diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/ChangeLog | 7368 | ||||
| -rw-r--r-- | doc/DANE-draft-notes | 11 | ||||
| -rw-r--r-- | doc/Exim3.upgrade | 671 | ||||
| -rw-r--r-- | doc/Exim4.upgrade | 1730 | ||||
| -rw-r--r-- | doc/GnuTLS-FAQ.txt | 414 | ||||
| -rw-r--r-- | doc/NewStuff | 1278 | ||||
| -rw-r--r-- | doc/OptionLists.txt | 1062 | ||||
| -rw-r--r-- | doc/README | 65 | ||||
| -rw-r--r-- | doc/README.SIEVE | 343 | ||||
| -rw-r--r-- | doc/cve-2016-9663 | 95 | ||||
| -rw-r--r-- | doc/dbm.discuss.txt | 320 | ||||
| -rw-r--r-- | doc/exim.8 | 1709 | ||||
| -rw-r--r-- | doc/experimental-spec.txt | 989 | ||||
| -rw-r--r-- | doc/filter.txt | 1725 | ||||
| -rw-r--r-- | doc/openssl.txt | 165 | ||||
| -rw-r--r-- | doc/spec.txt | 37579 |
16 files changed, 55524 insertions, 0 deletions
diff --git a/doc/ChangeLog b/doc/ChangeLog new file mode 100644 index 0000000..7da07ad --- /dev/null +++ b/doc/ChangeLog @@ -0,0 +1,7368 @@ +Change log file for Exim from version 4.21 +------------------------------------------ +This document describes *changes* to previous versions, that might +affect Exim's operation, with an unchanged configuration file. For new +options, and new features, see the NewStuff file next to this ChangeLog. + + +Exim version 4.92 +----------------- + +JH/01 Remove code calling the customisable local_scan function, unless a new + definition "HAVE_LOCAL_SCAN=yes" is present in the Local/Makefile. + +JH/02 Bug 1007: Avoid doing logging from signal-handlers, as that can result in + non-signal-safe functions being used. + +JH/03 Bug 2269: When presented with a received message having a stupidly large + number of DKIM-Signature headers, disable DKIM verification to avoid + a resource-consumption attack. The limit is set at twenty. + +JH/04 Add variables $arc_domains, $arc_oldest_pass for ARC verify. Fix the + report of oldest_pass in ${authres } in consequence, and separate out + some descriptions of reasons for verification fail. + +JH/05 Bug 2273: Cutthrough delivery left a window where the received messsage + files in the spool were present and unlocked. A queue-runner could spot + them, resulting in a duplicate delivery. Fix that by doing the unlock + after the unlink. Investigation by Tim Stewart. Take the opportunity to + add more error-checking on spoolfile handling while that code is being + messed with. + +PP/01 Refuse to open a spool data file (*-D) if it's a symlink. + No known attacks, no CVE, this is defensive hardening. + +JH/06 Bug 2275: The MIME ACL unlocked the received message files early, and + a queue-runner could start a delivery while other operations were ongoing. + Cutthrough delivery was a common victim, resulting in duplicate delivery. + Found and investigated by Tim Stewart. Fix by using the open message data + file handle rather than opening another, and not locally closing it (which + releases a lock) for that case, while creating the temporary .eml format + file for the MIME ACL. Also applies to "regex" and "spam" ACL conditions. + +JH/07 Bug 177: Make a random-recipient callout success visible in ACL, by setting + $sender_verify_failure/$recipient_verify_failure to "random". + +JH/08 When generating a selfsigned cert, use serial number 1 since zero is not + legitimate. + +JH/09 Bug 2274: Fix logging of cmdline args when starting in an unlinked cwd. + Previously this would segfault. + +JH/10 Fix ARC signing for case when DKIM signing failed. Previously this would + segfault. + +JH/11 Bug 2264: Exim now only follows CNAME chains one step by default. We'd + like zero, since the resolver should be doing this for us, But we need one + as a CNAME but no MX presence gets the CNAME returned; we need to check + that doesn't point to an MX to declare it "no MX returned" rather than + "error, loop". A new main option is added so the older capability of + following some limited number of chain links is maintained. + +JH/12 Add client-ip info to non-pass iprev ${authres } lines. + +JH/13 For receent Openssl versions (1.1 onward) use modern generic protocol + methods. These should support TLS 1.3; they arrived with TLS 1.3 and the + now-deprecated earlier definitions used only specified the range up to TLS + 1.2 (in the older-version library docs). + +JH/14 Bug 2284: Fix DKIM signing for body lines starting with a pair of dots. + +JH/15 Rework TLS client-side context management. Stop using a global, and + explicitly pass a context around. This enables future use of TLS for + connections to service-daemons (eg. malware scanning) while a client smtp + connection is using TLS; with cutthrough connections this is quite likely. + +JH/16 Fix ARC verification to do AS checks in reverse order. + +JH/17 Support a "tls" option on the ${readsocket } expansion item. + +JH/18 Bug 2287: Fix the protocol name (eg utf8esmtp) for multiple messages + using the SMTPUTF8 option on their MAIL FROM commands, in one connection. + Previously the "utf8" would be re-prepended for every additional message. + +JH/19 Reject MAIL FROM commands with SMTPUTF8 when the facility was not advertised. + Previously thery were accepted, resulting in issues when attempting to + forward messages to a non-supporting MTA. + +PP/02 Let -n work with printing macros too, not just options. + +JH/20 Bug 2296: Fix cutthrough for >1 address redirection. Previously only + one parent address was copied, and bogus data was used at delivery-logging + time. Either a crash (after delivery) or bogus log data could result. + Discovery and analysis by Tim Stewart. + +PP/03 Make ${utf8clean:} expansion operator detect incomplete final character. + Previously if the string ended mid-character, we did not insert the + promised '?' replacement. + +PP/04 Documentation: current string operators work on bytes, not codepoints. + +JH/21 Change as many as possible of the global flags into one-bit bitfields; these + should pack well giving a smaller memory footprint so better caching and + therefore performance. Group the declarations where this can't be done so + that the byte-sized flag variables are not interspersed among pointer + variables, giving a better chance of good packing by the compiler. + +JH/22 Bug 1896: Fix the envelope from for DMARC forensic reports to be possibly + non-null, to avoid issues with sites running BATV. Previously reports were + sent with an empty envelope sender so looked like bounces. + +JH/23 Bug 2318: Fix the noerror command within filters. It wasn't working. + The ignore_error flag wasn't being returned from the filter subprocess so + was not set for later routers. Investigation and fix by Matthias Kurz. + +JH/24 Bug 2310: Raise a msg:fail:internal event for each undelivered recipient, + and a msg:complete for the whole, when a message is manually removed using + -Mrm. Developement by Matthias Kurz, hacked on by JH. + +JH/25 Avoid fixed-size buffers for pathnames in DB access. This required using + a "Gnu special" function, asprintf() in the DB utility binary builds; I + hope that is portable enough. + +JH/26 Bug 2311: Fix DANE-TA verification under GnuTLS. Previously it was also + requiring a known-CA anchor certificate; make it now rely entirely on the + TLSA as an anchor. Checking the name on the leaf cert against the name + on the A-record for the host is still done for TA (but not for EE mode). + +JH/27 Fix logging of proxy address. Previously, a pointless "PRX=[]:0" would be + included in delivery lines for non-proxied connections, when compiled with + SUPPORT_SOCKS and running with proxy logging enabled. + +JH/28 Bug 2314: Fire msg:fail:delivery event even when error is being ignored. + Developement by Matthias Kurz, tweaked by JH. While in that bit of code, + move the existing event to fire before the normal logging of message + failure so that custom logging is bracketed by normal logging. + +JH/29 Bug 2322: A "fail" command in a non-system filter (file) now fires the + msg:fail:internal event. Developement by Matthias Kurz. + +JH/30 Bug 2329: Increase buffer size used for dns lookup from 2k, which was + far too small for todays use of crypto signatures stored there. Go all + the way to the max DNS message size of 64kB, even though this might be + overmuch for IOT constrained device use. + +JH/31 Fix a bad use of a copy function, which could be used to pointlessly + copy a string over itself. The library routine is documented as not + supporting overlapping copies, and on MacOS it actually raised a SIGABRT. + +JH/32 For main options check_spool_space and check_inode_space, where the + platform supports 64b integers, support more than the previous 2^31 kB + (i.e. more than 2 TB). Accept E, P and T multipliers in addition to + the previous G, M, k. + +JH/33 Bug 2338: Fix the cyrus-sasl authenticator to fill in the + $authenticated_fail_id variable on authentication failure. Previously + it was unset. + +JH/34 Increase RSA keysize of autogen selfsign cert from 1024 to 2048. RHEL 8.0 + OpenSSL didn't want to use such a weak key. Do for GnuTLS also, and for + more-modern GnuTLS move from GNUTLS_SEC_PARAM_LOW to + GNUTLS_SEC_PARAM_MEDIUM. + +JH/35 OpenSSL: fail the handshake when SNI processing hits a problem, server + side. Previously we would continue as if no SNI had been received. + +JH/36 Harden the handling of string-lists. When a list consisted of a sole + "<" character, which should be a list-separator specification, we walked + off past the nul-terimation. + +JH/37 Bug 2341: Send "message delayed" warning MDNs (restricted to external + causes) even when the retry time is not yet met. Previously they were + not, meaning that when (say) an account was over-quota and temp-rejecting, + and multiple senders' messages were queued, only one sender would get + notified on each configured delay_warning cycle. + +JH/38 Bug 2351: Log failures to extract envelope addresses from message headers. + +JH/39 OpenSSL: clear the error stack after an SSL_accept(). With anon-auth + cipher-suites, an error can be left on the stack even for a succeeding + accept; this results in impossible error messages when a later operation + actually does fail. + +AM/01 Bug 2359: GnuTLS: repeat lowlevel read and write operations while they + return error codes indicating retry. Under TLS1.3 this becomes required. + +JH/40 Fix the feature-cache refresh for EXPERIMENTAL_PIPE_CONNECT. Previously + it only wrote the new authenticators, resulting in a lack of tracking of + peer changes of ESMTP extensions until the next cache flush. + +JH/41 Fix the loop reading a message header line to check for integer overflow, + and more-often against header_maxsize. Previously a crafted message could + induce a crash of the recive process; now the message is cleanly rejected. + +JH/42 Bug 2366: Fix the behaviour of the dkim_verify_signers option. It had + been totally disabled for all of 4.91. Discovery and fix by "Mad Alex". + + +Exim version 4.91 +----------------- + +GF/01 DEFER rather than ERROR on redis cluster MOVED response. + When redis_servers is set to a list of > 1 element, and the Redis servers + in that list are in cluster configuration, convert the REDIS_REPLY_ERROR + case of MOVED into a DEFER case instead, thus moving the query onto the + next server in the list. For a cluster of N elements, all N servers must + be defined in redis_servers. + +GF/02 Catch and remove uninitialized value warning in exiqsumm + Check for existence of @ARGV before looking at $ARGV[0] + +JH/01 Replace the store_release() internal interface with store_newblock(), + which internalises the check required to safely use the old one, plus + the allocate and data copy operations duplicated in both (!) of the + extant use locations. + +JH/02 Disallow '/' characters in queue names specified for the "queue=" ACL + modifier. This matches the restriction on the commandline. + +JH/03 Fix pgsql lookup for multiple result-tuples with a single column. + Previously only the last row was returned. + +JH/04 Bug 2217: Tighten up the parsing of DKIM signature headers. Previously + we assumed that tags in the header were well-formed, and parsed the + element content after inspecting only the first char of the tag. + Assumptions at that stage could crash the receive process on malformed + input. + +JH/05 Bug 2215: Fix crash associated with dnsdb lookup done from DKIM ACL. + While running the DKIM ACL we operate on the Permanent memory pool so that + variables created with "set" persist to the DATA ACL. Also (at any time) + DNS lookups that fail create cache records using the Permanent pool. But + expansions release any allocations made on the current pool - so a dnsdb + lookup expansion done in the DKIM ACL releases the memory used for the + DNS negative-cache, and bad things result. Solution is to switch to the + Main pool for expansions. + While we're in that code, add checks on the DNS cache during store_reset, + active in the testsuite. + Problem spotted, and debugging aided, by Wolfgang Breyha. + +JH/06 Fix issue with continued-connections when the DNS shifts unreliably. + When none of the hosts presented to a transport match an already-open + connection, close it and proceed with the list. Previously we would + queue the message. Spotted by Lena with Yahoo, probably involving + round-robin DNS. + +JH/07 Bug 2214: Fix SMTP responses resulting from non-accept result of MIME ACL. + Previously a spurious "250 OK id=" response was appended to the proper + failure response. + +JH/08 The "support for" informational output now, which built with Content + Scanning support, has a line for the malware scanner interfaces compiled + in. Interface can be individually included or not at build time. + +JH/09 The "aveserver", "kavdaemon" and "mksd" interfaces are now not included + by the template makefile "src/EDITME". The "STREAM" support for an older + ClamAV interface method is removed. + +JH/10 Bug 2223: Fix mysql lookup returns for the no-data case (when the number of + rows affected is given instead). + +JH/11 The runtime Berkeley DB library version is now additionally output by + "exim -d -bV". Previously only the compile-time version was shown. + +JH/12 Bug 2230: Fix cutthrough routing for nonfirst messages in an initiating + SMTP connection. Previously, when one had more receipients than the + first, an abortive onward connection was made. Move to full support for + multiple onward connections in sequence, handling cutthrough connection + for all multi-message initiating connections. + +JH/13 Bug 2229: Fix cutthrough routing for nonstandard port numbers defined by + routers. Previously, a multi-recipient message would fail to match the + onward-connection opened for the first recipient, and cause its closure. + +JH/14 Bug 2174: A timeout on connect for a callout was also erroneously seen as + a timeout on read on a GnuTLS initiating connection, resulting in the + initiating connection being dropped. This mattered most when the callout + was marked defer_ok. Fix to keep the two timeout-detection methods + separate. + +JH/15 Relax results from ACL control request to enable cutthrough, in + unsupported situations, from error to silently (except under debug) + ignoring. This covers use with PRDR, frozen messages, queue-only and + fake-reject. + +HS/01 Fix Buffer overflow in base64d() (CVE-2018-6789) + +JH/16 Fix bug in DKIM verify: a buffer overflow could corrupt the malloc + metadata, resulting in a crash in free(). + +PP/01 Fix broken Heimdal GSSAPI authenticator integration. + Broken in f2ed27cf5, missing an equals sign for specified-initialisers. + Broken also in d185889f4, with init system revamp. + +JH/17 Bug 2113: Fix conversation closedown with the Avast malware scanner. + Previously we abruptly closed the connection after reading a malware- + found indication; now we go on to read the "scan ok" response line, + and send a quit. + +JH/18 Bug 2239: Enforce non-usability of control=utf8_downconvert in the mail + ACL. Previously, a crash would result. + +JH/19 Speed up macro lookups during configuration file read, by skipping non- + macro text after a replacement (previously it was only once per line) and + by skipping builtin macros when searching for an uppercase lead character. + +JH/20 DANE support moved from Experimental to mainline. The Makefile control + for the build is renamed. + +JH/21 Fix memory leak during multi-message connections using STARTTLS. A buffer + was allocated for every new TLS startup, meaning one per message. Fix + by only allocating once (OpenSSL) or freeing on TLS-close (GnuTLS). + +JH/22 Bug 2236: When a DKIM verification result is overridden by ACL, DMARC + reported the original. Fix to report (as far as possible) the ACL + result replacing the original. + +JH/23 Fix memory leak during multi-message connections using STARTTLS under + OpenSSL. Certificate information is loaded for every new TLS startup, + and the resources needed to be freed. + +JH/24 Bug 2242: Fix exim_dbmbuild to permit directoryless filenames. + +JH/25 Fix utf8_downconvert propagation through a redirect router. Previously it + was not propagated. + +JH/26 Bug 2253: For logging delivery lines under PRDR, append the overall + DATA response info to the (existing) per-recipient response info for + the "C=" log element. It can have useful tracking info from the + destination system. Patch from Simon Arlott. + +JH/27 Bug 2251: Fix ldap lookups that return a single attribute having zero- + length value. Previously this would segfault. + +HS/02 Support Avast multiline protoocol, this allows passing flags to + newer versions of the scanner. + +JH/28 Ensure that variables possibly set during message acceptance are marked + dead before release of memory in the daemon loop. This stops complaints + about them when the debug_store option is enabled. Discovered specifically + for sender_rate_period, but applies to a whole set of variables. + Do the same for the queue-runner and queue-list loops, for variables set + from spool message files. Do the same for the SMTP per-message loop, for + certain variables indirectly set in ACL operations. + +JH/29 Bug 2250: Fix a longstanding bug in heavily-pipelined SMTP input (such + as a multi-recipient message from a mailinglist manager). The coding had + an arbitrary cutoff number of characters while checking for more input; + enforced by writing a NUL into the buffer. This corrupted long / fast + input. The problem was exposed more widely when more pipelineing of SMTP + responses was introduced, and one Exim system was feeding another. + The symptom is log complaints of SMTP syntax error (NUL chars) on the + receiving system, and refused recipients seen by the sending system + (propating to people being dropped from mailing lists). + Discovered and pinpointed by David Carter. + +JH/30 The (EXPERIMENTAL_DMARC) variable $dmarc_ar_header is withdrawn, being + replaced by the ${authresults } expansion. + +JH/31 Bug 2257: Fix pipe transport to not use a socket-only syscall. + +HS/03 Set a handler for SIGTERM and call exit(3) if running as PID 1. This + allows proper process termination in container environments. + +JH/32 Bug 2258: Fix spool_wireformat in combination with LMTP transport. + Previously the "final dot" had a newline after it; ensure it is CR,LF. + +JH/33 SPF: remove support for the "spf" ACL condition outcome values "err_temp" + and "err_perm", deprecated since 4.83 when the RFC-defined words + "temperror" and "permerror" were introduced. + +JH/34 Re-introduce enforcement of no cutthrough delivery on transports having + transport-filters or DKIM-signing. The restriction was lost in the + consolidation of verify-callout and delivery SMTP handling. + Extend the restriction to also cover ARC-signing. + +JH/35 Cutthrough: for a final-dot response timeout (and nonunderstood responses) + in defer=pass mode supply a 450 to the initiator. Previously the message + would be spooled. + +PP/02 DANE: add dane_require_tls_ciphers SMTP Transport option; if unset, + tls_require_ciphers is used as before. + +HS/03 Malware Avast: Better match the Avast multiline protocol. Add + "pass_unscanned". Only tmpfails from the scanner are written to + the paniclog, as they may require admin intervention (permission + denied, license issues). Other scanner errors (like decompression + bombs) do not cause a paniclog entry. + +JH/36 Fix reinitialisation of DKIM logging variable between messages. + Previously it was possible to log spurious information in receive log + lines. + +JH/37 Bug 2255: Revert the disable of the OpenSSL session caching. This + triggered odd behaviour from Outlook Express clients. + +PP/03 Add util/renew-opendmarc-tlds.sh script for safe renewal of public + suffix list. + +JH/38 DKIM: accept Ed25519 pubkeys in SubjectPublicKeyInfo-wrapped form, + since the IETF WG has not yet settled on that versus the original + "bare" representation. + +JH/39 Fix syslog logging for syslog_timestamp=no and log_selector +millisec. + Previously the millisecond value corrupted the output. + Fix also for syslog_pid=no and log_selector +pid, for which the pid + corrupted the output. + + +Exim version 4.90 +----------------- + +JH/01 Rework error string handling in TLS interface so that the caller in + more cases is responsible for logging. This permits library-sourced + string to be attached to addresses during delivery, and collapses + pairs of long lines into single ones. + +PP/01 Allow PKG_CONFIG_PATH to be set in Local/Makefile and use it correctly + during configuration. Wildcards are allowed and expanded. + +JH/02 Rework error string handling in DKIM to pass more info back to callers. + This permits better logging. + +JH/03 Rework the transport continued-connection mechanism: when TLS is active, + do not close it down and have the child transport start it up again on + the passed-on TCP connection. Instead, proxy the child (and any + subsequent ones) for TLS via a unix-domain socket channel. Logging is + affected: the continued delivery log lines do not have any DNSSEC, TLS + Certificate or OCSP information. TLS cipher information is still logged. + +JH/04 Shorten the log line for daemon startup by collapsing adjacent sets of + identical IP addresses on different listening ports. Will also affect + "exiwhat" output. + +PP/02 Bug 2070: uClibc defines __GLIBC__ without providing glibc headers; + add noisy ifdef guards to special-case this sillyness. + Patch from Bernd Kuhls. + +JH/05 Tighten up the checking in isip4 (et al): dotted-quad components larger + than 255 are no longer allowed. + +JH/06 Default openssl_options to include +no_ticket, to reduce load on peers. + Disable the session-cache too, which might reduce our load. Since we + currrectly use a new context for every connection, both as server and + client, there is no benefit for these. + GnuTLS appears to not support tickets server-side by default (we don't + call gnutls_session_ticket_enable_server()) but client side is enabled + by default on recent versions (3.1.3 +) unless the PFS priority string + is used (3.2.4 +). + +PP/03 Add $SOURCE_DATE_EPOCH support for reproducible builds, per spec at + <https://reproducible-builds.org/specs/source-date-epoch/>. + +JH/07 Fix smtp transport use of limited max_rcpt under mua_wrapper. Previously + the check for any unsuccessful recipients did not notice the limit, and + erroneously found still-pending ones. + +JH/08 Pipeline CHUNKING command and data together, on kernels that support + MSG_MORE. Only in-clear (not on TLS connections). + +JH/09 Avoid using a temporary file during transport using dkim. Unless a + transport-filter is involved we can buffer the headers in memory for + creating the signature, and read the spool data file once for the + signature and again for transmission. + +JH/10 Enable use of sendfile in Linux builds as default. It was disabled in + 4.77 as the kernel support then wasn't solid, having issues in 64bit + mode. Now, it's been long enough. Add support for FreeBSD also. + +JH/11 Bug 2104: Fix continued use of a transport connection with TLS. In the + case where the routing stage had gathered several addresses to send to + a host before calling the transport for the first, we previously failed + to close down TLS in the old transport process before passing the TCP + connection to the new process. The new one sent a STARTTLS command + which naturally failed, giving a failed delivery and bloating the retry + database. Investigation and fix prototype from Wolfgang Breyha. + +JH/12 Fix check on SMTP command input synchronisation. Previously there were + false-negatives in the check that the sender had not preempted a response + or prompt from Exim (running as a server), due to that code's lack of + awareness of the SMTP input buffering. + +PP/04 Add commandline_checks_require_admin option. + Exim drops privileges sanely, various checks such as -be aren't a + security problem, as long as you trust local users with access to their + own account. When invoked by services which pass untrusted data to + Exim, this might be an issue. Set this option in main configuration + AND make fixes to the calling application, such as using `--` to stop + processing options. + +JH/13 Do pipelining under TLS. Previously, although safe, no advantage was + taken. Now take care to pack both (client) MAIL,RCPT,DATA, and (server) + responses to those, into a single TLS record each way (this usually means + a single packet). As a side issue, smtp_enforce_sync now works on TLS + connections. + +PP/05 OpenSSL/1.1: use DH_bits() for more accurate DH param sizes. This + affects you only if you're dancing at the edge of the param size limits. + If you are, and this message makes sense to you, then: raise the + configured limit or use OpenSSL 1.1. Nothing we can do for older + versions. + +JH/14 For the "sock" variant of the malware scanner interface, accept an empty + cmdline element to get the documented default one. Previously it was + inaccessible. + +JH/15 Fix a crash in the smtp transport caused when two hosts in succession + are unsuable for non-message-specific reasons - eg. connection timeout, + banner-time rejection. + +JH/16 Fix logging of delivery remote port, when specified by router, under + callout/hold. + +PP/06 Repair manualroute's ability to take options in any order, even if one + is the name of a transport. + Fixes bug 2140. + +HS/01 Cleanup, prevent repeated use of -p/-oMr (CVE-2017-1000369) + +JH/17 Change the list-building routines interface to use the expanding-string + triplet model, for better allocation and copying behaviour. + +JH/18 Prebuild the data-structure for "builtin" macros, for faster startup. + Previously it was constructed the first time a possibly-matching string + was met in the configuration file input during startup; now it is done + during compilation. + +JH/19 Bug 2141: Use the full-complex API for Berkeley DB rather than the legacy- + compatible one, to avoid the (poorly documented) possibility of a config + file in the working directory redirecting the DB files, possibly correpting + some existing file. CVE-2017-10140 assigned for BDB. + +JH/20 Bug 2147: Do not defer for a verify-with-callout-and-random which is not + cache-hot. Previously, although the result was properly cached, the + initial verify call returned a defer. + +JH/21 Bug 2151: Avoid using SIZE on the MAIL for a callout verify, on any but + the main verify for receipient in uncached-mode. + +JH/22 Retire historical build files to an "unsupported" subdir. These are + defined as "ones for which we have no current evidence of testing". + +JH/23 DKIM: enforce the DNS pubkey record "h" permitted-hashes optional field, + if present. Previously it was ignored. + +JH/24 Start using specified-initialisers in C structure init coding. This is + a C99 feature (it's 2017, so now considered safe). + +JH/25 Use one-bit bitfields for flags in the "addr" data structure. Previously + if was a fixed-sized field and bitmask ops via macros; it is now more + extensible. + +PP/07 GitHub PR 56: Apply MariaDB build fix. + Patch provided by Jaroslav Škarvada. + +PP/08 Bug 2161: Fix regression in sieve quoted-printable handling introduced + during Coverity cleanups [4.87 JH/47] + Diagnosis and fix provided by Michael Fischer v. Mollard. + +JH/26 Fix DKIM bug: when the pseudoheader generated for signing was exactly + the right size to place the terminating semicolon on its own folded + line, the header hash was calculated to an incorrect value thanks to + the (relaxed) space the fold became. + +HS/02 Fix Bug 2130: large writes from the transport subprocess were chunked + and confused the parent. + +JH/27 Fix SOCKS bug: an unitialized pointer was deref'd by the transport process + which could crash as a result. This could lead to undeliverable messages. + +JH/28 Logging: "next input sent too soon" now shows where input was truncated + for log purposes. + +JH/29 Fix queue_run_in_order to ignore the PID portion of the message ID. This + matters on fast-turnover and PID-randomising systems, which were getting + out-of-order delivery. + +JH/30 Fix a logging bug on aarch64: an unsafe routine was previously used for + a possibly-overlapping copy. The symptom was that "Remote host closed + connection in response to HELO" was logged instead of the actual 4xx + error for the HELO. + +JH/31 Fix CHUNKING code to properly flush the unwanted chunk after an error. + Previously only that bufferd was discarded, resulting in SYMTP command + desynchronisation. + +JH/32 DKIM: when a message has multiple signatures matching an identity given + in dkim_verify_signers, run the dkim acl once for each. Previously only + one run was done. Bug 2189. + +JH/33 Downgrade an unfound-list name (usually a typo in the config file) from + "panic the current process" to "deliberately defer". The panic log is + still written with the problem list name; the mail and reject logs now + get a temp-reject line for the message that was being handled, saying + something like "domains check lookup or other defer". The SMTP 451 + message is still "Temporary local problem". + +JH/34 Bug 2199: Fix a use-after-free while reading smtp input for header lines. + A crafted sequence of BDAT commands could result in in-use memory beeing + freed. CVE-2017-16943. + +HS/03 Bug 2201: Fix checking for leading-dot on a line during headers reading + from SMTP input. Previously it was always done; now only done for DATA + and not BDAT commands. CVE-2017-16944. + +JH/35 Bug 2201: Flush received data in BDAT mode after detecting an error fatal + to the message (such as an overlong header line). Previously this was + not done and we did not exit BDAT mode. Followon from the previous item + though a different problem. + + +Exim version 4.89 +----------------- + +JH/01 Bug 1922: Support IDNA2008. This has slightly different conversion rules + than -2003 did; needs libidn2 in addition to libidn. + +JH/02 The path option on a pipe transport is now expanded before use. + +PP/01 GitHub PR 50: Do not call ldap_start_tls_s on ldapi:// connections. + Patch provided by "Björn", documentation fix added too. + +JH/03 Bug 2003: fix Proxy Protocol v2 handling: the address size field was + missing a wire-to-host endian conversion. + +JH/04 Bug 2004: fix CHUNKING in non-PIPELINEING mode. Chunk data following + close after a BDAT command line could be taken as a following command, + giving a synch failure. Fix by only checking for synch immediately + before acknowledging the chunk. + +PP/02 GitHub PR 52: many spelling fixes, which include fixing parsing of + no_require_dnssec option and creation of _HAVE_TRANSPORT_APPEND_MAILDIR + macro. Patches provided by Josh Soref. + +JH/05 Have the EHLO response advertise VRFY, if there is a vrfy ACL defined. + Previously we did not; the RFC seems ambiguous and VRFY is not listed + by IANA as a service extension. However, John Klensin suggests that we + should. + +JH/06 Bug 2017: Fix DKIM verification in -bh test mode. The data feed into + the dkim code may be unix-mode line endings rather than smtp wire-format + CRLF, so prepend a CR to any bare LF. + +JH/07 Rationalise the coding for callout smtp conversations and transport ones. + As a side-benfit, callouts can now use PIPELINING hence fewer round-trips. + +JH/08 Bug 2016: Fix DKIM verification vs. CHUNKING. Any BDAT commands after + the first were themselves being wrongly included in the feed into dkim + processing; with most chunk sizes in use this resulted in an incorrect + body hash calculated value. + +JH/09 Bug 2014: permit inclusion of a DKIM-Signature header in a received + DKIM signature block, for verification. Although advised against by + standards it is specifically not ruled illegal. + +JH/10 Bug 2025: Fix reception of (quoted) local-parts with embedded spaces. + +JH/11 Bug 2029: Fix crash in DKIM verification when a message signature block is + missing a body hash (the bh= tag). + +JH/12 Bug 2018: Re-order Proxy Protocol startup versus TLS-on-connect startup. + It seems that HAProxy sends the Proxy Protocol information in clear and + only then does a TLS startup, so do the same. + +JH/13 Bug 2027: Avoid attempting to use TCP Fast Open for non-transport client + TCP connections (such as for Spamd) unless the daemon successfully set + Fast Open mode on its listening sockets. This fixes breakage seen on + too-old kernels or those not configured for Fast Open, at the cost of + requiring both directions being enabled for TFO, and TFO never being used + by non-daemon-related Exim processes. + +JH/14 Bug 2000: Reject messages recieved with CHUNKING but with malformed line + endings, at least on the first header line. Try to canonify any that get + past that check, despite the cost. + +JH/15 Angle-bracket nesting (an error inserted by broken sendmails) levels are + now limited to an arbitrary five deep, while parsing addresses with the + strip_excess_angle_brackets option enabled. + +PP/03 Bug 2018: For Proxy Protocol and TLS-on-connect, do not over-read and + instead leave the unprompted TLS handshake in socket buffer for the + TLS library to consume. + +PP/04 Bug 2018: Also handle Proxy Protocol v2 safely. + +PP/05 FreeBSD compat: handle that Ports no longer create /usr/bin/perl + +JH/16 Drop variables when they go out of scope. Memory management drops a whole + region in one operation, for speed, and this leaves assigned pointers + dangling. Add checks run only under the testsuite which checks all + variables at a store-reset and panics on a dangling pointer; add code + explicitly nulling out all the variables discovered. Fixes one known + bug: a transport crash, where a dangling pointer for $sending_ip_address + originally assigned in a verify callout, is re-used. + +PP/06 Drop '.' from @INC in various Perl scripts. + +PP/07 Switch FreeBSD iconv to always use the base-system libc functions. + +PP/08 Reduce a number of compilation warnings under clang; building with + CC=clang CFLAGS+=-Wno-dangling-else -Wno-logical-op-parentheses + should be warning-free. + +JH/17 Fix inbound CHUNKING when DKIM disabled at runtime. + +HS/01 Fix portability problems introduced by PP/08 for platforms where + realloc(NULL) is not equivalent to malloc() [SunOS et al]. + +HS/02 Bug 1974: Fix missing line terminator on the last received BDAT + chunk. This allows us to accept broken chunked messages. We need a more + general solution here. + +PP/09 Wrote util/chunking_fixqueue_finalnewlines.pl to help recover + already-broken messages in the queue. + +JH/18 Bug 2061: Fix ${extract } corrupting an enclosing ${reduce } $value. + +JH/19 Fix reference counting bug in routing-generated-address tracking. + + +Exim version 4.88 +----------------- + +JH/01 Use SIZE on MAIL FROM in a cutthrough connection, if the destination + supports it and a size is available (ie. the sending peer gave us one). + +JH/02 The obsolete acl condition "demime" is removed (finally, after ten + years of being deprecated). The replacements are the ACLs + acl_smtp_mime and acl_not_smtp_mime. + +JH/03 Upgrade security requirements imposed for hosts_try_dane: previously + a downgraded non-dane trust-anchor for the TLS connection (CA-style) + or even an in-clear connection were permitted. Now, if the host lookup + was dnssec and dane was requested then the host is only used if the + TLSA lookup succeeds and is dnssec. Further hosts (eg. lower priority + MXs) will be tried (for hosts_try_dane though not for hosts_require_dane) + if one fails this test. + This means that a poorly-configured remote DNS will make it incommunicado; + but it protects against a DNS-interception attack on it. + +JH/04 Bug 1810: make continued-use of an open smtp transport connection + non-noisy when a race steals the message being considered. + +JH/05 If main configuration option tls_certificate is unset, generate a + self-signed certificate for inbound TLS connections. + +JH/06 Bug 165: hide more cases of password exposure - this time in expansions + in rewrites and routers. + +JH/07 Retire gnutls_require_mac et.al. These were nonfunctional since 4.80 + and logged a warning sing 4.83; now they are a configuration file error. + +JH/08 Bug 1836: Fix crash in VRFY handling when handed an unqualified name + (lacking @domain). Apply the same qualification processing as RCPT. + +JH/09 Bug 1804: Avoid writing msglog files when in -bh or -bhc mode. + +JH/10 Support ${sha256:} applied to a string (as well as the previous + certificate). + +JH/11 Cutthrough: avoid using the callout hints db on a verify callout when + a cutthrough deliver is pending, as we always want to make a connection. + This also avoids re-routing the message when later placing the cutthrough + connection after a verify cache hit. + Do not update it with the verify result either. + +JH/12 Cutthrough: disable when verify option success_on_redirect is used, and + when routing results in more than one destination address. + +JH/13 Cutthrough: expand transport dkim_domain option when testing for dkim + signing (which inhibits the cutthrough capability). Previously only + the presence of an option was tested; now an expansion evaluating as + empty is permissible (obviously it should depend only on data available + when the cutthrough connection is made). + +JH/14 Fix logging of errors under PIPELINING. Previously the log line giving + the relevant preceding SMTP command did not note the pipelining mode. + +JH/15 Fix counting of empty lines in $body_linecount and $message_linecount. + Previously they were not counted. + +JH/16 DANE: treat a TLSA lookup response having all non-TLSA RRs, the same + as one having no matching records. Previously we deferred the message + that needed the lookup. + +JH/17 Fakereject: previously logged as a normal message arrival "<="; now + distinguished as "(=". + +JH/18 Bug 1867: make the fail_defer_domains option on a dnslookup router work + for missing MX records. Previously it only worked for missing A records. + +JH/19 Bug 1850: support Radius libraries that return REJECT_RC. + +JH/20 Bug 1872: Ensure that acl_smtp_notquit is run when the connection drops + after the data-go-ahead and data-ack. Patch from Jason Betts. + +JH/21 Bug 1846: Send DMARC forensic reports for reject and quarantine results, + even for a "none" policy. Patch from Tony Meyer. + +JH/22 Fix continued use of a connection for further deliveries. If a port was + specified by a router, it must also match for the delivery to be + compatible. + +JH/23 Bug 1874: fix continued use of a connection for further deliveries. + When one of the recipients of a message was unsuitable for the connection + (has no matching addresses), we lost track of needing to mark it + deferred. As a result mail would be lost. + +JH/24 Bug 1832: Log EHLO response on getting conn-close response for HELO. + +JH/25 Decoding ACL controls is now done using a binary search; the source code + takes up less space and should be simpler to maintain. Merge the ACL + condition decode tables also, with similar effect. + +JH/26 Fix problem with one_time used on a redirect router which returned the + parent address unchanged. A retry would see the parent address marked as + delivered, so not attempt the (identical) child. As a result mail would + be lost. + +JH/27 Fix a possible security hole, wherein a process operating with the Exim + UID can gain a root shell. Credit to http://www.halfdog.net/ for + discovery and writeup. Ubuntu bug 1580454; no bug raised against Exim + itself :( + +JH/28 Enable {spool,log} filesystem space and inode checks as default. + Main config options check_{log,spool}_{inodes,space} are now + 100 inodes, 10MB unless set otherwise in the configuration. + +JH/29 Fix the connection_reject log selector to apply to the connect ACL. + Previously it only applied to the main-section connection policy + options. + +JH/30 Bug 1897: fix callouts connection fallback from TLS to cleartext. + +PP/01 Changed default Diffie-Hellman parameters to be Exim-specific, created + by me. Added RFC7919 DH primes as an alternative. + +PP/02 Unbreak build via pkg-config with new hash support when crypto headers + are not in the system include path. + +JH/31 Fix longstanding bug with aborted TLS server connection handling. Under + GnuTLS, when a session startup failed (eg because the client disconnected) + Exim did stdio operations after fclose. This was exposed by a recent + change which nulled out the file handle after the fclose. + +JH/32 Bug 1909: Fix OCSP proof verification for cases where the proof is + signed directly by the cert-signing cert, rather than an intermediate + OCSP-signing cert. This is the model used by LetsEncrypt. + +JH/33 Bug 1914: Ensure socket is nonblocking before draining after SMTP QUIT. + +HS/01 Fix leak in verify callout under GnuTLS, about 3MB per recipient on + an incoming connection. + +HS/02 Bug 1802: Do not half-close the connection after sending a request + to rspamd. + +HS/03 Use "auto" as the default EC curve parameter. For OpenSSL < 1.0.2 + fallback to "prime256v1". + +JH/34 SECURITY: Use proper copy of DATA command in error message. + Could leak key material. Remotely exploitable. CVE-2016-9963. + + +Exim version 4.87 +----------------- + +JH/01 Bug 1664: Disable OCSP for GnuTLS library versions at/before 3.3.16 + and 3.4.4 - once the server is enabled to respond to an OCSP request + it does even when not requested, resulting in a stapling non-aware + client dropping the TLS connection. + +TF/01 Code cleanup: Overhaul the debug_selector and log_selector machinery to + support variable-length bit vectors. No functional change. + +TF/02 Improve the consistency of logging incoming and outgoing interfaces. + The I= interface field on outgoing lines is now after the H= remote + host field, same as incoming lines. There is a separate + outgoing_interface log selector which allows you to disable the + outgoing I= field. + +JH/02 Bug 728: Close logfiles after a daemon-process "exceptional" log write. + If not running log_selector +smtp_connection the mainlog would be held + open indefinitely after a "too many connections" event, including to a + deleted file after a log rotate. Leave the per net connection logging + leaving it open for efficiency as that will be quickly detected by the + check on the next write. + +HS/01 Bug 1671: Fix post transport crash. + Processing the wait-<transport> messages could crash the delivery + process if the message IDs didn't exist for some reason. When + using 'split_spool_directory=yes' the construction of the spool + file name failed already, exposing the same netto behaviour. + +JH/03 Bug 425: Capture substrings in $regex1, $regex2 etc from regex & + mime_regex ACL conditions. + +JH/04 Bug 1686: When compiled with EXPERIMENTAL_DSN_INFO: Add extra information + to DSN fail messages (bounces): remote IP, remote greeting, remote response + to HELO, local diagnostic string. + +JH/05 Downgrade message for a TLS-certificate-based authentication fail from + log line to debug. Even when configured with a tls authenticator many + client connections are expected to not authenticate in this way, so + an authenticate fail is not an error. + +HS/02 Add the Exim version string to the process info. This way exiwhat + gives some more detail about the running daemon. + +JH/06 Bug 1395: time-limit caching of DNS lookups, to the TTL value. This may + matter for fast-change records such as DNSBLs. + +JH/07 Bug 1678: Always record an interface option value, if set, as part of a + retry record, even if constant. There may be multiple transports with + different interface settings and the retry behaviour needs to be kept + distinct. + +JH/08 Bug 1586: exiqgrep now refuses to run if there are unexpected arguments. + +JH/09 Bug 1700: ignore space & tab embedded in base64 during decode. + +JH/10 Bug 840: fix log_defer_output option of pipe transport + +JH/11 Bug 830: use same host for all RCPTS of a message, even under + hosts_randomize. This matters a lot when combined with mua_wrapper. + +JH/12 Bug 1706: percent and underbar characters are no longer escaped by the + ${quote_pgsql:<string>} operator. + +JH/13 Bug 1708: avoid misaligned access in cached lookup. + +JH/14 Change header file name for freeradius-client. Relevant if compiling + with Radius support; from the Gentoo tree and checked under Fedora. + +JH/15 Bug 1712: Introduce $prdr_requested flag variable + +JH/16 Bug 1714: Permit an empty string as expansion result for transport + option transport_filter, meaning no filtering. + +JH/17 Bug 1713: Fix non-PDKIM_DEBUG build. Patch from Jasen Betts. + +JH/18 Bug 1709: When built with TLS support, the tls_advertise_hosts option now + defaults to "*" (all hosts). The variable is now available when not built + with TLS, default unset, mainly to enable keeping the testsuite sane. + If a server certificate is not supplied (via tls_certificate) an error is + logged, and clients will find TLS connections fail on startup. Presumably + they will retry in-clear. + Packagers of Exim are strongly encouraged to create a server certificate + at installation time. + +HS/03 Add -bP config_file as a synonym for -bP configure_file, for consistency + with the $config_file variable. + +JH/19 Two additional event types: msg:rcpt:defer and msg:rcpt:host:defer. Both + in transport context, after the attempt, and per-recipient. The latter type + is per host attempted. The event data is the error message, and the errno + information encodes the lookup type (A vs. MX) used for the (first) host, + and the trailing two digits of the smtp 4xx response. + +GF/01 Bug 1715: Fix for race condition in exicyclog, where exim could attempt + to write to mainlog (or rejectlog, paniclog) in the window between file + creation and permissions/ownership being changed. Particularly affects + installations where exicyclog is run as root, rather than exim user; + result is that the running daemon panics and dies. + +JH/20 Bug 1701: For MySQL lookups, support MySQL config file option group names. + +JH/21 Bug 1720: Add support for priority groups and weighted-random proxy + selection for the EXPERIMENTAL_SOCKS feature, via new per-proxy options + "pri" and "weight". Note that the previous implicit priority given by the + list order is no longer honoured. + +JH/22 Bugs 963, 1721: Fix some corner cases in message body canonicalization + for DKIM processing. + +JH/23 Move SOCKS5 support from Experimental to mainline, enabled for a build + by defining SUPPORT_SOCKS. + +JH/26 Move PROXY support from Experimental to mainline, enabled for a build + by defining SUPPORT_PROXY. Note that the proxy_required_hosts option + is renamed to hosts_proxy, and the proxy_{host,target}_{address,port}. + variables are renamed to proxy_{local,external}_{address,port}. + +JH/27 Move Internationalisation support from Experimental to mainline, enabled + for a build by defining SUPPORT_I18N + +JH/28 Bug 1745: Fix redis lookups to handle (quoted) spaces embedded in parts + of the query string, and make ${quote_redis:} do that quoting. + +JH/29 Move Events support from Experimental to mainline, enabled by default + and removable for a build by defining DISABLE_EVENT. + +JH/30 Updated DANE implementation code to current from Viktor Dukhovni. + +JH/31 Fix bug with hosts_connection_nolog and named-lists which were wrongly + cached by the daemon. + +JH/32 Move Redis support from Experimental to mainline, enabled for a build + by defining LOOKUP_REDIS. The libhiredis library is required. + +JH/33 Bug 1748: Permit ACL dnslists= condition in non-smtp ACLs if explicit + keys are given for lookup. + +JH/34 Bug 1192: replace the embedded copy of PolarSSL RSA routines in the DKIM + support, by using OpenSSL or GnuTLS library ones. This means DKIM is + only supported when built with TLS support. The PolarSSL SHA routines + are still used when the TLS library is too old for convenient support. + +JH/35 Require SINGLE_DH_USE by default in OpenSSL (main config option + openssl_options), for security. OpenSSL forces this from version 1.1.0 + server-side so match that on older versions. + +JH/36 Bug 1778: longstanding bug in memory use by the ${run } expansion: A fresh + allocation for $value could be released as the expansion processing + concluded, but leaving the global pointer active for it. + +JH/37 Bug 1769: Permit a VRFY ACL to override the default 252 response, + and to use the domains and local_parts ACL conditions. + +JH/38 Fix cutthrough bug with body lines having a single dot. The dot was + incorrectly not doubled on cutthrough transmission, hence seen as a + body-termination at the receiving system - resulting in truncated mails. + Commonly the sender saw a TCP-level error, and retransmitted the message + via the normal store-and-forward channel. This could result in duplicates + received - but deduplicating mailstores were liable to retain only the + initial truncated version. + +JH/39 Bug 1781: Fix use of DKIM private-keys having trailing '=' in the base-64. + +JH/40 Fix crash in queryprogram router when compiled with EXPERIMENTAL_SRS. + +JH/41 Bug 1792: Fix selection of headers to sign for DKIM: bottom-up. While + we're in there, support oversigning also; bug 1309. + +JH/42 Bug 1796: Fix error logged on a malware scanner connection failure. + +HS/04 Add support for keep_environment and add_environment options. + +JH/43 Tidy coding issues detected by gcc --fsanitize=undefined. Some remain; + either intentional arithmetic overflow during PRNG, or testing config- + induced overflows. + +JH/44 Bug 1800: The combination of a -bhc commandline option and cutthrough + delivery resulted in actual delivery. Cancel cutthrough before DATA + stage. + +JH/45 Fix cutthrough, when connection not opened by verify and target hard- + rejects a recipient: pass the reject to the originator. + +JH/46 Multiple issues raised by Coverity. Some were obvious or plausible bugs. + Many were false-positives and ignorable, but it's worth fixing the + former class. + +JH/47 Fix build on HP-UX and older Solaris, which need (un)setenv now also + for the new environment-manipulation done at startup. Move the routines + from being local to tls.c to being global via the os.c file. + +JH/48 Bug 1807: Fix ${extract } for the numeric/3-string case. While preparsing + an extract embedded as result-arg for a map, the first arg for extract + is unavailable so we cannot tell if this is a numbered or keyed + extraction. Accept either. + + +Exim version 4.86 +----------------- + +JH/01 Bug 1545: The smtp transport option "retry_include_ip_address" is now + expanded. + +JH/02 The smtp transport option "multi_domain" is now expanded. + +JH/03 The smtp transport now requests PRDR by default, if the server offers + it. + +JH/04 Certificate name checking on server certificates, when exim is a client, + is now done by default. The transport option tls_verify_cert_hostnames + can be used to disable this per-host. The build option + EXPERIMENTAL_CERTNAMES is withdrawn. + +JH/05 The value of the tls_verify_certificates smtp transport and main options + default to the word "system" to access the system default CA bundle. + For GnuTLS, only version 3.0.20 or later. + +JH/06 Verification of the server certificate for a TLS connection is now tried + (but not required) by default. The verification status is now logged by + default, for both outbound TLS and client-certificate supplying inbound + TLS connections + +JH/07 Changed the default rfc1413 lookup settings to disable calls. Few + sites use this now. + +JH/08 The EXPERIMENTAL_DSN compile option is no longer needed; all Delivery + Status Notification (bounce) messages are now MIME format per RFC 3464. + Support for RFC 3461 DSN options NOTIFY,ENVID,RET,ORCPT can be advertised + under the control of the dsn_advertise_hosts option, and routers may + have a dsn_lasthop option. + +JH/09 A timeout of 2 minutes is now applied to all malware scanner types by + default, modifiable by a malware= option. The list separator for + the options can now be changed in the usual way. Bug 68. + +JH/10 The smtp_receive_timeout main option is now expanded before use. + +JH/11 The incoming_interface log option now also enables logging of the + local interface on delivery outgoing connections. + +JH/12 The cutthrough-routing facility now supports multi-recipient mails, + if the interface and destination host and port all match. + +JH/13 Bug 344: The verify = reverse_host_lookup ACL condition now accepts a + /defer_ok option. + +JH/14 Bug 1573: The spam= ACL condition now additionally supports Rspamd. + Patch from Andrew Lewis. + +JH/15 Bug 670: The spamd_address main option (for the spam= ACL condition) + now supports optional time-restrictions, weighting, and priority + modifiers per server. Patch originally by <rommer@active.by>. + +JH/16 The spamd_address main option now supports a mixed list of local + and remote servers. Remote servers can be IPv6 addresses, and + specify a port-range. + +JH/17 Bug 68: The spamd_address main option now supports an optional + timeout value per server. + +JH/18 Bug 1581: Router and transport options headers_add/remove can + now have the list separator specified. + +JH/19 Bug 392: spamd_address, and clamd av_scanner, now support retry + option values. + +JH/20 Bug 1571: Ensure that $tls_in_peerdn is set, when verification fails + under OpenSSL. + +JH/21 Support for the A6 type of dns record is withdrawn. + +JH/22 Bug 608: The result of a QUIT or not-QUIT toplevel ACL now matters + rather than the verbs used. + +JH/23 Bug 1572: Increase limit on SMTP confirmation message copy size + from 255 to 1024 chars. + +JH/24 Verification callouts now attempt to use TLS by default. + +HS/01 DNSSEC options (dnssec_require_domains, dnssec_request_domains) + are generic router options now. The defaults didn't change. + +JH/25 Bug 466: Add RFC2322 support for MIME attachment filenames. + Original patch from Alexander Shikoff, worked over by JH. + +HS/02 Bug 1575: exigrep falls back to autodetection of compressed + files if ZCAT_COMMAND is not executable. + +JH/26 Bug 1539: Add timeout/retry options on dnsdb lookups. + +JH/27 Bug 286: Support SOA lookup in dnsdb lookups. + +JH/28 Bug 1588: Do not use the A lookup following an AAAA for setting the FQDN. + Normally benign, it bites when the pair was led to by a CNAME; + modern usage is to not canonicalize the domain to a CNAME target + (and we were inconsistent anyway for A-only vs AAAA+A). + +JH/29 Bug 1632: Removed the word "rejected" from line logged for ACL discards. + +JH/30 Check the forward DNS lookup for DNSSEC, in addition to the reverse, + when evaluating $sender_host_dnssec. + +JH/31 Check the HELO verification lookup for DNSSEC, adding new + $sender_helo_dnssec variable. + +JH/32 Bug 1397: Enable ECDHE on OpenSSL, just the NIST P-256 curve. + +JH/33 Bug 1346: Note MAIL cmd seen in -bS batch, to avoid smtp_no_mail log. + +JH/34 Bug 1648: Fix a memory leak seen with "mailq" and large queues. + +JH/35 Bug 1642: Fix support of $spam_ variables at delivery time. Was + documented as working, but never had. Support all but $spam_report. + +JH/36 Bug 1659: Guard checking of input smtp commands again pseudo-command + added for tls authenticator. + +HS/03 Add perl_taintmode main config option + + +Exim version 4.85 +----------------- + +TL/01 When running the test suite, the README says that variables such as + no_msglog_check are global and can be placed anywhere in a specific + test's script, however it was observed that placement needed to be near + the beginning for it to behave that way. Changed the runtest perl + script to read through the entire script once to detect and set these + variables, reset to the beginning of the script, and then run through + the script parsing/test process like normal. + +TL/02 The BSD's have an arc4random API. One of the functions to induce + adding randomness was arc4random_stir(), but it has been removed in + OpenBSD 5.5. Detect this OpenBSD version and skip calling this + function when detected. + +JH/01 Expand the EXPERIMENTAL_TPDA feature. Several different events now + cause callback expansion. + +TL/03 Bugzilla 1518: Clarify "condition" processing in routers; that + syntax errors in an expansion can be treated as a string instead of + logging or causing an error, due to the internal use of bool_lax + instead of bool when processing it. + +JH/02 Add EXPERIMENTAL_DANE, allowing for using the DNS as trust-anchor for + server certificates when making smtp deliveries. + +JH/03 Support secondary-separator specifier for MX, SRV, TLSA lookups. + +JH/04 Add ${sort {list}{condition}{extractor}} expansion item. + +TL/04 Bugzilla 1216: Add -M (related messages) option to exigrep. + +TL/05 GitHub Issue 18: Adjust logic testing for true/false in redis lookups. + Merged patch from Sebastian Wiedenroth. + +JH/05 Fix results-pipe from transport process. Several recipients, combined + with certificate use, exposed issues where response data items split + over buffer boundaries were not parsed properly. This eventually + resulted in duplicates being sent. This issue only became common enough + to notice due to the introduction of connection certificate information, + the item size being so much larger. Found and fixed by Wolfgang Breyha. + +JH/06 Bug 1533: Fix truncation of items in headers_remove lists. A fixed + size buffer was used, resulting in syntax errors when an expansion + exceeded it. + +JH/07 Add support for directories of certificates when compiled with a GnuTLS + version 3.3.6 or later. + +JH/08 Rename the TPDA experimental facility to Event Actions. The #ifdef + is EXPERIMENTAL_EVENT, the main-configuration and transport options + both become "event_action", the variables become $event_name, $event_data + and $event_defer_errno. There is a new variable $verify_mode, usable in + routers, transports and related events. The tls:cert event is now also + raised for inbound connections, if the main configuration event_action + option is defined. + +TL/06 In test suite, disable OCSP for old versions of openssl which contained + early OCSP support, but no stapling (appears to be less than 1.0.0). + +JH/09 When compiled with OpenSSL and EXPERIMENTAL_CERTNAMES, the checks on + server certificate names available under the smtp transport option + "tls_verify_cert_hostname" now do not permit multi-component wildcard + matches. + +JH/10 Time-related extraction expansions from certificates now use the main + option "timezone" setting for output formatting, and are consistent + between OpenSSL and GnuTLS compilations. Bug 1541. + +JH/11 Fix a crash in mime ACL when meeting a zero-length, quoted or RFC2047- + encoded parameter in the incoming message. Bug 1558. + +JH/12 Bug 1527: Autogrow buffer used in reading spool files. Since they now + include certificate info, eximon was claiming there were spoolfile + syntax errors. + +JH/13 Bug 1521: Fix ldap lookup for single-attr request, multiple-attr return. + +JH/14 Log delivery-related information more consistently, using the sequence + "H=<name> [<ip>]" wherever possible. + +TL/07 Bug 1547: Omit RFCs from release. Draft and RFCs have licenses which + are problematic for Debian distribution, omit them from the release + tarball. + +JH/15 Updates and fixes to the EXPERIMENTAL_DSN feature. + +JH/16 Fix string representation of time values on 64bit time_t architectures. + Bug 1561. + +JH/17 Fix a null-indirection in certextract expansions when a nondefault + output list separator was used. + + +Exim version 4.84 +----------------- +TL/01 Bugzilla 1506: Re-add a 'return NULL' to silence complaints from static + checkers that were complaining about end of non-void function with no + return. + +JH/01 Bug 1513: Fix parsing of quoted parameter values in MIME headers. + This was a regression introduced in 4.83 by another bugfix. + +JH/02 Fix broken compilation when EXPERIMENTAL_DSN is enabled. + +TL/02 Bug 1509: Fix exipick for enhanced spoolfile specification used when + EXPERIMENTAL_DSN is enabled. Fix from Wolfgang Breyha. + + +Exim version 4.83 +----------------- + +TF/01 Correctly close the server side of TLS when forking for delivery. + + When a message was received over SMTP with TLS, Exim failed to clear up + the incoming connection properly after forking off the child process to + deliver the message. In some situations the subsequent outgoing + delivery connection happened to have the same fd number as the incoming + connection previously had. Exim would try to use TLS and fail, logging + a "Bad file descriptor" error. + +TF/02 Portability fix for building lookup modules on Solaris when the xpg4 + utilities have not been installed. + +JH/01 Fix memory-handling in use of acl as a conditional; avoid free of + temporary space as the ACL may create new global variables. + +TL/01 LDAP support uses per connection or global context settings, depending + upon the detected version of the libraries at build time. + +TL/02 Experimental Proxy Protocol support: allows a proxied SMTP connection + to extract and use the src ip:port in logging and expansions as if it + were a direct connection from the outside internet. PPv2 support was + updated based on HAProxy spec change in May 2014. + +JH/02 Add ${listextract {number}{list}{success}{fail}}. + +TL/03 Bugzilla 1433: Fix DMARC SEGV with specific From header contents. + Properly escape header and check for NULL return. + +PP/01 Continue incomplete 4.82 PP/19 by fixing docs too: use dns_dnssec_ok + not dns_use_dnssec. + +JH/03 Bugzilla 1157: support log_selector smtp_confirmation for lmtp. + +TL/04 Add verify = header_names_ascii check to reject email with non-ASCII + characters in header names, implemented as a verify condition. + Contributed by Michael Fischer v. Mollard. + +TL/05 Rename SPF condition results err_perm and err_temp to standardized + results permerror and temperror. Previous values are deprecated but + still accepted. In a future release, err_perm and err_temp will be + completely removed, which will be a backward incompatibility if the + ACL tests for either of these two old results. Patch contributed by + user bes-internal on the mailing list. + +JH/04 Add ${utf8clean:} operator. Contributed by Alex Rau. + +JH/05 Bugzilla 305: Log incoming-TLS details on rejects, subject to log + selectors, in both main and reject logs. + +JH/06 Log outbound-TLS and port details, subject to log selectors, for a + failed delivery. + +JH/07 Add malware type "sock" for talking to simple daemon. + +JH/08 Bugzilla 1371: Add tls_{,try_}verify_hosts to smtp transport. + +JH/09 Bugzilla 1431: Support (with limitations) headers_add/headers_remove in + routers/transports under cutthrough routing. + +JH/10 Bugzilla 1005: ACL "condition =" should accept values which are negative + numbers. Touch up "bool" conditional to keep the same definition. + +TL/06 Remove duplicated language in spec file from 4.82 TL/16. + +JH/11 Add dnsdb tlsa lookup. From Todd Lyons. + +JH/12 Expand items in router/transport headers_add or headers_remove lists + individually rather than the list as a whole. Bug 1452. + + Required for reasonable handling of multiple headers_ options when + they may be empty; requires that headers_remove items with embedded + colons must have them doubled (or the list-separator changed). + +TL/07 Add new dmarc expansion variable $dmarc_domain_policy to directly + view the policy declared in the DMARC record. Currently, $dmarc_status + is a combined value of both the record presence and the result of the + analysis. + +JH/13 Fix handling of $tls_cipher et.al. in (non-verify) transport. Bug 1455. + +JH/14 New options dnssec_request_domains, dnssec_require_domains on the + dnslookup router and the smtp transport (applying to the forward + lookup). + +TL/08 Bugzilla 1453: New LDAP "SERVERS=" option allows admin to override list + of ldap servers used for a specific lookup. Patch provided by Heiko + Schlichting. + +JH/18 New options dnssec_lax, dnssec_strict on dnsdb lookups. + New variable $lookup_dnssec_authenticated for observability. + +TL/09 Bugzilla 609: Add -C option to exiqgrep, specify which exim.conf to use. + Patch submitted by Lars Timman. + +JH/19 EXPERIMENTAL_OCSP support under GnuTLS. Bug 1459. + +TL/10 Bugzilla 1454: New -oMm option to pass message reference to Exim. + Requires trusted mode and valid format message id, aborts otherwise. + Patch contributed by Heiko Schlichting. + +JH/20 New expansion variables tls_(in,out)_(our,peer)cert, and expansion item + certextract with support for various fields. Bug 1358. + +JH/21 Observability of OCSP via variables tls_(in,out)_ocsp. Stapling + is requested by default, modifiable by smtp transport option + hosts_request_ocsp. + +JH/22 Expansion operators ${md5:string} and ${sha1:string} can now + operate on certificate variables to give certificate fingerprints + Also new ${sha256:cert_variable}. + +JH/23 The PRDR feature is moved from being Experimental into the mainline. + +TL/11 Bug 1119: fix memory allocation in string_printing2(). Patch from + Christian Aistleitner. + +JH/24 The OCSP stapling feature is moved from Experimental into the mainline. + +TL/12 Bug 1444: Fix improper \r\n sequence handling when writing spool + file. Patch from Wolfgang Breyha. + +JH/25 Expand the coverage of the delivery $host and $host_address to + client authenticators run in verify callout. Bug 1476. + +JH/26 Port service names are now accepted for tls_on_connect_ports, to + align with daemon_smtp_ports. Bug 72. + +TF/03 Fix udpsend. The ip_connectedsocket() function's socket type + support and error reporting did not work properly. + +TL/13 Bug 1495: Exiqgrep check if -C config file specified on cli exists + and is readable. Patch from Andrew Colin Kissa. + +TL/14 Enhance documentation of ${run expansion and how it parses the + commandline after expansion, particularly in the case when an + unquoted variable expansion results in an empty value. + +JH/27 The TLS SNI feature was broken in 4.82. Fix it. + +PP/02 Fix internal collision of T_APL on systems which support RFC3123 + by renaming away from it. Addresses GH issue 15, reported by + Jasper Wallace. + +JH/28 Fix parsing of MIME headers for parameters with quoted semicolons. + +TL/15 SECURITY: prevent double expansion in math comparison functions + (can expand unsanitized data). Not remotely exploitable. + CVE-2014-2972 + + +Exim version 4.82 +----------------- + +PP/01 Add -bI: framework, and -bI:sieve for querying sieve capabilities. + +PP/02 Make -n do something, by making it not do something. + When combined with -bP, the name of an option is not output. + +PP/03 Added tls_dh_min_bits SMTP transport driver option, only honoured + by GnuTLS. + +PP/04 First step towards DNSSEC, provide $sender_host_dnssec for + $sender_host_name and config options to manage this, and basic check + routines. + +PP/05 DSCP support for outbound connections and control modifier for inbound. + +PP/06 Cyrus SASL: set local and remote IP;port properties for driver. + (Only plugin which currently uses this is kerberos4, which nobody should + be using, but we should make it available and other future plugins might + conceivably use it, even though it would break NAT; stuff *should* be + using channel bindings instead). + +PP/07 Handle "exim -L <tag>" to indicate to use syslog with tag as the process + name; added for Sendmail compatibility; requires admin caller. + Handle -G as equivalent to "control = suppress_local_fixups" (we used to + just ignore it); requires trusted caller. + Also parse but ignore: -Ac -Am -X<logfile> + Bugzilla 1117. + +TL/01 Bugzilla 1258 - Refactor MAIL FROM optional args processing. + +TL/02 Add +smtp_confirmation as a default logging option. + +TL/03 Bugzilla 198 - Implement remove_header ACL modifier. + Patch by Magnus Holmgren from 2007-02-20. + +TL/04 Bugzilla 1281 - Spec typo. + Bugzilla 1283 - Spec typo. + Bugzilla 1290 - Spec grammar fixes. + +TL/05 Bugzilla 1285 - Spec omission, fix docbook errors for spec.txt creation. + +TL/06 Add Experimental DMARC support using libopendmarc libraries. + +TL/07 Fix an out of order global option causing a segfault. Reported to dev + mailing list by by Dmitry Isaikin. + +JH/01 Bugzilla 1201 & 304 - New cutthrough-delivery feature, with TLS support. + +JH/02 Support "G" suffix to numbers in ${if comparisons. + +PP/08 Handle smtp transport tls_sni option forced-fail for OpenSSL. + +NM/01 Bugzilla 1197 - Spec typo + Bugzilla 1196 - Spec examples corrections + +JH/03 Add expansion operators ${listnamed:name} and ${listcount:string} + +PP/09 Add gnutls_allow_auto_pkcs11 option (was originally called + gnutls_enable_pkcs11, but renamed to more accurately indicate its + function. + +PP/10 Let Linux makefile inherit CFLAGS/CFLAGS_DYNAMIC. + Pulled from Debian 30_dontoverridecflags.dpatch by Andreas Metzler. + +JH/04 Add expansion item ${acl {name}{arg}...}, expansion condition + "acl {{name}{arg}...}", and optional args on acl condition + "acl = name arg..." + +JH/05 Permit multiple router/transport headers_add/remove lines. + +JH/06 Add dnsdb pseudo-lookup "a+" to do an "aaaa" + "a" combination. + +JH/07 Avoid using a waiting database for a single-message-only transport. + Performance patch from Paul Fisher. Bugzilla 1262. + +JH/08 Strip leading/trailing newlines from add_header ACL modifier data. + Bugzilla 884. + +JH/09 Add $headers_added variable, with content from use of ACL modifier + add_header (but not yet added to the message). Bugzilla 199. + +JH/10 Add 8bitmime log_selector, for 8bitmime status on the received line. + Pulled from Bugzilla 817 by Wolfgang Breyha. + +PP/11 SECURITY: protect DKIM DNS decoding from remote exploit. + CVE-2012-5671 + (nb: this is the same fix as in Exim 4.80.1) + +JH/11 Add A= logging on delivery lines, and a client_set_id option on + authenticators. + +JH/12 Add optional authenticated_sender logging to A= and a log_selector + for control. + +PP/12 Unbreak server_set_id for NTLM/SPA auth, broken by 4.80 PP/29. + +PP/13 Dovecot auth: log better reason to rejectlog if Dovecot did not + advertise SMTP AUTH mechanism to us, instead of a generic + protocol violation error. Also, make Exim more robust to bad + data from the Dovecot auth socket. + +TF/01 Fix ultimate retry timeouts for intermittently deliverable recipients. + + When a queue runner is handling a message, Exim first routes the + recipient addresses, during which it prunes them based on the retry + hints database. After that it attempts to deliver the message to + any remaining recipients. It then updates the hints database using + the retry rules. + + So if a recipient address works intermittently, it can get repeatedly + deferred at routing time. The retry hints record remains fresh so the + address never reaches the final cutoff time. + + This is a fairly common occurrence when a user is bumping up against + their storage quota. Exim had some logic in its local delivery code + to deal with this. However it did not apply to per-recipient defers + in remote deliveries, e.g. over LMTP to a separate IMAP message store. + + This change adds a proper retry rule check during routing so that the + final cutoff time is checked against the message's age. We only do + this check if there is an address retry record and there is not a + domain retry record; this implies that previous attempts to handle + the address had the retry_use_local_parts option turned on. We use + this as an approximation for the destination being like a local + delivery, as in LMTP. + + I suspect this new check makes the old local delivery cutoff check + redundant, but I have not verified this so I left the code in place. + +TF/02 Correct gecos expansion when From: is a prefix of the username. + + Test 0254 submits a message to Exim with the header + + Resent-From: f + + When I ran the test suite under the user fanf2, Exim expanded + the header to contain my full name, whereas it should have added + a Resent-Sender: header. It erroneously treats any prefix of the + username as equal to the username. + + This change corrects that bug. + +GF/01 DCC debug and logging tidyup + Error conditions log to paniclog rather than rejectlog. + Debug lines prefixed by "DCC: " to remove any ambiguity. + +TF/03 Avoid unnecessary rebuilds of lookup-related code. + +PP/14 Fix OCSP reinitialisation in SNI handling for Exim/TLS as server. + Bug spotted by Jeremy Harris; was flawed since initial commit. + Would have resulted in OCSP responses post-SNI triggering an Exim + NULL dereference and crash. + +JH/13 Add $router_name and $transport_name variables. Bugzilla 308. + +PP/15 Define SIOCGIFCONF_GIVES_ADDR for GNU Hurd. + Bug detection, analysis and fix by Samuel Thibault. + Bugzilla 1331, Debian bug #698092. + +SC/01 Update eximstats to watch out for senders sending 'HELO [IpAddr]' + +JH/14 SMTP PRDR (http://www.eric-a-hall.com/specs/draft-hall-prdr-00.txt). + Server implementation by Todd Lyons, client by JH. + Only enabled when compiled with EXPERIMENTAL_PRDR. A new + config variable "prdr_enable" controls whether the server + advertises the facility. If the client requests PRDR a new + acl_data_smtp_prdr ACL is called once for each recipient, after + the body content is received and before the acl_smtp_data ACL. + The client is controlled by both of: a hosts_try_prdr option + on the smtp transport, and the server advertisement. + Default client logging of deliveries and rejections involving + PRDR are flagged with the string "PRDR". + +PP/16 Fix problems caused by timeouts during quit ACLs trying to double + fclose(). Diagnosis by Todd Lyons. + +PP/17 Update configure.default to handle IPv6 localhost better. + Patch by Alain Williams (plus minor tweaks). + Bugzilla 880. + +PP/18 OpenSSL made graceful with empty tls_verify_certificates setting. + This is now consistent with GnuTLS, and is now documented: the + previous undocumented portable approach to treating the option as + unset was to force an expansion failure. That still works, and + an empty string is now equivalent. + +PP/19 Renamed DNSSEC-enabling option to "dns_dnssec_ok", to make it + clearer that Exim is using the DO (DNSSEC OK) EDNS0 resolver flag, + not performing validation itself. + +PP/20 Added force_command boolean option to pipe transport. + Patch from Nick Koston, of cPanel Inc. + +JH/15 AUTH support on callouts (and hence cutthrough-deliveries). + Bugzilla 321, 823. + +TF/04 Added udpsend ACL modifier and hexquote expansion operator + +PP/21 Fix eximon continuous updating with timestamped log-files. + Broken in a format-string cleanup in 4.80, missed when I repaired the + other false fix of the same issue. + Report and fix from Heiko Schlichting. + Bugzilla 1363. + +PP/22 Guard LDAP TLS usage against Solaris LDAP variant. + Report from Prashanth Katuri. + +PP/23 Support safari_ecdhe_ecdsa_bug for openssl_options. + It's SecureTransport, so affects any MacOS clients which use the + system-integrated TLS libraries, including email clients. + +PP/24 Fix segfault from trying to fprintf() to a NULL stdio FILE* if + using a MIME ACL for non-SMTP local injection. + Report and assistance in diagnosis by Warren Baker. + +TL/08 Adjust exiqgrep to be case-insensitive for sender/receiver. + +JH/16 Fix comparisons for 64b. Bugzilla 1385. + +TL/09 Add expansion variable $authenticated_fail_id to keep track of + last id that failed so it may be referenced in subsequent ACL's. + +TL/10 Bugzilla 1375 - Prevent TLS rebinding in ldap. Patch provided by + Alexander Miroch. + +TL/11 Bugzilla 1382 - Option ldap_require_cert overrides start_tls + ldap library initialization, allowing self-signed CA's to be + used. Also properly sets require_cert option later in code by + using NULL (global ldap config) instead of ldap handle (per + session). Bug diagnosis and testing by alxgomz. + +TL/12 Enhanced documentation in the ratelimit.pl script provided in + the src/util/ subdirectory. + +TL/13 Bug 1031 - Imported transport SQL logging patch from Axel Rau + renamed to Transport Post Delivery Action by Jeremy Harris, as + EXPERIMENTAL_TPDA. + +TL/14 Bugzilla 1217 - Redis lookup support has been added. It is only enabled + when Exim is compiled with EXPERIMENTAL_REDIS. A new config variable + redis_servers = needs to be configured which will be used by the redis + lookup. Patch from Warren Baker, of The Packet Hub. + +TL/15 Fix exiqsumm summary for corner case. Patch provided by Richard Hall. + +TL/16 Bugzilla 1289 - Clarify host/ip processing when have errors looking up a + hostname or reverse DNS when processing a host list. Used suggestions + from multiple comments on this bug. + +TL/17 Bugzilla 1057 - Multiple clamd TCP targets patch from Mark Zealey. + +TL/18 Had previously added a -CONTINUE option to runtest in the test suite. + Missed a few lines, added it to make the runtest require no keyboard + interaction. + +TL/19 Bugzilla 1402 - Test 533 fails if any part of the path to the test suite + contains upper case chars. Make router use caseful_local_part. + +TL/20 Bugzilla 1400 - Add AVOID_GNUTLS_PKCS11 build option. Allows GnuTLS + support when GnuTLS has been built with p11-kit. + + +Exim version 4.80.1 +------------------- + +PP/01 SECURITY: protect DKIM DNS decoding from remote exploit. + CVE-2012-5671 + This, or similar/improved, will also be change PP/11 of 4.82. + + +Exim version 4.80 +----------------- + +PP/01 Handle short writes when writing local log-files. + In practice, only affects FreeBSD (8 onwards). + Bugzilla 1053, with thanks to Dmitry Isaikin. + +NM/01 Bugzilla 949 - Documentation tweak + +NM/02 Bugzilla 1093 - eximstats DATA reject detection regexps + improved. + +NM/03 Bugzilla 1169 - primary_hostname spelling was incorrect in docs. + +PP/02 Implemented gsasl authenticator. + +PP/03 Implemented heimdal_gssapi authenticator with "server_keytab" option. + +PP/04 Local/Makefile support for (AUTH|LOOKUP)_*_PC=foo to use + `pkg-config foo` for cflags/libs. + +PP/05 Swapped $auth1/$auth2 for gsasl GSSAPI mechanism, to be more consistent + with rest of GSASL and with heimdal_gssapi. + +PP/06 Local/Makefile support for USE_(GNUTLS|OPENSSL)_PC=foo to use + `pkg-config foo` for cflags/libs for the TLS implementation. + +PP/07 New expansion variable $tls_bits; Cyrus SASL server connection + properties get this fed in as external SSF. A number of robustness + and debugging improvements to the cyrus_sasl authenticator. + +PP/08 cyrus_sasl server now expands the server_realm option. + +PP/09 Bugzilla 1214 - Log authentication information in reject log. + Patch by Jeremy Harris. + +PP/10 Added dbmjz lookup type. + +PP/11 Let heimdal_gssapi authenticator take a SASL message without an authzid. + +PP/12 MAIL args handles TAB as well as SP, for better interop with + non-compliant senders. + Analysis and variant patch by Todd Lyons. + +NM/04 Bugzilla 1237 - fix cases where printf format usage not indicated + Bug report from Lars Müller <lars@samba.org> (via SUSE), + Patch from Dirk Mueller <dmueller@suse.com> + +PP/13 tls_peerdn now print-escaped for spool files. + Observed some $tls_peerdn in wild which contained \n, which resulted + in spool file corruption. + +PP/14 TLS fixes for OpenSSL: support TLS 1.1 & 1.2; new "openssl_options" + values; set SSL_MODE_AUTO_RETRY so that OpenSSL will retry a read + or write after TLS renegotiation, which otherwise led to messages + "Got SSL error 2". + +TK/01 Bugzilla 1239 - fix DKIM verification when signature was not inserted + as a tracking header (ie: a signed header comes before the signature). + Patch from Wolfgang Breyha. + +JH/01 Bugzilla 660 - Multi-valued attributes from ldap now parseable as a + comma-sep list; embedded commas doubled. + +JH/02 Refactored ACL "verify =" logic to table-driven dispatch. + +PP/15 LDAP: Check for errors of TLS initialisation, to give correct + diagnostics. + Report and patch from Dmitry Banschikov. + +PP/16 Removed "dont_insert_empty_fragments" from "openssl_options". + Removed SSL_clear() after SSL_new() which led to protocol negotiation + failures. We appear to now support TLS1.1+ with Exim. + +PP/17 OpenSSL: new expansion var $tls_sni, which if used in tls_certificate + lets Exim select keys and certificates based upon TLS SNI from client. + Also option tls_sni on SMTP Transports. Also clear $tls_bits correctly + before an outbound SMTP session. New log_selector, +tls_sni. + +PP/18 Bugzilla 1122 - check localhost_number expansion for failure, avoid + NULL dereference. Report and patch from Alun Jones. + +PP/19 DNS resolver init changes for NetBSD compatibility. (Risk of breakage + on less well tested platforms). Obviates NetBSD pkgsrc patch-ac. + Not seeing resolver debug output on NetBSD, but suspect this is a + resolver implementation change. + +PP/20 Revert part of NM/04, it broke log_path containing %D expansions. + Left warnings. Added "eximon gdb" invocation mode. + +PP/21 Defaulting "accept_8bitmime" to true, not false. + +PP/22 Added -bw for inetd wait mode support. + +PP/23 Added PCRE_CONFIG=yes support to Makefile for using pcre-config to + locate the relevant includes and libraries. Made this the default. + +PP/24 Fixed headers_only on smtp transports (was not sending trailing dot). + Bugzilla 1246, report and most of solution from Tomasz Kusy. + +JH/03 ${eval } now uses 64-bit and supports a "g" suffix (like to "k" and "m"). + This may cause build issues on older platforms. + +PP/25 Revamped GnuTLS support, passing tls_require_ciphers to + gnutls_priority_init, ignoring Exim options gnutls_require_kx, + gnutls_require_mac & gnutls_require_protocols (no longer supported). + Added SNI support via GnuTLS too. + Made ${randint:..} supplier available, if using not-too-old GnuTLS. + +PP/26 Added EXPERIMENTAL_OCSP for OpenSSL. + +PP/27 Applied dnsdb SPF support patch from Janne Snabb. + Applied second patch from Janne, implementing suggestion to default + multiple-strings-in-record handling to match SPF spec. + +JH/04 Added expansion variable $tod_epoch_l for a higher-precision time. + +PP/28 Fix DCC dcc_header content corruption (stack memory referenced, + read-only, out of scope). + Patch from Wolfgang Breyha, report from Stuart Northfield. + +PP/29 Fix three issues highlighted by clang analyser static analysis. + Only crash-plausible issue would require the Cambridge-specific + iplookup router and a misconfiguration. + Report from Marcin Mirosław. + +PP/30 Another attempt to deal with PCRE_PRERELEASE, this one less buggy. + +PP/31 %D in printf continues to cause issues (-Wformat=security), so for + now guard some of the printf checks behind WANT_DEEPER_PRINTF_CHECKS. + As part of this, removing so much warning spew let me fix some minor + real issues in debug logging. + +PP/32 GnuTLS was always using default tls_require_ciphers, due to a missing + assignment on my part. Fixed. + +PP/33 Added tls_dh_max_bits option, defaulting to current hard-coded limit + of NSS, for GnuTLS/NSS interop. Problem root cause diagnosis by + Janne Snabb (who went above and beyond: thank you). + +PP/34 Validate tls_require_ciphers on startup, since debugging an invalid + string otherwise requires a connection and a bunch more work and it's + relatively easy to get wrong. Should also expose TLS library linkage + problems. + +PP/35 Pull in <features.h> on Linux, for some portability edge-cases of + 64-bit ${eval} (JH/03). + +PP/36 Define _GNU_SOURCE in exim.h; it's needed for some releases of + GNU libc to support some of the 64-bit stuff, should not lead to + conflicts. Defined before os.h is pulled in, so if a given platform + needs to override this, it can. + +PP/37 Unbreak Cyrus SASL auth: SSF retrieval was incorrect, Exim thought + protection layer was required, which is not implemented. + Bugzilla 1254, patch from Wolfgang Breyha. + +PP/38 Overhaul DH prime handling, supply RFC-specified DH primes as built + into Exim, default to IKE id 23 from RFC 5114 (2048 bit). Make + tls_dhparam take prime identifiers. Also unbreak combination of + OpenSSL+DH_params+TLSSNI. + +PP/39 Disable SSLv2 by default in OpenSSL support. + + +Exim version 4.77 +----------------- + +PP/01 Solaris build fix for Oracle's LDAP libraries. + Bugzilla 1109, patch from Stephen Usher. + +TF/01 HP/UX build fix: avoid arithmetic on a void pointer. + +TK/01 DKIM Verification: Fix relaxed canon for empty headers w/o + whitespace trailer + +TF/02 Fix a couple more cases where we did not log the error message + when unlink() failed. See also change 4.74-TF/03. + +TF/03 Make the exiwhat support code safe for signals. Previously Exim might + lock up or crash if it happened to be inside a call to libc when it + got a SIGUSR1 from exiwhat. + + The SIGUSR1 handler appends the current process status to the process + log which is later printed by exiwhat. It used to use the general + purpose logging code to do this, but several functions it calls are + not safe for signals. + + The new output code in the SIGUSR1 handler is specific to the process + log, and simple enough that it's easy to inspect for signal safety. + Removing some special cases also simplifies the general logging code. + Removing the spurious timestamps from the process log simplifies + exiwhat. + +TF/04 Improved ratelimit ACL condition. + + The /noupdate option has been deprecated in favour of /readonly which + has clearer semantics. The /leaky, /strict, and /readonly update modes + are mutually exclusive. The update mode is no longer included in the + database key; it just determines when the database is updated. (This + means that when you upgrade Exim will forget old rate measurements.) + + Exim now checks that the per_* options are used with an update mode that + makes sense for the current ACL. For example, when Exim is processing a + message (e.g. acl_smtp_rcpt or acl_smtp_data, etc.) you can specify + per_mail/leaky or per_mail/strict; otherwise (e.g. in acl_smtp_helo) you + must specify per_mail/readonly. If you omit the update mode it defaults to + /leaky where that makes sense (as before) or /readonly where required. + + The /noupdate option is now undocumented but still supported for + backwards compatibility. It is equivalent to /readonly except that in + ACLs where /readonly is required you may specify /leaky/noupdate or + /strict/noupdate which are treated the same as /readonly. + + A useful new feature is the /count= option. This is a generalization + of the per_byte option, so that you can measure the throughput of other + aggregate values. For example, the per_byte option is now equivalent + to per_mail/count=${if >{0}{$message_size} {0} {$message_size} }. + + The per_rcpt option has been generalized using the /count= mechanism + (though it's more complicated than the per_byte equivalence). When it is + used in acl_smtp_rcpt, the per_rcpt option adds recipients to the + measured rate one at a time; if it is used later (e.g. in acl_smtp_data) + or in a non-SMTP ACL it adds all the recipients in one go. (The latter + /count=$recipients_count behaviour used to work only in non-SMTP ACLs.) + Note that using per_rcpt with a non-readonly update mode in more than + one ACL will cause the recipients to be double-counted. (The per_mail + and per_byte options don't have this problem.) + + The handling of very low rates has changed slightly. If the computed rate + is less than the event's count (usually one) then this event is the first + after a long gap. In this case the rate is set to the same as this event's + count, so that the first message of a spam run is counted properly. + + The major new feature is a mechanism for counting the rate of unique + events. The new per_addr option counts the number of different + recipients that someone has sent messages to in the last time period. It + behaves like per_rcpt if all the recipient addresses are different, but + duplicate recipient addresses do not increase the measured rate. Like + the /count= option this is a general mechanism, so the per_addr option + is equivalent to per_rcpt/unique=$local_part@$domain. You can, for + example, measure the rate that a client uses different sender addresses + with the options per_mail/unique=$sender_address. There are further + details in the main documentation. + +TF/05 Removed obsolete $Cambridge$ CVS revision strings. + +TF/06 Removed a few PCRE remnants. + +TF/07 Automatically extract Exim's version number from tags in the git + repository when doing development or release builds. + +PP/02 Raise smtp_cmd_buffer_size to 16kB. + Bugzilla 879. Patch from Paul Fisher. + +PP/03 Implement SSL-on-connect outbound with protocol=smtps on smtp transport. + Heavily based on revision 40f9a89a from Simon Arlott's tree. + Bugzilla 97. + +PP/04 Use .dylib instead of .so for dynamic library loading on MacOS. + +PP/05 Variable $av_failed, true if the AV scanner deferred. + Bugzilla 1078. Patch from John Horne. + +PP/06 Stop make process more reliably on build failure. + Bugzilla 1087. Patch from Heiko Schlittermann. + +PP/07 Make maildir_use_size_file an _expandable_ boolean. + Bugzilla 1089. Patch from Heiko Schlittermann. + +PP/08 Handle ${run} returning more data than OS pipe buffer size. + Bugzilla 1131. Patch from Holger Weiß. + +PP/09 Handle IPv6 addresses with SPF. + Bugzilla 860. Patch from Wolfgang Breyha. + +PP/10 GnuTLS: support TLS 1.2 & 1.1. + Bugzilla 1156. + Use gnutls_certificate_verify_peers2() [patch from Andreas Metzler]. + Bugzilla 1095. + +PP/11 match_* no longer expand right-hand-side by default. + New compile-time build option, EXPAND_LISTMATCH_RHS. + New expansion conditions, "inlist", "inlisti". + +PP/12 fix uninitialised greeting string from PP/03 (smtps client support). + +PP/13 shell and compiler warnings fixes for RC1-RC4 changes. + +PP/14 fix log_write() format string regression from TF/03. + Bugzilla 1152. Patch from Dmitry Isaikin. + + +Exim version 4.76 +----------------- + +PP/01 The new ldap_require_cert option would segfault if used. Fixed. + +PP/02 Harmonised TLS library version reporting; only show if debugging. + Layout now matches that introduced for other libraries in 4.74 PP/03. + +PP/03 New openssl_options items: no_sslv2 no_sslv3 no_ticket no_tlsv1 + +PP/04 New "dns_use_edns0" global option. + +PP/05 Don't segfault on misconfiguration of ref:name exim-user as uid. + Bugzilla 1098. + +PP/06 Extra paranoia around buffer usage at the STARTTLS transition. + nb: Exim is not vulnerable to http://www.kb.cert.org/vuls/id/555316 + +TK/01 Updated PolarSSL code to 0.14.2. + Bugzilla 1097. Patch from Andreas Metzler. + +PP/07 Catch divide-by-zero in ${eval:...}. + Fixes bugzilla 1102. + +PP/08 Condition negation of bool{}/bool_lax{} did not negate. Fixed. + Bugzilla 1104. + +TK/02 Bugzilla 1106: CVE-2011-1764 - DKIM log line was subject to a + format-string attack -- SECURITY: remote arbitrary code execution. + +TK/03 SECURITY - DKIM signature header parsing was double-expanded, second + time unintentionally subject to list matching rules, letting the header + cause arbitrary Exim lookups (of items which can occur in lists, *not* + arbitrary string expansion). This allowed for information disclosure. + +PP/09 Fix another SIGFPE (x86) in ${eval:...} expansion, this time related to + INT_MIN/-1 -- value coerced to INT_MAX. + + +Exim version 4.75 +----------------- + +NM/01 Workaround for PCRE version dependency in version reporting + Bugzilla 1073 + +TF/01 Update valgrind.h and memcheck.h to copies from valgrind-3.6.0. + This fixes portability to compilers other than gcc, notably + Solaris CC and HP-UX CC. Fixes Bugzilla 1050. + +TF/02 Bugzilla 139: Avoid using the += operator in the modular lookup + makefiles for portability to HP-UX and POSIX correctness. + +PP/01 Permit LOOKUP_foo enabling on the make command-line. + Also via indented variable definition in the Makefile. + (Debugging by Oliver Heesakkers). + +PP/02 Restore caching of spamd results with expanded spamd_address. + Patch from author of expandable spamd_address patch, Wolfgang Breyha. + +PP/03 Build issue: lookups-Makefile now exports LC_ALL=C + Improves build reliability. Fix from: Frank Elsner + +NM/02 Fix wide character breakage in the rfc2047 coding + Fixes bug 1064. Patch from Andrey N. Oktyabrski + +NM/03 Allow underscore in dnslist lookups + Fixes bug 1026. Patch from Graeme Fowler + +PP/04 Bugzilla 230: Support TLS-enabled LDAP (in addition to ldaps). + Code patches from Adam Ciarcinski of NetBSD. + +NM/04 Fixed exiqgrep to cope with mailq missing size issue + Fixes bug 943. + +PP/05 Bugzilla 1083: when lookup expansion defers, escape the output which + is logged, to avoid truncation. Patch from John Horne. + +PP/06 Bugzilla 1042: implement freeze_signal on pipe transports. + Patch from Jakob Hirsch. + +PP/07 Bugzilla 1061: restrict error messages sent over SMTP to not reveal + SQL string expansion failure details. + Patch from Andrey Oktyabrski. + +PP/08 Bugzilla 486: implement %M datestamping in log filenames. + Patch from Simon Arlott. + +PP/09 New lookups functionality failed to compile on old gcc which rejects + extern declarations in function scope. + Patch from Oliver Fleischmann + +PP/10 Use sig_atomic_t for flags set from signal handlers. + Check getgroups() return and improve debugging. + Fixed developed for diagnosis in bug 927 (which turned out to be + a kernel bug). + +PP/11 Bugzilla 1055: Update $message_linecount for maildir_tag. + Patch from Mark Zealey. + +PP/12 Bugzilla 1056: Improved spamd server selection. + Patch from Mark Zealey. + +PP/13 Bugzilla 1086: Deal with maildir quota file races. + Based on patch from Heiko Schlittermann. + +PP/14 Bugzilla 1019: DKIM multiple signature generation fix. + Patch from Uwe Doering, sign-off by Michael Haardt. + +NM/05 Fix to spam.c to accommodate older gcc versions which dislike + variable declaration deep within a block. Bug and patch from + Dennis Davis. + +PP/15 lookups-Makefile IRIX compatibility coercion. + +PP/16 Make DISABLE_DKIM build knob functional. + +NM/06 Bugzilla 968: child_open_uid: restore default SIGPIPE handler + Patch by Simon Arlott + +TF/03 Fix valgrind.h portability to C89 compilers that do not support + variable argument macros. Our copy now differs from upstream. + + +Exim version 4.74 +----------------- + +TF/01 Failure to get a lock on a hints database can have serious + consequences so log it to the panic log. + +TF/02 Log LMTP confirmation messages in the same way as SMTP, + controlled using the smtp_confirmation log selector. + +TF/03 Include the error message when we fail to unlink a spool file. + +DW/01 Bugzilla 139: Support dynamically loaded lookups as modules. + With thanks to Steve Haslam, Johannes Berg & Serge Demonchaux + for maintaining out-of-tree patches for some time. + +PP/01 Bugzilla 139: Documentation and portability issues. + Avoid GNU Makefile-isms, let Exim continue to build on BSD. + Handle per-OS dynamic-module compilation flags. + +PP/02 Let /dev/null have normal permissions. + The 4.73 fixes were a little too stringent and complained about the + permissions on /dev/null. Exempt it from some checks. + Reported by Andreas M. Kirchwitz. + +PP/03 Report version information for many libraries, including + Exim version information for dynamically loaded libraries. Created + version.h, now support a version extension string for distributors + who patch heavily. Dynamic module ABI change. + +PP/04 CVE-2011-0017 - check return value of setuid/setgid. This is a + privilege escalation vulnerability whereby the Exim run-time user + can cause root to append content of the attacker's choosing to + arbitrary files. + +PP/05 Bugzilla 1041: merged DCC maintainer's fixes for return code. + (Wolfgang Breyha) + +PP/06 Bugzilla 1071: fix delivery logging with untrusted macros. + If dropping privileges for untrusted macros, we disabled normal logging + on the basis that it would fail; for the Exim run-time user, this is not + the case, and it resulted in successful deliveries going unlogged. + Fixed. Reported by Andreas Metzler. + + +Exim version 4.73 +----------------- + +PP/01 Date: & Message-Id: revert to normally being appended to a message, + only prepend for the Resent-* case. Fixes regression introduced in + Exim 4.70 by NM/22 for Bugzilla 607. + +PP/02 Include check_rfc2047_length in configure.default because we're seeing + increasing numbers of administrators be bitten by this. + +JJ/01 Added DISABLE_DKIM and comment to src/EDITME + +PP/03 Bugzilla 994: added openssl_options main configuration option. + +PP/04 Bugzilla 995: provide better SSL diagnostics on failed reads. + +PP/05 Bugzilla 834: provide a permit_coredump option for pipe transports. + +PP/06 Adjust NTLM authentication to handle SASL Initial Response. + +PP/07 If TLS negotiated an anonymous cipher, we could end up with SSL but + without a peer certificate, leading to a segfault because of an + assumption that peers always have certificates. Be a little more + paranoid. Problem reported by Martin Tscholak. + +PP/08 Bugzilla 926: switch ClamAV to use the new zINSTREAM API for content + filtering; old API available if built with WITH_OLD_CLAMAV_STREAM=yes + NB: ClamAV planning to remove STREAM in "middle of 2010". + CL also introduces -bmalware, various -d+acl logging additions and + more caution in buffer sizes. + +PP/09 Implemented reverse_ip expansion operator. + +PP/10 Bugzilla 937: provide a "debug" ACL control. + +PP/11 Bugzilla 922: Documentation dusting, patch provided by John Horne. + +PP/12 Bugzilla 973: Implement --version. + +PP/13 Bugzilla 752: Refuse to build/run if Exim user is root/0. + +PP/14 Build without WITH_CONTENT_SCAN. Path from Andreas Metzler. + +PP/15 Bugzilla 816: support multiple condition rules on Routers. + +PP/16 Add bool_lax{} expansion operator and use that for combining multiple + condition rules, instead of bool{}. Make both bool{} and bool_lax{} + ignore trailing whitespace. + +JJ/02 prevent non-panic DKIM error from being sent to paniclog + +JJ/03 added tcp_wrappers_daemon_name to allow host entries other than + "exim" to be used + +PP/17 Fix malware regression for cmdline scanner introduced in PP/08. + Notification from Dr Andrew Aitchison. + +PP/18 Change ClamAV response parsing to be more robust and to handle ClamAV's + ExtendedDetectionInfo response format. + Notification from John Horne. + +PP/19 OpenSSL 1.0.0a compatibility const-ness change, should be backwards + compatible. + +PP/20 Added a CONTRIBUTING file. Fixed the documentation build to use http: + XSL and documented dependency on system catalogs, with examples of how + it normally works. + +DW/21 Added Valgrind hooks in store.c to help it capture out-of-bounds store + access. + +DW/22 Bugzilla 1044: CVE-2010-4345 - partial fix: restrict default behaviour + of CONFIGURE_OWNER and CONFIGURE_GROUP options to no longer allow a + configuration file which is writeable by the Exim user or group. + +DW/23 Bugzilla 1044: CVE-2010-4345 - part two: extend checks for writeability + of configuration files to cover files specified with the -C option if + they are going to be used with root privileges, not just the default + configuration file. + +DW/24 Bugzilla 1044: CVE-2010-4345 - part three: remove ALT_CONFIG_ROOT_ONLY + option (effectively making it always true). + +DW/25 Add TRUSTED_CONFIG_PREFIX_FILE option to allow alternative configuration + files to be used while preserving root privileges. + +DW/26 Set FD_CLOEXEC on SMTP sockets after forking in the daemon, to ensure + that rogue child processes cannot use them. + +PP/27 Bugzilla 1047: change the default for system_filter_user to be the Exim + run-time user, instead of root. + +PP/28 Add WHITELIST_D_MACROS option to let some macros be overridden by the + Exim run-time user without dropping privileges. + +DW/29 Remove use of va_copy() which breaks pre-C99 systems. Duplicate the + result string, instead of calling string_vformat() twice with the same + arguments. + +DW/30 Allow TRUSTED_CONFIG_PREFIX_FILE only for Exim or CONFIGURE_OWNER, not + for other users. Others should always drop root privileges if they use + -C on the command line, even for a whitelisted configure file. + +DW/31 Turn TRUSTED_CONFIG_PREFIX_FILE into TRUSTED_CONFIG_FILE. No prefixes. + +NM/01 Fixed bug #1002 - Message loss when using multiple deliveries + + +Exim version 4.72 +----------------- + +JJ/01 installed exipick 20100104.1, adding $max_received_linelength, + $data_path, and $header_path variables; fixed documentation bugs and + typos + +JJ/02 installed exipick 20100222.0, added --input-dir and --finput to allow + exipick to access non-standard spools, including the "frozen" queue + (Finput) + +NM/01 Bugzilla 965: Support mysql stored procedures. + Patch from Alain Williams + +NM/02 Bugzilla 961: Spacing fix (syntax error) on Makefile directives for NetBSD + +NM/03 Bugzilla 955: Documentation fix for max_rcpts. + Patch from Andreas Metzler + +NM/04 Bugzilla 954: Fix for unknown responses from Dovecot authenticator. + Patch from Kirill Miazine + +NM/05 Bugzilla 671: Added umask to procmail example. + +JJ/03 installed exipick 20100323.0, fixing doc bug + +NM/06 Bugzilla 988: CVE-2010-2023 - prevent hardlink attack on sticky mail + directory. Notification and patch from Dan Rosenberg. + +TK/01 PDKIM: Upgrade PolarSSL files to upstream version 0.12.1. + +TK/02 Improve log output when DKIM signing operation fails. + +MH/01 Treat the transport option dkim_domain as a colon separated + list, not as a single string, and sign the message with each element, + omitting multiple occurences of the same signer. + +NM/07 Null terminate DKIM strings, Null initialise DKIM variable + Bugzilla 985, 986. Patch by Simon Arlott + +NM/08 Bugzilla 967. dnsdb DNS TXT record bug fix (DKIM-related) + Patch by Simon Arlott + +PP/01 Bugzilla 989: CVE-2010-2024 - work round race condition on + MBX locking. Notification from Dan Rosenberg. + + +Exim version 4.71 +----------------- + +TK/01 Bugzilla 912: Fix DKIM segfault on empty headers/body. + +NM/01 Bugzilla 913: Documentation fix for gnutls_* options. + +NM/02 Bugzilla 722: Documentation for randint. Better randomness defaults. + +NM/03 Bugzilla 847: Enable DNSDB lookup by default. + +NM/04 Bugzilla 915: Flag broken perl installation during build. + + +Exim version 4.70 +----------------- + +TK/01 Added patch by Johannes Berg that expands the main option + "spamd_address" if it starts with a dollar sign. + +TK/02 Write list of recipients to X-Envelope-Sender header when building + the mbox-format spool file for content scanning (suggested by Jakob + Hirsch). + +TK/03 Added patch by Wolfgang Breyha that adds experimental DCC + (http://www.dcc-servers.net/) support via dccifd. Activated by + setting EXPERIMENTAL_DCC=yes in Local/Makefile. + +TK/04 Bugzilla 673: Add f-protd malware scanner support. Patch submitted + by Mark Daniel Reidel <mr@df.eu>. + +NM/01 Bugzilla 657: Embedded PCRE removed from the exim source tree. + When building exim an external PCRE library is now needed - + PCRE is a system library on the majority of modern systems. + See entry on PCRE_LIBS in EDITME file. + +NM/02 Bugzilla 646: Removed unwanted C/R in Dovecot authenticator + conversation. Added nologin parameter to request. + Patch contributed by Kirill Miazine. + +TF/01 Do not log submission mode rewrites if they do not change the address. + +TF/02 Bugzilla 662: Fix stack corruption before exec() in daemon.c. + +NM/03 Bugzilla 602: exicyclog now handles panic log, and creates empty + log files in place. Contributed by Roberto Lima. + +NM/04 Bugzilla 667: Close socket used by dovecot authenticator. + +TF/03 Bugzilla 615: When checking the local_parts router precondition + after a local_part_suffix or local_part_prefix option, Exim now + does not use the address's named list lookup cache, since this + contains cached lookups for the whole local part. + +NM/05 Bugzilla 521: Integrated SPF Best Guess support contributed by + Robert Millan. Documentation is in experimental-spec.txt. + +TF/04 Bugzilla 668: Fix parallel build (make -j). + +NM/05.2 Bugzilla 437: Prevent Maildir aux files being created with mode 000. + +NM/05.3 Bugzilla 598: Improvement to Dovecot authenticator handling. + Patch provided by Jan Srzednicki. + +TF/05 Leading white space used to be stripped from $spam_report which + wrecked the formatting. Now it is preserved. + +TF/06 Save $spam_score, $spam_bar, and $spam_report in spool files, so + that they are available at delivery time. + +TF/07 Fix the way ${extract is skipped in the untaken branch of a conditional. + +TF/08 TLS error reporting now respects the incoming_interface and + incoming_port log selectors. + +TF/09 Produce a more useful error message if an SMTP transport's hosts + setting expands to an empty string. + +NM/06 Bugzilla 744: EXPN did not work under TLS. + Patch provided by Phil Pennock. + +NM/07 Bugzilla 769: Extraneous comma in usage fprintf + Patch provided by Richard Godbee. + +NM/08 Fixed erroneous documentation references to smtp_notquit_acl to be + acl_smtp_notquit, added index entry. + +NM/09 Bugzilla 787: Potential buffer overflow in string_format. + Patch provided by Eugene Bujak. + +NM/10 Bugzilla 770: Problem on some platforms modifying the len parameter to + accept(). Patch provided by Maxim Dounin. + +NM/11 Bugzilla 749: Preserve old behaviour of blanks comparing equal to zero. + Patch provided by Phil Pennock. + +NM/12 Bugzilla 497: Correct behaviour of exiwhat when no config exists. + +NM/13 Bugzilla 590: Correct handling of Resent-Date headers. + Patch provided by Brad "anomie" Jorsch. + +NM/14 Bugzilla 622: Added timeout setting to transport filter. + Patch provided by Dean Brooks. + +TK/05 Add native DKIM support (does not depend on external libraries). + +NM/15 Bugzilla 854: Removed code that symlinks to pcre as its no longer useful. + Patch provided by Graeme Fowler. + +NM/16 Bugzilla 851: Documentation example syntax fix. + +NM/17 Changed NOTICE file to remove references to embedded PCRE. + +NM/18 Bugzilla 894: Fix issue with very long lines including comments in + lsearch. + +NM/19 Bugzilla 745: TLS version reporting. + Patch provided by Phil Pennock. + +NM/20 Bugzilla 167: bool: condition support. + Patch provided by Phil Pennock. + +NM/21 Bugzilla 665: gnutls_compat_mode to allow compatibility with broken + clients. Patch provided by Phil Pennock. + +NM/22 Bugzilla 607: prepend (not append) Resent-Message-ID and Resent-Date. + Patch provided by Brad "anomie" Jorsch. + +NM/23 Bugzilla 687: Fix misparses in eximstats. + Patch provided by Heiko Schlittermann. + +NM/24 Bugzilla 688: Fix exiwhat to handle log_selector = +pid. + Patch provided by Heiko Schlittermann. + +NM/25 Bugzilla 727: Use transport mode as default mode for maildirsize file. + plus update to original patch. + +NM/26 Bugzilla 799: Documentation correction for ratelimit. + +NM/27 Bugzilla 802: Improvements to local interface IP addr detection. + Patch provided by David Brownlee. + +NM/28 Bugzilla 807: Improvements to LMTP delivery logging. + +NM/29 Bugzilla 862, 866, 875: Documentation bugfixes. + +NM/30 Bugzilla 888: TLS documentation bugfixes. + +NM/31 Bugzilla 896: Dovecot buffer overrun fix. + +NM/32 Bugzilla 889: Change all instances of "expr" in shell scripts to "expr --" + Unlike the original bugzilla I have changed all shell scripts in src tree. + +NM/33 Bugzilla 898: Transport filter timeout fix. + Patch by Todd Rinaldo. + +NM/34 Bugzilla 901: Fix sign/unsigned and UTF mismatches. + Patch by Serge Demonchaux. + +NM/35 Bugzilla 39: Base64 decode bug fixes. + Patch by Jakob Hirsch. + +NM/36 Bugzilla 909: Correct connect() call in dcc code. + +NM/37 Bugzilla 910: Correct issue with relaxed/simple handling. + +NM/38 Bugzilla 908: Removed NetBSD3 support as no longer needed. + +NM/39 Bugzilla 911: Fixed MakeLinks build script. + + +Exim version 4.69 +----------------- + +TK/01 Add preliminary DKIM support. Currently requires a forked version of + ALT-N's libdkim that I have put here: + http://duncanthrax.net/exim-experimental/ + + Note to Michael Haardt: I had to rename some vars in sieve.c. They + were called 'true' and it seems that C99 defines that as a reserved + keyword to be used with 'bool' variable types. That means you could + not include C99-style headers which use bools without triggering + build errors in sieve.c. + +NM/01 Bugzilla 592: --help option is handled incorrectly if exim is invoked + as mailq or other aliases. Changed the --help handling significantly + to do whats expected. exim_usage() emits usage/help information. + +SC/01 Added the -bylocaldomain option to eximstats. + +NM/02 Bugzilla 619: Defended against bad data coming back from gethostbyaddr. + +NM/03 Bugzilla 613: Documentation fix for acl_not_smtp. + +NM/04 Bugzilla 628: PCRE update to 7.4 (work done by John Hall). + + +Exim version 4.68 +----------------- + +PH/01 Another patch from the Sieve maintainer. + +PH/02 When an IPv6 address is converted to a string for single-key lookup + in an address list (e.g. for an item such as "net24-dbm;/net/works"), + dots are used instead of colons so that keys in lsearch files need not + contain colons. This was done some time before quoting was made available + in lsearch files. However, iplsearch files do require colons in IPv6 keys + (notated using the quote facility) so as to distinguish them from IPv4 + keys. This meant that lookups for IP addresses in host lists did not work + for iplsearch lookups. + + This has been fixed by arranging for IPv6 addresses to be expressed with + colons if the lookup type is iplsearch. This is not incompatible, because + previously such lookups could never work. + + The situation is now rather anomalous, since one *can* have colons in + ordinary lsearch keys. However, making the change in all cases is + incompatible and would probably break a number of configurations. + +TK/01 Change PRVS address formatting scheme to reflect latests BATV draft + version. + +MH/01 The "spam" ACL condition code contained a sscanf() call with a %s + conversion specification without a maximum field width, thereby enabling + a rogue spamd server to cause a buffer overflow. While nobody in their + right mind would setup Exim to query an untrusted spamd server, an + attacker that gains access to a server running spamd could potentially + exploit this vulnerability to run arbitrary code as the Exim user. + +TK/02 Bugzilla 502: Apply patch to make the SPF-Received: header use + $primary_hostname instead of what libspf2 thinks the hosts name is. + +MH/02 The dsearch lookup now uses lstat(2) instead of stat(2) to look for + a directory entry by the name of the lookup key. Previously, if a + symlink pointed to a non-existing file or a file in a directory that + Exim lacked permissions to read, a lookup for a key matching that + symlink would fail. Now it is enough that a matching directory entry + exists, symlink or not. (Bugzilla 503.) + +PH/03 The body_linecount and body_zerocount variables are now exported in the + local_scan API. + +PH/04 Added the $dnslist_matched variable. + +PH/05 Unset $tls_cipher and $tls_peerdn before making a connection as a client. + This means they are set thereafter only if the connection becomes + encrypted. + +PH/06 Added the client_condition to authenticators so that some can be skipped + by clients under certain conditions. + +PH/07 The error message for a badly-placed control=no_multiline_responses left + "_responses" off the end of the name. + +PH/08 Added -Mvc to output a copy of a message in RFC 2822 format. + +PH/09 Tidied the code for creating ratelimiting keys, creating them explicitly + (without spaces) instead of just copying the configuration text. + +PH/10 Added the /noupdate option to the ratelimit ACL condition. + +PH/11 Added $max_received_linelength. + +PH/12 Added +ignore_defer and +include_defer to host lists. + +PH/13 Installed PCRE version 7.2. This needed some changes because of the new + way in which PCRE > 7.0 is built. + +PH/14 Implemented queue_only_load_latch. + +PH/15 Removed an incorrect (int) cast when reading the value of SIZE in a + MAIL command. The effect was to mangle the value on 64-bit systems. + +PH/16 Another patch from the Sieve maintainer. + +PH/17 Added the NOTQUIT ACL, based on a patch from Ted Cooper. + +PH/18 If a system quota error occurred while trying to create the file for + a maildir delivery, the message "Mailbox is full" was not appended to the + bounce if the delivery eventually timed out. Change 4.67/27 below applied + only to a quota excession during the actual writing of the file. + +PH/19 It seems that peer DN values may contain newlines (and other non-printing + characters?) which causes problems in log lines. The DN values are now + passed through string_printing() before being added to log lines. + +PH/20 Added the "servers=" facility to MySQL and PostgreSQL lookups. (Oracle + and InterBase are left for another time.) + +PH/21 Added message_body_newlines option. + +PH/22 Guard against possible overflow in moan_check_errorcopy(). + +PH/23 POSIX allows open() to be a macro; guard against that. + +PH/24 If the recipient of an error message contained an @ in the local part + (suitably quoted, of course), incorrect values were put in $domain and + $local_part during the evaluation of errors_copy. + + +Exim version 4.67 +----------------- + +MH/01 Fix for bug #448, segfault in Dovecot authenticator when interface_address + is unset (happens when testing with -bh and -oMi isn't used). Thanks to + Jan Srzednicki. + +PH/01 Added a new log selector smtp_no_mail, to log SMTP sessions that do not + issue a MAIL command. + +PH/02 In an ACL statement such as + + deny dnslists = X!=127.0.0.2 : X=127.0.0.2 + + if a client was not listed at all, or was listed with a value other than + 127.0.0.2, in the X list, but was listed with 127.0.0.2 in the Y list, + the condition was not true (as it should be), so access was not denied. + The bug was that the ! inversion was incorrectly passed on to the second + item. This has been fixed. + +PH/03 Added additional dnslists conditions == and =& which are different from + = and & when the dns lookup returns more than one IP address. + +PH/04 Added gnutls_require_{kx,mac,protocols} to give more control over the + cipher suites used by GnuTLS. These options are ignored by OpenSSL. + +PH/05 After discussion on the list, added a compile time option ENABLE_DISABLE_ + FSYNC, which compiles an option called disable_fsync that allows for + bypassing fsync(). The documentation is heavily laced with warnings. + +SC/01 Updated eximstats to collate all SpamAssassin rejects into one bucket. + +PH/06 Some tidies to the infrastructure of the Test Suite that is concerned + with the auxiliary C programs that it uses: (1) Arrange for BIND_8_COMPAT + to be defined when compiling on OSX (Darwin); (2) Tidies to the Makefile, + including adding "make clean"; (3) Added -fPIC when compiling the test + dynamically loaded module, to get rid of a warning. + +MH/02 Fix for bug #451, causing paniclog entries to be written if a bounce + message fails, move_frozen_messages = true and ignore_bounce_errors_after + = 0s. The bug is otherwise harmless. + +PH/07 There was a bug in the dovecot authenticator such that the value of + $auth1 could be overwritten, and so not correctly preserved, after a + successful authentication. This usually meant that the value preserved by + the server_setid option was incorrect. + +PH/08 Added $smtp_count_at_connection_start, deliberately with a long name. + +PH/09 Installed PCRE release 7.0. + +PH/10 The acl_not_smtp_start ACL was, contrary to the documentation, not being + run for batched SMTP input. It is now run at the start of every message + in the batch. While fixing this I discovered that the process information + (output by running exiwhat) was not always getting set for -bs and -bS + input. This is fixed, and it now also says "batched" for BSMTP. + +PH/11 Added control=no_pipelining. + +PH/12 Added $sending_ip_address and $sending_port (mostly Magnus Holmgren's + patch, slightly modified), and move the expansion of helo_data till after + the connection is made in the smtp transport (so it can use these + values). + +PH/13 Added ${rfc2047d: to decoded RFC 2047 strings. + +PH/14 Added log_selector = +pid. + +PH/15 Flush SMTP output before delaying, unless control=no_delay_flush is set. + +PH/16 Add ${if forany and ${if forall. + +PH/17 Added dsn_from option to vary the From: line in DSNs. + +PH/18 Flush SMTP output before performing a callout, unless control = + no_callout_flush is set. + +PH/19 Change 4.64/PH/36 introduced a bug: when address_retry_include_sender + was true (the default) a successful delivery failed to delete the retry + item, thus causing premature timeout of the address. The bug is now + fixed. + +PH/20 Added hosts_avoid_pipelining to the smtp transport. + +PH/21 Long custom messages for fakedefer and fakereject are now split up + into multiline responses in the same way that messages for "deny" and + other ACL rejections are. + +PH/22 Applied Jori Hamalainen's speed-up changes and typo fixes to exigrep, + with slight modification. + +PH/23 Applied sieve patches from the maintainer "tracking the latest notify + draft, changing the syntax and factoring some duplicate code". + +PH/24 When the log selector "outgoing_port" was set, the port was shown as -1 + for deliveries of the second and subsequent messages over the same SMTP + connection. + +PH/25 Applied Magnus Holmgren's patch for ${addresses, ${map, ${filter, and + ${reduce, with only minor "tidies". + +SC/02 Applied Daniel Tiefnig's patch to improve the '($parent) =' pattern match. + +PH/26 Added a "continue" ACL modifier that does nothing, for the benefit of its + expansion side effects. + +PH/27 When a message times out after an over-quota error from an Exim-imposed + quota, the bounce message says "mailbox is full". This message was not + being given when it was a system quota that was exceeded. It now should + be the same. + +MH/03 Made $recipients available in local_scan(). local_scan() already has + better access to the recipient list through recipients_list[], but + $recipients can be useful in postmaster-provided expansion strings. + +PH/28 The $smtp_command and $smtp_command_argument variables were not correct + in the case of a MAIL command with additional options following the + address, for example: MAIL FROM:<foo@bar> SIZE=1234. The option settings + were accidentally chopped off. + +PH/29 SMTP synchronization checks are implemented when a command is read - + there is a check that no more input is waiting when there shouldn't be + any. However, for some commands, a delay in an ACL can mean that it is + some time before the response is written. In this time, more input might + arrive, invalidly. So now there are extra checks after an ACL has run for + HELO/EHLO and after the predata ACL, and likewise for MAIL and RCPT when + pipelining has not been advertised. + +PH/30 MH's patch to allow iscntrl() characters to be list separators. + +PH/31 Unlike :fail:, a custom message specified with :defer: was not being + returned in the SMTP response when smtp_return_error_details was false. + This has been fixed. + +PH/32 Change the Dovecot authenticator to use read() and write() on the socket + instead of the C I/O that was originally supplied, because problems were + reported on Solaris. + +PH/33 Compile failed with OpenSSL 0.9.8e. This was due to a coding error in + Exim which did not show up earlier: it was assuming that a call to + SSL_CTX_set_info_callback() might give an error value. In fact, there is + no error. In previous releases of OpenSSL, SSL_CTX_set_info_callback() + was a macro that became an assignment, so it seemed to work. This has + changed to a proper function call with a void return, hence the compile + error. Exim's code has been fixed. + +PH/34 Change HDA_SIZE in oracle.c from 256 to 512. This is needed for 64-bit + cpus. + +PH/35 Applied a patch from the Sieve maintainer which fixes a bug in "notify". + +PH/36 Applied John Jetmore's patch to add -v functionality to exigrep. + +PH/37 If a message is not accepted after it has had an id assigned (e.g. + because it turns out to be too big or there is a timeout) there is no + "Completed" line in the log. When some messages of this type were + selected by exigrep, they were listed as "not completed". Others were + picked up by some special patterns. I have improved the selection + criteria to be more general. + +PH/38 The host_find_failed option in the manualroute router can now be set + to "ignore", to completely ignore a host whose IP address cannot be + found. If all hosts are ignored, the behaviour is controlled by the new + host_all_ignored option. + +PH/39 In a list of hosts for manualroute, if one item (either because of multi- + homing or because of multiple MX records with /mx) generated more than + one IP address, and the following item turned out to be the local host, + all the secondary addresses of the first item were incorrectly removed + from the list, along with the local host and any following hosts (which + is what is supposed to happen). + +PH/40 When Exim receives a message, it writes the login name, uid, and gid of + whoever called Exim into the -H file. In the case of the daemon it was + behaving confusingly. When first started, it used values for whoever + started the daemon, but after a SIGHUP it used the Exim user (because it + calls itself on a restart). I have changed the code so that it now always + uses the Exim user. + +PH/41 (Following a suggestion from Tony Finch) If all the RCPT commands in a + message are rejected with the same error (e.g. no authentication or bad + sender address), and a DATA command is nevertheless sent (as can happen + with PIPELINING or a stupid MUA), the error message that was given to the + RCPT commands is included in the rejection of the DATA command. This is + intended to be helpful for MUAs that show only the final error to their + users. + +PH/42 Another patch from the Sieve maintainer. + +SC/02 Eximstats - Differentiate between permanent and temporary rejects. + Eximstats - Fixed some broken HTML links and added missing column headers + (Jez Hancock). + Eximstats - Fixed Grand Total Summary Domains, Edomains, and Email + columns for Rejects, Temp Rejects, Ham, and Spam rows. + +SC/03 Eximstats - V1.58 Fix to get <> and blackhole to show in edomain tables. + +PH/43 Yet another patch from the Sieve maintainer. + +PH/44 I found a way to check for a TCP/IP connection going away before sending + the response to the final '.' that terminates a message, but only in the + case where the client has not sent further data following the '.' + (unfortunately, this is allowed). However, in many cases there won't be + any further data because there won't be any more messages to send. A call + to select() can be used: if it shows that the input is "ready", there is + either input waiting, or the socket has been closed. An attempt to read + the next input character can distinguish the two cases. Previously, Exim + would have sent an OK response which the client would never have see. + This could lead to message repetition. This fix should cure that, at + least in a lot of common cases. + +PH/45 Do not advertise STARTTLS in response to HELP unless it would be + advertised in response to EHLO. + + +Exim version 4.66 +----------------- + +PH/01 Two more bugs that were introduced by 4.64/PH/07, in addition to the one + fixed by 4.65/MH/01 (is this a record?) are fixed: + + (i) An empty string was always treated as zero by the numeric comparison + operators. This behaviour has been restored. + + (ii) It is documented that the numeric comparison operators always treat + their arguments as decimal numbers. This was broken in that numbers + starting with 0 were being interpreted as octal. + + While fixing these problems I realized that there was another issue that + hadn't been noticed. Values of message_size_limit (both the global option + and the transport option) were treated as octal if they started with 0. + The documentation was vague. These values are now always treated as + decimal, and I will make that clear in the documentation. + + +Exim version 4.65 +----------------- + +TK/01 Disable default definition of HAVE_LINUX_SENDFILE. Clashes with + Linux large file support (_FILE_OFFSET_BITS=64) on older glibc + versions. (#438) + +MH/01 Don't check that the operands of numeric comparison operators are + integers when their expansion is in "skipping" mode (fixes bug + introduced by 4.64-PH/07). + +PH/01 If a system filter or a router generates more than SHRT_MAX (32767) + child addresses, Exim now panics and dies. Previously, because the count + is held in a short int, deliveries were likely to be lost. As such a + large number of recipients for a single message is ridiculous + (performance will be very, very poor), I have chosen to impose a limit + rather than extend the field. + + +Exim version 4.64 +----------------- + +TK/01 Bugzilla #401. Fix DK spooling code so that it can overwrite a + leftover -K file (the existence of which was triggered by #402). + While we were at it, introduced process PID as part of the -K + filename. This should rule out race conditions when creating + these files. + +TK/02 Bugzilla #402. Apply patch from Simon Arlott, speeding up DK signing + processing considerably. Previous code took too long for large mails, + triggering a timeout which in turn triggers #401. + +TK/03 Introduced HAVE_LINUX_SENDFILE to os.h-Linux. Currently only used + in the DK code in transports.c. sendfile() is not really portable, + hence the _LINUX specificness. + +TF/01 In the add_headers option to the mail command in an Exim filter, + there was a bug that Exim would claim a syntax error in any + header after the first one which had an odd number of characters + in the field name. + +PH/01 If a server that rejects MAIL FROM:<> was the target of a sender + callout verification, Exim cached a "reject" for the entire domain. This + is correct for most verifications, but it is not correct for a recipient + verification with use_sender or use_postmaster set, because in that case + the callout does not use MAIL FROM:<>. Exim now distinguishes the special + case of MAIL FROM:<> rejection from other early rejections (e.g. + rejection of HELO). When verifying a recipient using a non-null MAIL + address, the cache is ignored if it shows MAIL FROM:<> rejection. + Whatever the result of the callout, the value of the domain cache is + left unchanged (for any other kind of callout, getting as far as trying + RCPT means that the domain itself is ok). + +PH/02 Tidied a number of unused variable and signed/unsigned warnings that + gcc 4.1.1 threw up. + +PH/03 On Solaris, an unexpectedly close socket (dropped connection) can + manifest itself as EPIPE rather than ECONNECT. When tidying away a + session, the daemon ignores ECONNECT errors and logs others; it now + ignores EPIPE as well. + +PH/04 Applied Nico Erfurth's refactoring patch to tidy up mime.c + (quoted-printable decoding). + +PH/05 Applied Nico Erfurth's refactoring patch to tidy up spool_mbox.c, and + later the small subsequent patch to fix an introduced bug. + +PH/06 Installed the latest Cygwin Makefile from the Cygwin maintainer. + +PH/07 There was no check for overflow in expansions such as ${if >{1}{4096M}}. + +PH/08 An error is now given if message_size_limit is specified negative. + +PH/09 Applied and tidied up Jakob Hirsch's patch for allowing ACL variables + to be given (somewhat) arbitrary names. + +JJ/01 exipick 20060919.0, allow for arbitrary acl_ variables introduced + in 4.64-PH/09. + +JJ/02 exipick 20060919.0, --show-vars args can now be regular expressions, + miscellaneous code fixes + +PH/10 Added the log_reject_target ACL modifier to specify where to log + rejections. + +PH/11 Callouts were setting the name used for EHLO/HELO from $smtp_active_ + hostname. This is wrong, because it relates to the incoming message (and + probably the interface on which it is arriving) and not to the outgoing + callout (which could be using a different interface). This has been + changed to use the value of the helo_data option from the smtp transport + instead - this is what is used when a message is actually being sent. If + there is no remote transport (possible with a router that sets up host + addresses), $smtp_active_hostname is used. + +PH/12 Installed Andrey Panin's patch to add a dovecot authenticator. Various + tweaks were necessary in order to get it to work (see also 21 below): + (a) The code assumed that strncpy() returns a negative number on buffer + overflow, which isn't the case. Replaced with Exim's string_format() + function. + (b) There were several signed/unsigned issues. I just did the minimum + hacking in of casts. There is scope for a larger refactoring. + (c) The code used strcasecmp() which is not a standard C function. + Replaced with Exim's strcmpic() function. + (d) The code set only $1; it now sets $auth1 as well. + (e) A simple test gave the error "authentication client didn't specify + service in request". It would seem that Dovecot has changed its + interface. Fortunately there's a specification; I followed it and + changed what the client sends and it appears to be working now. + +PH/13 Added $message_headers_raw to provide the headers without RFC 2047 + decoding. + +PH/14 Corrected misleading output from -bv when -v was also used. Suppose the + address A is aliased to B and C, where B exists and C does not. Without + -v the output is "A verified" because verification stops after a + successful redirection if more than one address is generated. However, + with -v the child addresses are also verified. Exim was outputting "A + failed to verify" and then showing the successful verification for C, + with its parentage. It now outputs "B failed to verify", showing B's + parentage before showing the successful verification of C. + +PH/15 Applied Michael Deutschmann's patch to allow DNS black list processing to + look up a TXT record in a specific list after matching in a combined + list. + +PH/16 It seems that the options setting for the resolver (RES_DEFNAMES and + RES_DNSRCH) can affect the behaviour of gethostbyname() and friends when + they consult the DNS. I had assumed they would set it the way they + wanted; and indeed my experiments on Linux seem to show that in some + cases they do (I could influence IPv6 lookups but not IPv4 lookups). + To be on the safe side, however, I have now made the interface to + host_find_byname() similar to host_find_bydns(), with an argument + containing the DNS resolver options. The host_find_byname() function now + sets these options at its start, just as host_find_bydns() does. The smtp + transport options dns_qualify_single and dns_search_parents are passed to + host_find_byname() when gethostbyname=TRUE in this transport. Other uses + of host_find_byname() use the default settings of RES_DEFNAMES + (qualify_single) but not RES_DNSRCH (search_parents). + +PH/17 Applied (a modified version of) Nico Erfurth's patch to make + spool_read_header() do less string testing, by means of a preliminary + switch on the second character of optional "-foo" lines. (This is + overdue, caused by the large number of possibilities that now exist. + Originally there were few.) While I was there, I also converted the + str(n)cmp tests so they don't re-test the leading "-" and the first + character, in the hope this might squeeze out yet more improvement. + +PH/18 Two problems with "group" syntax in header lines when verifying: (1) The + flag allowing group syntax was set by the header_syntax check but not + turned off, possible causing trouble later; (2) The flag was not being + set at all for the header_verify test, causing "group"-style headers to + be rejected. I have now set it in this case, and also caused header_ + verify to ignore an empty address taken from a group. While doing this, I + came across some other cases where the code for allowing group syntax + while scanning a header line wasn't quite right (mostly, not resetting + the flag correctly in the right place). These bugs could have caused + trouble for malformed header lines. I hope it is now all correct. + +PH/19 The functions {pwcheck,saslauthd}_verify_password() are always called + with the "reply" argument non-NULL. The code, however (which originally + came from elsewhere) had *some* tests for NULL when it wrote to *reply, + but it didn't always do it. This confused somebody who was copying the + code for some other use. I have removed all the tests. + +PH/20 It was discovered that the GnuTLS code had support for RSA_EXPORT, a + feature that was used to support insecure browsers during the U.S. crypto + embargo. It requires special client support, and Exim is probably the + only MTA that supported it -- and would never use it because real RSA is + always available. This code has been removed, because it had the bad + effect of slowing Exim down by computing (never used) parameters for the + RSA_EXPORT functionality. + +PH/21 On the advice of Timo Sirainen, added a check to the dovecot + authenticator to fail if there's a tab character in the incoming data + (there should never be unless someone is messing about, as it's supposed + to be base64-encoded). Also added, on Timo's advice, the "secured" option + if the connection is using TLS or if the remote IP is the same as the + local IP, and the "valid-client-cert option" if a client certificate has + been verified. + +PH/22 As suggested by Dennis Davis, added a server_condition option to *all* + authenticators. This can be used for authorization after authentication + succeeds. (In the case of plaintext, it servers for both authentication + and authorization.) + +PH/23 Testing for tls_required and lost_connection in a retry rule didn't work + if any retry times were supplied. + +PH/24 Exim crashed if verify=helo was activated during an incoming -bs + connection, where there is no client IP address to check. In this + situation, the verify now always succeeds. + +PH/25 Applied John Jetmore's -Mset patch. + +PH/26 Added -bem to be like -Mset, but loading a message from a file. + +PH/27 In a string expansion for a processed (not raw) header when multiple + headers of the same name were present, leading whitespace was being + removed from all of them, but trailing whitespace was being removed only + from the last one. Now trailing whitespace is removed from each header + before concatenation. Completely empty headers in a concatenation (as + before) are ignored. + +PH/28 Fixed bug in backwards-compatibility feature of PH/09 (thanks to John + Jetmore). It would have mis-read ACL variables from pre-4.61 spool files. + +PH/29 [Removed. This was a change that I later backed out, and forgot to + correct the ChangeLog entry (that I had efficiently created) before + committing the later change.] + +PH/30 Exim was sometimes attempting to deliver messages that had suffered + address errors (4xx response to RCPT) over the same connection as other + messages routed to the same hosts. Such deliveries are always "forced", + so retry times are not inspected. This resulted in far too many retries + for the affected addresses. The effect occurred only when there were more + hosts than the hosts_max_try setting in the smtp transport when it had + the 4xx errors. Those hosts that it had tried were not added to the list + of hosts for which the message was waiting, so if all were tried, there + was no problem. Two fixes have been applied: + + (i) If there are any address or message errors in an SMTP delivery, none + of the hosts (tried or untried) are now added to the list of hosts + for which the message is waiting, so the message should not be a + candidate for sending over the same connection that was used for a + successful delivery of some other message. This seems entirely + reasonable: after all the message is NOT "waiting for some host". + This is so "obvious" that I'm not sure why it wasn't done + previously. Hope I haven't missed anything, but it can't do any + harm, as the worst effect is to miss an optimization. + + (ii) If, despite (i), such a delivery is accidentally attempted, the + routing retry time is respected, so at least it doesn't keep + hammering the server. + +PH/31 Installed Andrew Findlay's patch to close the writing end of the socket + in ${readsocket because some servers need this prod. + +PH/32 Added some extra debug output when updating a wait-xxx database. + +PH/33 The hint "could be header name not terminated by colon", which has been + given for certain expansion errors for a long time, was not being given + for the ${if def:h_colon_omitted{... case. + +PH/34 The spec says: "With one important exception, whenever a domain list is + being scanned, $domain contains the subject domain." There was at least + one case where this was not true. + +PH/35 The error "getsockname() failed: connection reset by peer" was being + written to the panic log as well as the main log, but it isn't really + panic-worthy as it just means the connection died rather early on. I have + removed the panic log writing for the ECONNRESET error when getsockname() + fails. + +PH/36 After a 4xx response to a RCPT error, that address was delayed (in queue + runs only) independently of the message's sender address. This meant + that, if the 4xx error was in fact related to the sender, a different + message to the same recipient with a different sender could confuse + things. In particular, this can happen when sending to a greylisting + server, but other circumstances could also provoke similar problems. + I have changed the default so that the retry time for these errors is now + based a combination of the sender and recipient addresses. This change + can be overridden by setting address_retry_include_sender=false in the + smtp transport. + +PH/37 For LMTP over TCP/IP (the smtp transport), error responses from the + remote server are returned as part of bounce messages. This was not + happening for LMTP over a pipe (the lmtp transport), but now it is the + same for both kinds of LMTP. + +PH/38 Despite being documented as not happening, Exim was rewriting addresses + in header lines that were in fact CNAMEs. This is no longer the case. + +PH/39 If -R or -S was given with -q<time>, the effect of -R or -S was ignored, + and queue runs started by the daemon processed all messages. This has + been fixed so that -R and -S can now usefully be given with -q<time>. + +PH/40 Import PCRE release 6.7 (fixes some bugs). + +PH/41 Add bitwise logical operations to eval (courtesy Brad Jorsch). + +PH/42 Give an error if -q is specified more than once. + +PH/43 Renamed the variables $interface_address and $interface_port as + $received_ip_address and $received_port, to make it clear that these + values apply to message reception, and not to the outgoing interface when + a message is delivered. (The old names remain recognized, of course.) + +PH/44 There was no timeout on the connect() call when using a Unix domain + socket in the ${readsocket expansion. There now is. + +PH/45 Applied a modified version of Brad Jorsch's patch to allow "message" to + be meaningful with "accept". + +SC/01 Eximstats V1.43 + Bug fix for V1.42 with -h0 specified. Spotted by Chris Lear. + +SC/02 Eximstats V1.44 + Use a glob alias rather than an array ref in the generated + parser. This improves both readability and performance. + +SC/03 Eximstats V1.45 (Marco Gaiarin / Steve Campbell) + Collect SpamAssassin and rejection statistics. + Don't display local sender or destination tables unless + there is data to show. + Added average volumes into the top table text output. + +SC/04 Eximstats V1.46 + Collect data on the number of addresses (recipients) + as well as the number of messages. + +SC/05 Eximstats V1.47 + Added 'Message too big' to the list of mail rejection + reasons (thanks to Marco Gaiarin). + +SC/06 Eximstats V1.48 + Mainlog lines which have GMT offsets and are too short to + have a flag are now skipped. + +SC/07 Eximstats V1.49 (Alain Williams) + Added the -emptyok flag. + +SC/08 Eximstats V1.50 + Fixes for obtaining the IP address from reject messages. + +JJ/03 exipick.20061117.2, made header handling as similar to exim as possible + (added [br]h_ prefixes, implemented RFC2047 decoding. Fixed + whitespace changes from 4.64-PH/27 + +JJ/04 exipick.20061117.2, fixed format and added $message_headers_raw to + match 4.64-PH/13 + +JJ/05 exipick.20061117.2, bug fixes (error out sooner when invalid criteria + are found, allow negative numbers in numeric criteria) + +JJ/06 exipick.20061117.2, added new $message_body_missing variable + +JJ/07 exipick.20061117.2, added $received_ip_address and $received_port + to match changes made in 4.64-PH/43 + +PH/46 Applied Jori Hamalainen's patch to add features to exiqsumm. + +PH/47 Put in an explicit test for a DNS lookup of an address record where the + "domain" is actually an IP address, and force a failure. This locks out + those revolvers/nameservers that support "A-for-A" lookups, in + contravention of the specifications. + +PH/48 When a host name was looked up from an IP address, and the subsequent + forward lookup of the name timed out, the host name was left in + $sender_host_name, contrary to the specification. + +PH/49 Although default lookup types such as lsearch* or cdb*@ have always been + restricted to single-key lookups, Exim was not diagnosing an error if + * or *@ was used with a query-style lookup. + +PH/50 Increased the value of DH_BITS in tls-gnu.c from 768 to 1024. + +MH/01 local_scan ABI version incremented to 1.1. It should have been updated + long ago, but noone interested enough thought of it. Let's just say that + the "1.1" means that there are some new functions that weren't there at + some point in the past. + +PH/51 Error processing for expansion failure of helo_data from an smtp + transport during callout processing was broken. + +PH/52 Applied John Jetmore's patch to allow tls-on-connect and STARTTLS to be + tested/used via the -bh/-bhc/-bs options. + +PH/53 Added missing "#include <time.h>" to pcre/pcretest.c (this was a PCRE + bug, fixed in subsequent PCRE releases). + +PH/54 Applied Robert Bannocks' patch to avoid a problem with references that + arises when using the Solaris LDAP libraries (but not with OpenLDAP). + +PH/55 Check for a ridiculously long file name in exim_dbmbuild. + + +Exim version 4.63 +----------------- + +SC/01 Use a glob alias rather than an array ref in eximstats generated + parser. This improves both readability and performance. + +SC/02 Collect SpamAssassin and rejection statistics in eximstats. + Don't display local sender or destination tables in eximstats unless + there is data to show. + Added average volumes into the eximstats top table text output. + +SC/03 Collect data on the number of addresses (recipients) as well + as the number of messages in eximstats. + +TF/01 Correct an error in the documentation for the redirect router. Exim + does (usually) call initgroups() when daemonizing. + +TF/02 Call initgroups() when dropping privilege in exim.c, so that Exim runs + with consistent privilege compared to when running as a daemon. + +TF/03 Note in the spec that $authenticated_id is not set for local + submissions from trusted users. + +TF/04 The ratelimit per_rcpt option now works correctly in acl_not_smtp. + Thanks to Dean Brooks <dean@iglou.com> for the patch. + +TF/05 Make it easier to get SMTP authentication and TLS/SSL support working + by adding some example configuration directives to the default + configuration file. A little bit of work is required to uncomment the + directives and define how usernames and passwords are checked, but + there is now a framework to start from. + +PH/01 Added #define LDAP_DEPRECATED 1 to ldap.c because some of the "old" + functions that Exim currently uses aren't defined in ldap.h for OpenLDAP + without this. I don't know how relevant this is to other LDAP libraries. + +PH/02 Add the verb name to the "unknown ACL verb" error. + +PH/03 Magnus Holmgren's patch for filter_prepend_home. + +PH/03 Fixed Bugzilla #101: macro definition between ACLs doesn't work. + +PH/04 Applied Magnus Holmgren's patch to fix Bugzilla #98: transport's home + directory not expanded when it should be if an expanded home directory + was set for the address (which is overridden by the transport). + +PH/05 Applied Alex Kiernan's patch to fix Bugzilla #99: a problem with + libradius. + +PH/06 Added acl_not_smtp_start, based on Johannes Berg's patch, and set the + bit to forbid control=suppress_local_fixups in the acl_not_smtp ACL, + because it is too late at that time, and has no effect. + +PH/07 Changed ${quote_pgsql to quote ' as '' instead of \' because of a + security issue with \' (bugzilla #107). I could not use the + PQescapeStringConn() function, because it needs a PGconn value as one of + its arguments. + +PH/08 When testing addresses using -bt, indicate those final addresses that + are duplicates that would not cause an additional delivery. At least one + person was confused, thinking that -bt output corresponded to deliveries. + (Suppressing duplicates isn't a good idea as you lose the information + about possibly different redirections that led to the duplicates.) + +PH/09 Applied patch from Erik to use select() instead of poll() in spam.c on + systems where poll() doesn't work, in particular OS X. + +PH/10 Added more information to debugging output for retry time not reached. + +PH/11 Applied patch from Arkadiusz Miskiewicz to apply a timeout to read + operations in malware.c. + +PH/12 Applied patch from Magnus Holmgren to include the "h" tag in Domain Keys + signatures. + +PH/13 If write_rejectlog was set false when logging was sent to syslog with + syslog_duplication set false, log lines that would normally be written + both the the main log and to the reject log were not written to syslog at + all. + +PH/14 In the default configuration, change the use of "message" in ACL warn + statements to "add_header". + +PH/15 Diagnose a filter syntax error for "seen", "unseen", or "noerror" if not + not followed by a command (e.g. "seen endif"). + +PH/16 Recognize SMTP codes at the start of "message" in ACLs and after :fail: + and :defer: in a redirect router. Add forbid_smtp_code to suppress the + latter. + +PH/17 Added extra conditions to the default value of delay_warning_condition + so that it is now: + + ${if or { \ + { !eq{$h_list-id:$h_list-post:$h_list-subscribe:}{} } \ + { match{$h_precedence:}{(?i)bulk|list|junk} } \ + { match{$h_auto-submitted:}{(?i)auto-generated|auto-replied} } \ + }{no}{yes}} + + The Auto-Submitted: and various List- headers are standardised, whereas I + don't think Precedence: ever was. + +PH/18 Refactored debugging code in route_finduser() to show more information, + in particular, the error code if getpwnam() issues one. + +PH/19 Added PQsetClientEncoding(conn, "SQL_ASCII") to the pgsql code module. + This is apparently needed in addition to the PH/07 change above to avoid + any possible encoding problems. + +PH/20 Perl can change the locale. Exim was resetting it after a ${perl call, + but not after initializing Perl. + +PH/21 Added a call to PQsetNoticeProcessor() to catch pgsql "notices" and + output them only if debugging. By default they are written stderr, + apparently, which is not desirable. + +PH/22 Added Alain Williams' LDAP patch to support setting REFERRALS=off on + queries. + +JJ/01 exipick: added --reverse (and -R synonym), --random, --size, --sort and + --not options + +JJ/02 exipick: rewrote --help documentation to hopefully make more clear. + +PH/23 Made -oMaa and -oMt work with -bh and -bs to pretend the connection is + authenticated or an ident call has been made. Suppress the default + values for $authenticated_id and $authenticated_sender (but permit -oMai + and -oMas) when testing with -bh. + +PH/24 Re-jigged the order of the tests in the default configuration so that the + tests for valid domains and recipients precede the DNS black list and CSA + tests, on the grounds that those ones are more expensive. + +PH/25 Exim was not testing for a space following SMTP commands such as EHLO + that require one. Thus, EHLORHUBARB was interpreted as a valid command. + This bug exists in every version of Exim that I still have, right back to + 0.12. + +PH/26 (n)wildlsearch lookups are documented as being done case-insensitively. + However, an attempt to turn on case-sensitivity in a regex key by + including (?-i) didn't work because the subject string was already + lowercased, and the effects were non-intuitive. It turns out that a + one-line patch can be used to allow (?-i) to work as expected. + + +Exim version 4.62 +----------------- + +TF/01 Fix the add_header change below (4.61 PH/55) which had a bug that (amongst + other effects) broke the use of negated acl sub-conditions. + +PH/01 ${readsocket now supports Internet domain sockets (modified John Jetmore + patch). + +PH/02 When tcp-wrappers is called from Exim, it returns only "deny" or "allow". + "Deny" causes Exim to reject the incoming connection with a 554 error. + Unfortunately, if there is a major crisis, such as a disk failure, + tcp-wrappers gives "deny", whereas what one would like would be some + kind of temporary error. A kludge has been added to help with this. + Before calling hosts_ctl(), errno is set zero. If the result is "deny", a + 554 error is used if errno is still zero or contains ENOENT (which occurs + if either of the /etc/hosts.{allow,deny} files is missing). Otherwise, a + 451 error is used. + +PH/03 Add -lutil to the default FreeBSD LIBS setting. + +PH/04 Change PH/19 for 4.61 was too wide. It should not be applied to host + errors. Otherwise a message that provokes a temporary error (when other + messages do not) can cause a whole host to time out. + +PH/05 Batch deliveries by appendfile and pipe transports did not work when the + addresses were routed directly to files or pipes from a redirect router. + File deliveries just didn't batch; pipe deliveries might have suffered + odd errors. + +PH/06 A failure to get a lock for a hints database would erroneously always say + "Failed to get write lock", even when it was really a read lock. + +PH/07 The appendfile transport was creating MBX lock files with a fixed mode + of 0600. This has been changed to use the value of the lockfile_mode + option (which defaults to 0600). + +PH/08 Applied small patch from the Sieve maintainer. + +PH/09 If maildir_quota_directory_regex was set to exclude (say) the .Trash + folder from quota calculations, a direct delivery into this folder messed + up the contents of the maildirsize file. This was because the regex was + used only to exclude .Trash (or whatever) when the size of the mailbox + was calculated. There was no check that a delivery was happening into an + excluded directory. This bug has been fixed by ignoring all quota + processing for deliveries into excluded directories. + +PH/10 Added the maildirfolder_create_regex option to appendfile. + + +Exim version 4.61 +----------------- + +PH/01 The code for finding all the local interface addresses on a FreeBSD + system running IPv6 was broken. This may well have applied to all BSD + systems, as well as to others that have similar system calls. The broken + code found IPv4 interfaces correctly, but gave incorrect values for the + IPv6 interfaces. In particular, ::1 was not found. The effect in Exim was + that it would not match correctly against @[] and not recognize the IPv6 + addresses as local. + +PH/02 The ipliteral router was not recognizing addresses of the form user@ + [ipv6:....] because it didn't know about the "ipv6:" prefix. + +PH/03 Added disable_ipv6. + +PH/04 Changed $reply_address to use the raw form of the headers instead of the + decoded form, because it is most often used to construct To: headers + lines in autoreplies, and the decoded form may well be syntactically + invalid. However, $reply_address has leading white space removed, and all + newlines turned into spaces so that the autoreply transport does not + grumble. + +PH/05 If group was specified without a user on a router, and no group or user + was specified on a transport, the group from the router was ignored. + +PH/06 Increased the number of ACL variables to 20 of each type, and arranged + for visible compile-time settings that can be used to change these + numbers, for those that want even more. Backwards compatibility with old + spool files has been maintained. However, going back to a previous Exim + release will lost any variables that are in spool files. + +PH/07 Two small changes when running in the test harness: increase delay when + passing a TCP/IP connection to a new process, in case the original + process has to generate a bounce, and remove special handling of + 127.0.0.2 (sic), which is no longer necessary. + +PH/08 Changed debug output of dbfn_open() flags from numbers to names, so as to + be the same on different OS. + +PH/09 Moved a debug statement in filter processing to avoid a race problem when + testing. + +JJ/01 exipick: fixed bug where -b (brief) output option showed "Vars:" + whether --show-vars was specified or not + +JJ/02 exipick: Added support for new ACL variable spool format introduced + in 4.61-PH/06 + +PH/10 Fixed another bug related to PH/04 above: if an incoming message had a + syntactically invalid From: or Reply-to: line, and a filter used this to + generate an autoreply, and therefore failed to obtain an address for the + autoreply, Exim could try to deliver to a non-existent relative file + name, causing unrelated and misleading errors. What now happens is that + it logs this as a hard delivery error, but does not attempt to create a + bounce message. + +PH/11 The exinext utility has a -C option for testing purposes, but although + the given file was scanned by exinext itself; it wasn't being passed on + when Exim was called. + +PH/12 In the smtp transport, treat an explicit ECONNRESET error the same as + an end-of-file indication when reading a command response. + +PH/13 Domain literals for IPv6 were not recognized unless IPv6 support was + compiled. In many other places in Exim, IPv6 addresses are always + recognized, so I have changed this. It also means that IPv4 domain + literals of the form [IPV4:n.n.n.n] are now always recognized. + +PH/14 When a uid/gid is specified for the queryprogram router, it cannot be + used if the router is not running as root, for example, when verifying at + ACL time, or when using -bh. The debugging output from this situation was + non-existent - all you got was a failure to exec. I have made two + changes: + + (a) Failures to set uid/gid, the current directory, or a process leader + in a subprocess such as that created by queryprogram now generate + suitable debugging output when -d is set. + + (b) The queryprogram router detects when it is not running as root, + outputs suitable debugging information if -d is set, and then runs + the subprocess without attempting to change uid/gid. + +PH/15 Minor change to Makefile for building test_host (undocumented testing + feature). + +PH/16 As discussed on the list in Nov/Dec: Exim no longer looks at the + additional section of a DNS packet that returns MX or SRV records. + Instead, it always explicitly searches for A/AAAA records. This avoids + major problems that occur when a DNS server includes only records of one + type (A or AAAA) in an MX/SRV packet. A byproduct of this change has + fixed another bug: if SRV records were looked up and the corresponding + address records were *not* found in the additional section, the port + values from the SRV records were lost. + +PH/17 If a delivery to a pipe, file, or autoreply was deferred, Exim was not + using the correct key (the original address) when searching the retry + rules in order to find which one to use for generating the retry hint. + +PH/18 If quota_warn_message contains a From: header, Exim now refrains from + adding the default one. Similarly, if it contains a Reply-To: header, the + errors_reply_to option, if set, is not used. + +PH/19 When calculating a retry time, Exim used to measure the "time since + failure" by looking at the "first failed" field in the retry record. Now + it does not use this if it is later than than the arrival time of the + message. Instead it uses the arrival time. This makes for better + behaviour in cases where some deliveries succeed, thus re-setting the + "first failed" field. An example is a quota failure for a huge message + when small messages continue to be delivered. Without this change, the + "time since failure" will always be short, possible causing more frequent + delivery attempts for the huge message than are intended. + [Note: This change was subsequently modified - see PH/04 for 4.62.] + +PH/20 Added $auth1, $auth2, $auth3 to contain authentication data (as well as + $1, $2, $3) because the numerical variables can be reset during some + expansion items (e.g. "match"), thereby losing the authentication data. + +PH/21 Make -bV show the size of off_t variables so that the test suite can + decide whether to run tests for quotas > 2G. + +PH/22 Test the values given for quota, quota_filecount, quota_warn_threshold, + mailbox_size, and mailbox_filecount in the appendfile transport. If a + filecount value is greater than 2G or if a quota value is greater than 2G + on a system where the size of off_t is not greater than 4, a panic error + is given. + +PH/23 When a malformed item such as 1.2.3/24 appears in a host list, it can + never match. The debug and -bh output now contains an explicit error + message indicating a malformed IPv4 address or mask. + +PH/24 An host item such as 1.2.3.4/abc was being treated as the IP address + 1.2.3.4 without a mask. Now it is not recognized as an IP address, and + PH/23 above applies. + +PH/25 Do not write to syslog when running in the test harness. The only + occasion when this arises is a failure to open the main or panic logs + (for which there is an explicit test). + +PH/26 Added the /no_tell option to "control=freeze". + +PH/27 If a host name lookup failed very early in a connection, for example, if + the IP address matched host_lookup and the reverse lookup yielded a name + that did not have a forward lookup, an error message of the form "no IP + address found for host xxx.xxx.xxx (during SMTP connection from NULL)" + could be logged. Now it outputs the IP address instead of "NULL". + +PH/28 An enabling patch from MH: add new function child_open_exim2() which + allows the sender and the authenticated sender to be set when + submitting a message from within Exim. Since child_open_exim() is + documented for local_scan(), the new function should be too. + +PH/29 In GnuTLS, a forced expansion failure for tls_privatekey was not being + ignored. In both GnuTLS and OpenSSL, an expansion of tls_privatekey that + results in an empty string is now treated as unset. + +PH/30 Fix eximon buffer overflow bug (Bugzilla #73). + +PH/31 Added sender_verify_fail logging option. + +PH/32 In November 2003, the code in Exim that added an empty Bcc: header when + needed by RFC 822 but not by RFC 2822 was commented out. I have now + tidied the source and removed it altogether. + +PH/33 When a queue run was abandoned because the load average was too high, a + log line was always written; now it is written only if the queue_run log + selector is set. In addition, the log line for abandonment now contains + information about the queue run such as the pid. This is always present + in "start" and "stop" lines but was omitted from the "abandon" line. + +PH/34 Omit spaces between a header name and the colon in the error message that + is given when verify = headers_syntax fails (if there are lots of them, + the message gets confusing). + +PH/35 Change the default for dns_check_names_pattern to allow slashes within + names, as there are now some PTR records that contain slashes. This check + is only to protect against broken name servers that fall over on strange + characters, so the fact that it applies to all lookups doesn't matter. + +PH/36 Now that the new test suite is complete, we can remove some of the + special code in Exim that was needed for the old test suite. For example, + sorting DNS records because real resolvers return them in an arbitrary + order. The new test suite's fake resolver always returns records in the + same order. + +PH/37 When running in the test harness, use -odi for submitted messages (e.g. + bounces) except when queue_only is set, to avoid logging races between + the different processes. + +PH/38 Panic-die if .include specifies a non-absolute path. + +PH/39 A tweak to the "H" retry rule from its user. + +JJ/03 exipick: Removed parentheses from 'next' and 'last' calls that specified + a label. They prevented compilation on older perls. + +JJ/04 exipick: Refactored code to prevent implicit split to @_ which caused + a warning to be raised on newish perls. + +JJ/05 exipick: Fixed bug where -bpc always showed a count of all messages + on queue. Changes to match documented behaviour of showing count of + messages matching specified criteria. + +PH/40 Changed the default ident timeout from 30s to 5s. + +PH/41 Added support for the use of login_cap features, on those BSD systems + that have them, for controlling the resources used by pipe deliveries. + +PH/42 The content-scanning code uses fopen() to create files in which to put + message data. Previously it was not paying any attention to the mode of + the files. Exim runs with umask(0) because the rest of the code creates + files with open(), and sets the required mode explicitly. Thus, these + files were ending up world-writeable. This was not a big issue, because, + being within the spool directory, they were not world-accessible. I have + created a function called modefopen, which takes an additional mode + argument. It sets umask(777), creates the file, chmods it to the required + mode, then resets the umask. All the relevant calls to fopen() in the + content scanning code have been changed to use this function. + +PH/43 If retry_interval_max is set greater than 24 hours, it is quietly reset + to 24 hours. This avoids potential overflow problems when processing G + and H retry rules. I suspect nobody ever tinkers with this value. + +PH/44 Added STRIP_COMMAND=/usr/bin/strip to the FreeBSD Makefile. + +PH/45 When the plaintext authenticator is running as a client, the server's + challenges are checked to ensure they are valid base64 strings. By + default, the authentication attempt is cancelled if an invalid string is + received. Setting client_ignore_invalid_base64 true ignores these errors. + The decoded challenge strings are now placed in $auth1, $auth2, etc. as + they are received. Thus, the responses can be made to depend on the + challenges. If an invalid string is ignored, an empty string is placed in + the variable. + +PH/46 Messages that are created by the autoreply transport now contains a + References: header, in accordance with RFCs 2822 and 3834. + +PH/47 Added authenticated_sender_force to the smtp transport. + +PH/48 The ${prvs expansion was broken on systems where time_t was long long. + +PH/49 Installed latest patch from the Sieve maintainer. + +PH/50 When an Exim quota was set without a file count quota, and mailbox_size + was also set, the appendfile transport was unnecessarily scanning a + directory of message files (e.g. for maildir delivery) to find the count + of files (along with the size), even though it did not need this + information. It now does the scan only if it needs to find either the + size of the count of files. + +PH/51 Added ${time_eval: to convert Exim time strings into seconds. + +PH/52 Two bugs concerned with error handling when the smtp transport is + used in LMTP mode: + + (i) Exim was not creating retry information for temporary errors given + for individual recipients after the DATA command when the smtp transport + was used in LMTP mode. This meant that they could be retried too + frequently, and not timed out correctly. + + (ii) Exim was setting the flag that allows error details to be returned + for LMTP errors on RCPT commands, but not for LMTP errors for individual + recipients that were returned after the DATA command. + +PH/53 This is related to PH/52, but is more general: for any failing address, + when detailed error information was permitted to be returned to the + sender, but the error was temporary, then after the final timeout, only + "retry timeout exceeded" was returned. Now it returns the full error as + well as "retry timeout exceeded". + +PH/54 Added control=allow_auth_unadvertised, as it seems there are clients that + do this, and (what is worse) MTAs that accept it. + +PH/55 Added the add_header modified to ACLs. The use of "message" with "warn" + will now be deprecated. + +PH/56 New os.c-cygwin from the Cygwin maintainer. + +JJ/06 exipick: added --unsorted option to allow unsorted output in all output + formats (previously only available in exim formats via -bpr, -bpru, + and -bpra. Now also available in native and exiqgrep formats) + +JJ/07 exipick: added --freeze and --thaw options to allow faster interaction + with very large, slow to parse queues + +JJ/08 exipick: added ! as generic prefix to negate any criteria format + +JJ/09 exipick: miscellaneous performance enhancements (~24% improvements) + +PH/57 Tidies in SMTP dialogue display in debug output: (i) It was not showing + responses to authentication challenges, though it was showing the + challenges; (ii) I've removed the CR characters from the debug output for + SMTP output lines. + +PH/58 Allow for the insertion of a newline as well as a space when a string + is turned into more than one encoded-word during RFC 2047 encoding. The + Sieve code now uses this. + +PH/59 Added the following errors that can be detected in retry rules: mail_4xx, + data_4xx, lost_connection, tls_required. + +PH/60 When a VRFY deferred or FAILED, the log message rather than the user + message was being sent as an SMTP response. + +PH/61 Add -l and -k options to exicyclog. + +PH/62 When verifying, if an address was redirected to one new address, so that + verification continued, and the new address failed or deferred after + having set something in $address_data, the value of $address_data was not + passed back to the ACL. This was different to the case when no + redirection occurred. The value is now passed back in both cases. + +PH/63 Changed the macro HAVE_LOGIN_CAP (see PH/41 for this release above) to + HAVE_SETCLASSRESOURCES because there are different APIs in use that all + use login_cap.h, so on its own it isn't the distinguishing feature. The + new name refers directly to the setclassresources() function. + +PH/65 Added configuration files for NetBSD3. + +PH/66 Updated OS/Makefile-HP-UX for gcc 4.1.0 with HP-UX 11. + +PH/67 Fixed minor infelicity in the sorting of addresses to ensure that IPv6 + is preferred over IPv4. + +PH/68 The bounce_return_message and bounce_return_body options were not being + honoured for bounces generated during the reception of non-SMTP messages. + In particular, this applied to messages rejected by the ACL. This bug has + been fixed. However, if bounce_return_message is true and bounce_return_ + body is false, the headers that are returned for a non-SMTP message + include only those that have been read before the error was detected. + (In the case of an ACL rejection, they have all been read.) + +PH/69 The HTML version of the specification is now built in a directory called + spec_html instead of spec.html, because the latter looks like a path with + a MIME-type, and this confuses some software. + +PH/70 Catch two compiler warnings in sieve.c. + +PH/71 Fixed an obscure and subtle bug (thanks Alexander & Matthias). The + function verify_get_ident() calls ip_connect() to connect a socket, but + if the "connect()" function timed out, ip_connect() used to close the + socket. However, verify_get_ident() also closes the socket later, and in + between Exim writes to the log, which may get opened at this point. When + the socket was closed in ip_connect(), the log could get the same file + descriptor number as the socket. This naturally causes chaos. The fix is + not to close the socket in ip_connect(); the socket should be closed by + the function that creates it. There was only one place in the code where + this was missing, in the iplookup router, which I don't think anybody now + uses, but I've fixed it anyway. + +PH/72 Make dns_again_means_nonexist apply to lookups using gethostbyname() as + well as to direct DNS lookups. Otherwise the handling of names in host + lists is inconsistent and therefore confusing. + + +Exim version 4.60 +----------------- + +PH/01 Two changes to the default runtime configuration: + + (1) Move the checks for relay_from_hosts and authenticated clients from + after to before the (commented out) DNS black list checks. + + (2) Add control=submission to the relay_from_hosts and authenticated + clients checks, on the grounds that messages accepted by these + statements are most likely to be submissions. + +PH/02 Several tidies to the handling of ${prvs and ${prvscheck: + + (1) Generate an error if the third argument for the ${prvs expansion is + not a single digit. + + (2) Treat a missing third argument of ${prvscheck as if it were an empty + string. + + (3) Reset the variables that are obtained from the first argument of + ${prvscheck and used in the second argument before leaving the code, + because their memory is reclaimed, so using them afterwards may do + silly things. + + (4) Tidy up the code for expanding the arguments of ${prvscheck one by + one (it's much easier than Tom thought :-). + + (5) Because of (4), we can now allow for the use of $prvscheck_result + inside the third argument. + +PH/03 For some reason, the default setting of PATH when running a command from + a pipe transport was just "/usr/bin". I have changed it to + "/bin:/usr/bin". + +PH/04 SUPPORT_TRANSLATE_IP_ADDRESS and MOVE_FROZEN_MESSAGES did not cause + anything to be listed in the output from -bV. + +PH/05 When a filter generated an autoreply, the entire To: header line was + quoted in the delivery log line, like this: + + => >A.N.Other <ano@some.domain> <original@ddress> ... + + This has been changed so that it extracts the operative address. There + may be more than one such address. If so, they are comma-separated, like + this: + + => >ano@some.domain,ona@other.domain <original@ddress> ... + +PH/06 When a client host used a correct literal IP address in a HELO or EHLO + command, (for example, EHLO [1.2.3.4]) and the client's IP address was + not being looked up in the rDNS to get a host name, Exim was showing the + IP address twice in Received: lines, even though the IP addresses were + identical. For example: + + Received: from [1.2.3.4] (helo=[1.2.3.4]) + + However, if the real host name was known, it was omitting the HELO data + if it matched the actual IP address. This has been tidied up so that it + doesn't show the same IP address twice. + +PH/07 When both +timestamp and +memory debugging was on, the value given by + $tod_xxx expansions could be wrong, because the tod_stamp() function was + called by the debug printing, thereby overwriting the timestamp buffer. + Debugging no longer uses the tod_stamp() function when +timestamp is set. + +PH/08 When the original message was included in an autoreply transport, it + always said "this is a copy of the message, including all the headers", + even if body_only or headers_only was set. It now gives an appropriate + message. + +PH/09 Applied a patch from the Sieve maintainer which: + + o fixes some comments + o adds the (disabled) notify extension core + o adds some debug output for the result of if/elsif tests + o points to the current vacation draft in the documentation + and documents the missing references header update + + and most important: + + o fixes a bug in processing the envelope test (when testing + multiple envelope elements, the last element determined the + result) + +PH/10 Exim was violating RFC 3834 ("Recommendations for Automatic Responses to + Electronic Mail") by including: + + Auto-submitted: auto-generated + + in the messages that it generates (bounce messages and others, such as + warnings). In the case of bounce messages for non-SMTP messages, there was + also a typo: it was using "Auto_submitted" (underscore instead of + hyphen). Since every message generated by Exim is necessarily in response + to another message, thes have all been changed to: + + Auto-Submitted: auto-replied + + in accordance with these statements in the RFC: + + The auto-replied keyword: + + - SHOULD be used on messages sent in direct response to another + message by an automatic process, + + - MUST NOT be used on manually-generated messages, + + - MAY be used on Delivery Status Notifications (DSNs) and Message + Disposition Notifications (MDNs), + + - MUST NOT be used on messages generated by automatic or periodic + processes, except for messages which are automatic responses to + other messages. + +PH/11 Added "${if def:sender_address {(envelope-from <$sender_address>)\n\t}}" + to the default Received: header definition. + +PH/12 Added log selector acl_warn_skipped (default on). + +PH/13 After a successful wildlsearch lookup, discard the values of numeric + variables because (a) they are in the wrong storage pool and (b) even if + they were copied, it wouldn't work properly because of the caching. + +PH/14 Add check_rfc2047_length to disable enforcement of RFC 2047 length + checking when decoding. Apparently there are clients that generate + overlong encoded strings. Why am I not surprised? + +PH/15 If the first argument of "${if match_address" was not empty, but did not + contain an "@" character, Exim crashed. Now it writes a panic log message + and treats the condition as false. + +PH/16 In autoreply, treat an empty string for "once" the same as unset. + +PH/17 A further patch from the Sieve maintainer: "Introduce the new Sieve + extension "envelope-auth". The code is finished and in agreement with + other implementations, but there is no documentation so far and in fact, + nobody wrote the draft yet. This extension is currently #undef'ed, thus + not changing the active code. + + Print executed "if" and "elsif" statements when debugging is used. This + helps a great deal to understand what a filter does. + + Document more things not specified clearly in RFC3028. I had all this + sorted out, when out of a sudden new issues came to my mind. Oops." + +PH/18 Exim was not recognizing the "net-" search type prefix in match_ip lists + (Bugzilla #53). + +PH/19 Exim expands the IPv6 address given to -bh to its full non-abbreviated + canonical form (as documented). However, after a host name lookup from + the IP address, check_host() was doing a simple string comparison with + addresses acquired from the DNS when checking that the found name did + have the original IP as one of its addresses. Since any found IPv6 + addresses are likely to be in abbreviated form, the comparison could + fail. Luckily, there already exists a function for doing the comparison + by converting both addresses to binary, so now that is used instead of + the text comparison. + +PH/20 There was another similar case to PH/19, when a complete host name was + given in a host list; looking up its IP address could give an abbreviated + form, whereas the current host's name might or might not be abbreviated. + The same fix has been applied. + + +Exim version 4.54 +----------------- + +PH/01 The ${base62: operator adjusted itself to base 36 when BASE_62 was + set to 36 (for Darwin and Cygwin), but the ${base62d: operator did not. + It now does. + +PH/02 Two minor problems detected in Cygwin: the os.{c,h} files had lost */ on + the CVS lines, and there was a missing #if HAVE_IPV6 in host.c. + +PH/03 Typo: missing ".o" in src/pcre/Makefile. + +PH/04 Tighten up "personal" tests: Instead of testing for any "List-" + header line, restrict the check to what is listed in RFCs 2369 and 2929. + Also, for "Auto-Submitted", treat anything other than "no" as + non-personal, in accordance with RFC 3834. (Previously it treated + anything starting "auto-" as non-personal.) + +TF/01 The control=submission/name=... option had a problem with syntax + errors if the name included a slash character. The /name= option + now slurps the rest of the string, so it can include any characters + but it must come last in the list of options (after /sender_retain + or /domain=). + +PH/05 Some modifications to the interface to the fake nameserver for the new + testing suite. + + + +Exim version 4.53 +----------------- + +TK/01 Added the "success_on_redirect" address verification option. See + NewStuff for rationale and an example. + +PH/01 Added support for SQLite, basic code supplied by David Woodhouse. + +PH/02 Patch to exigrep to allow it to work on syslog lines. + +PH/03 When creating an mbox file for a virus/spam scan, use fseek() instead of + fread() to skip over the body file's header line, because in Cygwin the + header line is locked and is inaccessible. + +PH/04 Added $message_exim_id, ultimately to replace $message_id (they will both + co-exist for some time) to make it clear that it is the Exim ID that is + referenced, not the Message-ID: header line. + +PH/05 Replaced all Tom's calls to snprintf() with calls to the internal + string_format() function, because snprintf() does not exist on all + operating systems. + +PH/06 The use of forbid_filter_existstest now also locks out the use of the + ${stat: expansion item. + +PH/07 Changed "SMTP protocol violation: synchronization error" into "SMTP + protocol synchronization error", to keep the pedants happy. + +PH/08 Arrange for USE_INET_NTOA_FIX to be set in config.h for AIX systems as + well as for IRIX systems, when gcc is being used. See the host.c source + file for comments. + +PH/09 Installed latest Cygwin configuration files from the Cygwin maintainer. + +PH/10 Named domain lists were not working if used in a queue_smtp_domains + setting. + +PH/11 Added support for the IGNOREQUOTA extension to LMTP, both to the lmtp + transport and to the smtp transport in LMTP mode. + +TK/02 Remove one case of BASE64 error detection FTTB (undocumented anyway). + +PH/12 There was a missing call to search_tidyup() before the fork() in rda.c to + run a filter in a subprocess. This could lead to confusion in subsequent + lookups in the parent process. There should also be a search_tidyup() at + the end of the subprocess. + +PH/13 Previously, if "verify = helo" was set in an ACL, the condition was true + only if the host matched helo_try_verify_hosts, which caused the + verification to occur when the EHLO/HELO command was issued. The ACL just + tested the remembered result. Now, if a previous verification attempt has + not happened, "verify = helo" does it there and then. + +JJ/01 exipick: added $message_exim_id variable (see 4.53-PH/04) + +TK/03 Fix log output including CR from clamd. + +PH/14 A reference to $reply_address when Reply-to: was empty and From: did not + exist provoked a memory error which could cause a segfault. + +PH/15 Installed PCRE 6.2 + +PH/17 Defined BIND_8_COMPAT in the Darwin os.h file. + +PH/18 Reversed 4.52/PH/17 because the HP-UX user found it wasn't the cause + of the problem. Specifically, suggested +O2 rather than +O1 for the + HP-UX compiler. + +PH/19 Added sqlite_lock_timeout option (David Woodhouse's patch). + +PH/20 If a delivery was routed to a non-standard port by means of an SRV + record, the port was not correctly logged when the outgoing_port log + selector was set (it logged the transort's default port). + +PH/21 Added support for host-specific ports to manualroute, queryprogram, + fallback_hosts, and "hosts" in the smtp transport. + +PH/22 If the log selector "outgoing_port" is set, the port is now also given on + host errors such as "Connection refused". + +PH/23 Applied a patch to fix problems with exim-4.52 while doing radius + authentication with radiusclient 0.4.9: + + - Error returned from rc_read_config was caught wrongly + - Username/password not passed on to radius server due to wrong length. + + The presumption is that some radiusclient API changes for 4.51/PH/17 + were not taken care of correctly. The code is still untested by me (my + Linux distribution still has 0.3.2 of radiusclient), but it was + contributed by a Radius user. + +PH/24 When doing a callout, the value of $domain wasn't set correctly when + expanding the "port" option of the smtp transport. + +TK/04 MIME ACL: Fix buffer underrun that occurs when EOF condition is met + while reading a MIME header. Thanks to Tom Hughes for a patch. + +PH/24 Include config.h inside local_scan.h so that configuration settings are + available. + +PH/25 Make $smtp_command_argument available after all SMTP commands. This means + that in an ACL for RCPT (for example), you can examine exactly what was + received. + +PH/26 Exim was recognizing IPv6 addresses of the form [IPv6:....] in EHLO + commands, but it was not correctly comparing the address with the actual + client host address. Thus, it would show the EHLO address in Received: + header lines when this was not necessary. + +PH/27 Added the % operator to ${eval:}. + +PH/28 Exim tries to create and chdir to its spool directory when it starts; + it should be ignoring failures (because with -C, for example, it has lost + privilege). It wasn't ignoring creation failures other than "already + exists". + +PH/29 Added "crypteq" to the list of supported features that Exim outputs when + -bV or -d is used. + +PH/30 Fixed (presumably very longstanding) bug in exim_dbmbuild: if it failed + because an input line was too long, either on its own, or by virtue of + too many continuations, the temporary file was not being removed, and the + return code was incorrect. + +PH/31 Missing "BOOL" in function definition in filtertest.c. + +PH/32 Applied Sieve patches from the maintainer. + +TK/05 Domainkeys: Accomodate for a minor API change in libdomainkeys 0.67. + +PH/33 Added "verify = not_blind". + +PH/34 There are settings for CHOWN_COMMAND and MV_COMMAND that can be used in + Local/Makefile (with some defaults set). These are used in built scripts + such as exicyclog, but they have never been used in the exim_install + script (though there are many overriding facilities there). I have + arranged that the exim_install script now takes note of these two + settings. + +PH/35 Installed configuration files for Dragonfly. + +PH/36 When a locally submitted message by a trusted user did not contain a + From: header, and the sender address was obtained from -f or from an SMTP + MAIL command, and the trusted user did not use -F to supply a sender + name, $originator_name was incorrectly used when constructing a From: + header. Furthermore, $originator_name was used for submission mode + messages from external hosts without From: headers in a similar way, + which is clearly wrong. + +PH/37 Added control=suppress_local_fixups. + +PH/38 When log_selector = +received_sender was set, and the addition of the + sender made the log line's construction buffer exactly full, or one byte + less than full, an overflow happened when the terminating "\n" was + subsequently added. + +PH/39 Added a new log selector, "unknown_in_list", which provokes a log entry + when the result of a list match is failure because a DNS lookup failed. + +PH/40 RM_COMMAND is now used in the building process. + +PH/41 Added a "distclean" target to the top-level Makefile; it deletes all + the "build-* directories that it finds. + +PH/42 (But a TF fix): In a domain list, Exim incorrectly matched @[] if the IP + address in a domain literal was a prefix of an interface address. + +PH/43 (Again a TF fix): In the dnslookup router, do not apply widen_domains + when verifying a sender address, unless rewrite_headers is false. + +PH/44 Wrote a long comment about why errors_to addresses are verified as + recipients, not senders. + +TF/01 Add missing LIBS=-lm to OS/Makefile-OpenBSD which was overlooked when + the ratelimit ACL was added. + +PH/45 Added $smtp_command for the full command (cf $smtp_command_argument). + +PH/46 Added extra information about PostgreSQL errors to the error string. + +PH/47 Added an interface to a fake DNS resolver for use by the new test suite, + avoiding the need to install special zones in a real server. This is + backwards compatible; if it can't find the fake resolver, it drops back. + Thus, both old and new test suites can be run. + +TF/02 Added util/ratelimit.pl + +TF/03 Minor fix to the ratelimit code to improve its behaviour in case the + clock is set back in time. + +TF/04 Fix the ratelimit support in exim_fixdb. Patch provided by Brian + Candler <B.Candler@pobox.com>. + +TF/05 The fix for PH/43 was not completely correct; widen_domains is always + OK for addresses that are the result of redirections. + +PH/48 A number of further additions for the benefit of the new test suite, + including a fake gethostbyname() that interfaces to the fake DNS resolver + (see PH/47 above). + +TF/06 The fix for widen_domains has also been applied to qualify_single and + search_parents which are the other dnslookup options that can cause + header rewrites. + +PH/49 Michael Haardt's randomized retrying, but as a separate retry parameter + type ("H"). + +PH/50 Make never_users, trusted_users, admin_groups, trusted_groups expandable. + +TF/07 Exim produced the error message "an SRV record indicated no SMTP + service" if it encountered an MX record with an empty target hostname. + The message is now "an MX or SRV record indicated no SMTP service". + +TF/08 Change PH/13 introduced the possibility that verify=helo may defer, + if the DNS of the sending site is misconfigured. This is quite a + common situation. This change restores the behaviour of treating a + helo verification defer as a failure. + +PH/51 If self=fail was set on a router, the bounce message did not include the + actual error message. + + +Exim version 4.52 +----------------- + +TF/01 Added support for Client SMTP Authorization. See NewStuff for details. + +PH/01 When a transport filter timed out in a pipe delivery, and the pipe + command itself ended in error, the underlying message about the transport + filter timeout was being overwritten with the pipe command error. Now the + underlying error message should be appended to the second error message. + +TK/01 Fix poll() being unavailable on Mac OSX 10.2. + +PH/02 Reduce the amount of output that "make" produces by default. Full output + can still be requested. + +PH/03 The warning log line about a condition test deferring for a "warn" verb + was being output only once per connection, rather than after each + occurrence (because it was using the same function as for successful + "warn" verbs). This seems wrong, so I have changed it. + +TF/02 Two buglets in acl.c which caused Exim to read a few bytes of memory that + it should not have, which might have caused a crash in the right + circumstances, but probably never did. + +PH/04 Installed a modified version of Tony Finch's patch to make submission + mode fix the return path as well as the Sender: header line, and to + add a /name= option so that you can make the user's friendly name appear + in the header line. + +TF/03 Added the control = fakedefer ACL modifier. + +TF/04 Added the ratelimit ACL condition. See NewStuff for details. Thanks to + Mark Lowes for thorough testing. + +TK/02 Rewrote SPF support to work with libspf2 versions >1.2.0. + +TK/03 Merged latest SRS patch from Miles Wilton. + +PH/05 There's a shambles in IRIX6 - it defines EX_OK in unistd.h which conflicts + with the definition in sysexits.h (which is #included earlier). + Fortunately, Exim does not actually use EX_OK. The code used to try to + preserve the sysexits.h value, by assuming that macro definitions were + scanned for macro replacements. I have been disabused of this notion, + so now the code just undefines EX_OK before #including unistd.h. + +PH/06 There is a timeout for writing blocks of data, set by, e.g. data_timeout + in the smtp transport. When a block could not be written in a single + write() function, the timeout was being re-applied to each part-write. + This seems wrong - if the receiver was accepting one byte at a time it + would take for ever. The timeout is now adjusted when this happens. It + doesn't have to be particularly precise. + +TK/04 Added simple SPF lookup method in EXPERIMENTAL_SPF. See NewStuff for + details. Thanks to Chris Webb <chris@arachsys.com> for the patch! + +PH/07 Added "fullpostmaster" verify option, which does a check to <postmaster> + without a domain if the check to <postmaster@domain> fails. + +SC/01 Eximstats: added -xls and the ability to specify output files + (patch written by Frank Heydlauf). + +SC/02 Eximstats: use FileHandles for outputting results. + +SC/03 Eximstats: allow any combination of xls, txt, and html output. + +SC/04 Eximstats: fixed display of large numbers with -nvr option + +SC/05 Eximstats: fixed merging of reports with empty tables. + +SC/06 Eximstats: added the -include_original_destination flag + +SC/07 Eximstats: removed tabs and trailing whitespace. + +TK/05 Malware: Improve on aveserver error handling. Patch from Alex Miller. + +TK/06 MBOX spool code: Add real "From " MBOX separator line + so the .eml file is really in mbox format (even though + most programs do not really care). Patch from Alex Miller. + +TK/07 MBOX spool code: Add X-Envelope-From: and X-Envelope-To: headers. + The latter is generated from $received_to and is only set if the + message has one envelope recipient. SA can use these headers, + obviously out-of-the-box. Patch from Alex Miller. + +PH/08 The ${def test on a variable was returning false if the variable's + value was "0", contrary to what the specification has always said! + The result should be true unless the variable is empty. + +PH/09 The syntax error of a character other than { following "${if + def:variable_name" (after optional whitespace) was not being diagnosed. + An expansion such as ${if def:sender_ident:{xxx}{yyy}} in which an + accidental colon was present, for example, could give incorrect results. + +PH/10 Tidied the code in a number of places where the st_size field of a stat() + result is used (not including appendfile, where other changes are about + to be made). + +PH/11 Upgraded appendfile so that quotas larger than 2G are now supported. + This involved changing a lot of size variables from int to off_t. It + should work with maildirs and everything. + +TK/08 Apply fix provided by Michael Haardt to prevent deadlock in case of + spamd dying while we are connected to it. + +TF/05 Fixed a ${extract error message typo reported by Jeremy Harris + <jgh@wizmail.org> + +PH/12 Applied Alex Kiernan's patch for the API change for the error callback + function for BDB 4.3. + +PH/13 Changed auto_thaw such that it does not apply to bounce messages. + +PH/14 Imported PCRE 6.0; this was more than just a trivial operation because + the sources for PCRE have been re-arranged and more files are now + involved. + +PH/15 The code I had for printing potentially long long variables in PH/11 + above was not the best (it lost precision). The length of off_t variables + is now inspected at build time, and an appropriate printing format (%ld + or %lld) is chosen and #defined by OFF_T_FMT. We also define LONGLONG_T + to be "long long int" or "long int". This is needed for the internal + formatting function string_vformat(). + +PH/16 Applied Matthew Newton's patch to exicyclog: "If log_file_path is set in + the configuration file to be ":syslog", then the script "guesses" where + the logs files are, rather than using the compiled in default. In our + case the guess is not the same as the compiled default, so the script + suddenly stopped working when I started to use syslog. The patch checks + to see if log_file_path is "". If so, it attempts to read it from exim + with no configuration file to get the compiled in version, before it + falls back to the previous guessing code." + +TK/09 Added "prvs" and "prvscheck" expansion items. These help a lot with + implementing BATV in an Exim configuration. See NewStuff for the gory + details. + +PH/17 Applied Michael Haardt's patch for HP-UX, affecting only the os.h and + Makefile that are specific to HP-UX. + +PH/18 If the "use_postmaster" option was set for a recipient callout together + with the "random" option, the postmaster address was used as the MAIL + FROM address for the random test, but not for the subsequent recipient + test. It is now used for both. + +PH/19 Applied Michael Haardt's patch to update Sieve to RFC3028bis. "The + patch removes a few documentation additions to RFC 3028, because the + latest draft now contains them. It adds the new en;ascii-case comparator + and a new error check for 8bit text in MIME parts. Comparator and + require names are now matched exactly. I enabled the subaddress + extension, but it is not well tested yet (read: it works for me)." + +PH/20 Added macros for time_t as for off_t (see PH/15 above) and used them to + rework some of the code of TK/09 above to avoid the hardwired use of + "%lld" and "long long". Replaced the call to snprintf() with a call to + string_vformat(). + +PH/21 Added some other messages to those in 4.51/PH/42, namely "All relevant MX + records point to non-existent hosts", "retry timeout exceeded", and + "retry time not reached for any host after a long failure period". + +PH/22 Fixed some oversights/typos causing bugs when Exim is compiled with + experimental DomainKeys support: + + (1) The filter variables $n0-$n9 and $sn0-$sn9 were broken. + (2) On an error such as an illegally used "control", the wrong name for + the control was given. + + These problems did NOT occur unless DomainKeys support was compiled. + +PH/23 Added daemon_startup_retries and daemon_startup_sleep. + +PH/24 Added ${if match_ip condition. + +PH/25 Put debug statements on either side of calls to EXIM_DBOPEN() for hints + databases so that it will be absolutely obvious if a crash occurs in the + DB library. This is a regular occurrence (often caused by mis-matched + db.h files). + +PH/26 Insert a lot of missing (void) casts for functions such as chown(), + chmod(), fcntl(), sscanf(), and other functions from stdio.h. These were + picked up on a user's system that detects such things. There doesn't seem + to be a gcc warning option for this - only an attribute that has to be + put on the function's prototype. It seems that in Fedora Core 4 they have + set this on a number of new functions. No doubt there will be more in due + course. + +PH/27 If a dnslookup or manualroute router is set with verify=only, it need not + specify a transport. However, if an address that was verified by such a + router was the subject of a callout, Exim crashed because it tried to + read the rcpt_include_affixes from the non-existent transport. Now it + just assumes that the setting of that option is false. This bug was + introduced by 4.51/PH/31. + +PH/28 Changed -d+all to exclude +memory, because that information is very + rarely of interest, but it makes the output a lot bigger. People tend to + do -d+all out of habit. + +PH/29 Removed support for the Linux-libc5 build, as it is obsolete and the + code in os-type was giving problems when libc.so lives in lib64, like on + x86_64 Fedora Core. + +PH/30 Exim's DNS code uses the original T_xxx names for DNS record times. These + aren't the modern standard, and it seems that some systems' include files + don't always have them. Exim was already checking for some of the newer + ones like T_AAAA, and defining it itself. I've added checks for all the + record types that Exim uses. + +PH/31 When using GnuTLS, if the parameters cache file did not exist, Exim was + not automatically generating a new one, as it is supposed to. This + prevented TLS from working. If the file did exist, but contained invalid + data, a new version was generated, as expected. It was only the case of a + non-existent file that was broken. + +TK/10 Domainkeys: Fix a bug in verification that caused a crash in conjunction + with a change in libdomainkeys > 0.64. + +TK/11 Domainkeys: Change the logic how the "testing" policy flag is retrieved + from DNS. If the selector record carries the flag, it now has + precedence over the domain-wide flag. + +TK/12 Cleared some compiler warnings related to SPF, SRS and DK code. + +PH/32 In mua_wrapper mode, if an smtp transport configuration error (such as + the use of a port name that isn't defined in /etc/services) occurred, the + message was deferred as in a normal delivery, and thus remained on the + spool, instead of being failed because of the mua_wrapper setting. This + is now fixed, and I tidied up some of the mua_wrapper messages at the + same time. + +SC/08 Eximstats: whilst parsing the mainlog(s), store information about + the messages in a hash of arrays rather than using individual hashes. + This is a bit cleaner and results in dramatic memory savings, albeit + at a slight CPU cost. + +SC/09 Eximstats: added the -show_rt<list> and the -show_dt<list> flags + as requested by Marc Sherman. + +SC/10 Eximstats: added histograms for user specified patterns as requested + by Marc Sherman. + +SC/11 Eximstats: v1.43 - bugfix for pattern histograms with -h0 specified. + +PH/33 Patch from the Cygwin maintainer to add "b" to all occurences of + fopen() in the content-scanning modules that did not already have it. + + +Exim version 4.51 +----------------- + +TK/01 Added Yahoo DomainKeys support via libdomainkeys. See + doc/experimental-spec.txt for details. (http://domainkeys.sf.net) + +TK/02 Fix ACL "control" statement not being available in MIME ACL. + +TK/03 Fix ACL "regex" condition not being available in MIME ACL. + +PH/01 Installed a patch from the Sieve maintainer that allows -bf to be used + to test Sieve filters that use "vacation". + +PH/02 Installed a slightly modified version of Nikos Mavrogiannopoulos' patch + that changes the way the GnuTLS parameters are stored in the cache file. + The new format can be generated externally. For backward compatibility, + if the data in the cache doesn't make sense, Exim assumes it has read an + old-format file, and it generates new data and writes a new file. This + means that you can't go back to an older release without removing the + file. + +PH/03 A redirect router that has both "unseen" and "one_time" set does not + work if there are any delivery delays because "one_time" forces the + parent to be marked "delivered", so its unseen clone is never tried + again. For this reason, Exim now forbids the simultaneous setting of + these two options. + +PH/04 Change 4.11/85 fixed an obscure bug concerned with addresses that are + redirected to themselves ("homonym" addresses). Read the long ChangeLog + entry if you want to know the details. The fix, however, neglected to + consider the case when local delivery batching is involved. The test for + "previously delivered" was not happening when checking to see if an + address could be batched with a previous (undelivered) one; under + certain circumstances this could lead to multiple deliveries to the same + address. + +PH/05 Renamed the macro SOCKLEN_T as EXIM_SOCKLEN_T because AIX uses SOCKLEN_T + in its include files, and this causes problems building Exim. + +PH/06 A number of "verify =" ACL conditions have no options (e.g. verify = + header_syntax) but Exim was just ignoring anything given after a slash. + In particular, this caused confusion with an attempt to use "verify = + reverse_host_lookup/defer_ok". An error is now given when options are + supplied for verify items that do not have them. (Maybe reverse_host_ + lookup should have a defer_ok option, but that's a different point.) + +PH/07 Increase the size of the buffer for incoming SMTP commands from 512 (as + defined by RFC 821) to 2048, because there were problems with some AUTH + commands, and RFC 1869 says the size should be increased for extended + SMTP commands that take arguments. + +PH/08 Added ${dlfunc dynamically loaded function for expansion (code from Tony + Finch). + +PH/09 Previously, an attempt to use ${perl when it wasn't compiled gave an + "unknown" error; now it says that the functionality isn't in the binary. + +PH/10 Added a nasty fudge to try to recognize and flatten LDAP passwords in + an address' error message when a string expansion fails (syntax or + whatever). Otherwise the password may appear in the log. Following change + PH/42 below, there is no longer a chance of it appearing in a bounce + message. + +PH/11 Installed exipick version 20050225.0 from John Jetmore. + +PH/12 If the last host in a fallback_hosts list was multihomed, only the first + of its addresses was ever tried. (Bugzilla bug #2.) + +PH/13 If "headers_add" in a transport didn't end in a newline, Exim printed + the result incorrectly in the debug output. (It correctly added a newline + to what was transported.) + +TF/01 Added $received_time. + +PH/14 Modified the default configuration to add an acl_smtp_data ACL, with + commented out examples of how to interface to a virus scanner and to + SpamAssassin. Also added commented examples of av_scanner and + spamd_address settings. + +PH/15 Further to TK/02 and TK/03 above, tidied up the tables of what conditions + and controls are allowed in which ACLs. There were a couple of minor + errors. Some of the entries in the conditions table (which is a table of + where they are NOT allowed) were getting very unwieldy; rewrote them as a + negation of where the condition IS allowed. + +PH/16 Installed updated OS/os.c-cygwin from the Cygwin maintainer. + +PH/17 The API for radiusclient changed at release 0.4.0. Unfortunately, the + header file does not have a version number, so I've had to invent a new + value for RADIUS_LIB_TYPE, namely "RADIUSCLIENTNEW" to request the new + API. The code is untested by me (my Linux distribution still has 0.3.2 of + radiusclient), but it was contributed by a Radius user. + +PH/18 Installed Lars Mainka's patch for the support of CRL collections in + files or directories, for OpenSSL. + +PH/19 When an Exim process that is running as root has to create an Exim log + file, it does so in a subprocess that runs as exim:exim so as to get the + ownership right at creation (otherwise, other Exim processes might see + the file with the wrong ownership). There was no test for failure of this + fork() call, which would lead to the process getting stuck as it waited + for a non-existent subprocess. Forks do occasionally fail when resources + run out. I reviewed all the other calls to fork(); they all seem to check + for failure. + +PH/20 When checking for unexpected SMTP input at connect time (before writing + the banner), Exim was not dealing correctly with a non-positive return + from the read() function. If the client had disconnected by this time, + the result was a log entry for a synchronization error with an empty + string after "input=" when read() returned zero. If read() returned -1 + (an event I could not check), uninitialized data bytes were printed. + There were reports of junk text (parts of files, etc) appearing after + "input=". + +PH/21 Added acl_not_smtp_mime to allow for MIME scanning for non-SMTP messages. + +PH/22 Added support for macro redefinition, and (re)definition in between + driver and ACL definitions. + +PH/23 The cyrus_sasl authenticator was expanding server_hostname, but then + forgetting to use the resulting value; it was using the unexpanded value. + +PH/24 The cyrus_sasl authenticator was advertising mechanisms for which it + hadn't been configured. The fix is from Juergen Kreileder, who + understands it better than I do: + + "Here's what I see happening with three configured cyrus_sasl + authenticators configured (plain, login, cram-md5): + + On startup auth_cyrus_sasl_init() gets called for each of these. + This means three calls to sasl_listmech() without a specified mech_list. + => SASL tests which mechs of all available mechs actually work + => three warnings about OTP not working + => the returned list contains: plain, login, cram-md5, digest-md5, ... + + With the patch, sasl_listmech() also gets called three times. But now + SASL's mech_list option is set to the server_mech specified in the the + authenticator. Or in other words, the answer from sasl_listmech() + gets limited to just the mech you're testing for (which is different + for each call.) + => the return list contains just 'plain' or 'login', 'cram-md5' or + nothing depending on the value of ob->server_mech. + + I've just tested the patch: Authentication still works fine, + unavailable mechs specified in the exim configuration are still + caught, and the auth.log warnings about OTP are gone." + +PH/25 When debugging is enabled, the contents of the command line are added + to the debugging output, even when log_selector=+arguments is not + specified. + +PH/26 Change scripts/os-type so that when "uname -s" returns just "GNU", the + answer is "GNU", and only if the return is "GNU/something" is the answer + "Linux". + +PH/27 $acl_verify_message is now set immediately after the failure of a + verification in an ACL, and so is available in subsequent modifiers. In + particular, the message can be preserved by coding like this: + + warn !verify = sender + set acl_m0 = $acl_verify_message + + Previously, $acl_verify_message was set only while expanding "message" + and "log_message" when a very denied access. + +PH/28 Modified OS/os.c-Linux with + + -#ifndef OS_LOAD_AVERAGE + +#if !defined(OS_LOAD_AVERAGE) && defined(__linux__) + + to make Exim compile on kfreebsd-gnu. (I'm totally confused about the + nomenclature these days.) + +PH/29 Installed patch from the Sieve maintainer that adds the options + sieve_useraddress and sieve_subaddress to the redirect router. + +PH/30 In these circumstances: + . Two addresses routed to the same list of hosts; + . First host does not offer TLS; + . First host accepts first address; + . First host gives temporary error to second address; + . Second host offers TLS and a TLS session is established; + . Second host accepts second address. + Exim incorrectly logged both deliveries with the TLS parameters (cipher + and peerdn, if requested) that were in fact used only for the second + address. + +PH/31 When doing a callout as part of verifying an address, Exim was not paying + attention to any local part prefix or suffix that was matched by the + router that accepted the address. It now behaves in the same way as it + does for delivery: the affixes are removed from the local part unless + rcpt_include_affixes is set on the transport. + +PH/32 Add the sender address, as F=<...>, to the log line when logging a + timeout during the DATA phase of an incoming message. + +PH/33 Sieve envelope tests were broken for match types other than :is. I have + applied a patch sanctioned by the Sieve maintainer. + +PH/34 Change 4.50/80 broke Exim in that it could no longer handle cases where + the uid or gid is negative. A case of a negative gid caused this to be + noticed. The fix allows for either to be negative. + +PH/35 ACL_WHERE_MIME is now declared unconditionally, to avoid too much code + clutter, but the tables that are indexed by ACL_WHERE_xxx values had been + overlooked. + +PH/36 The change PH/12 above was broken. Fixed it. + +PH/37 Exim used to check for duplicate addresses in the middle of routing, on + the grounds that routing the same address twice would always produce the + same answer. This might have been true once, but it is certainly no + longer true now. Routing a child address may depend on the previous + routing that produced that child. Some complicated redirection strategies + went wrong when messages had multiple recipients, and made Exim's + behaviour dependent on the order in which the addresses were given. + + I have moved the duplicate checking until after the routing is complete. + Exim scans the addresses that are assigned to local and remote + transports, and removes any duplicates. This means that more work will be + done, as duplicates will always all be routed, but duplicates are + presumably rare, so I don't expect this is of any significance. + + For deliveries to pipes, files, and autoreplies, the duplicate checking + still happens during the routing process, since they are not going to be + routed further. + +PH/38 Installed a patch from Ian Freislich, with the agreement of Tom Kistner. + It corrects a timeout issue with spamd. This is Ian's comment: "The + background is that sometimes spamd either never reads data from a + connection it has accepted, or it never writes response data. The exiscan + spam.[ch] uses a 3600 second timeout on spamd socket reads, further, it + blindly assumes that writes won't block so it may never time out." + +PH/39 Allow G after quota size as well as K and M. + +PH/40 The value set for $authenticated_id in an authenticator may not contain + binary zeroes or newlines because the value is written to log lines and + to spool files. There was no check on this. Now the value is run through + the string_printing() function so that such characters are converted to + printable escape sequences. + +PH/41 $message_linecount is a new variable that contains the total number of + lines in the message. Compare $body_linecount, which is the count for the + body only. + +PH/42 Exim no longer gives details of delivery errors for specific addresses in + bounce and delay warning messages, except in certain special cases, which + are as follows: + + (a) An SMTP error message from a remote host; + (b) A message specified in a :fail: redirection; + (c) A message specified in a "fail" command in a system filter; + (d) A message specified in a FAIL return from the queryprogram router; + (e) A message specified by the cannot_route_message router option. + + In these cases only, Exim does include the error details in bounce and + warning messages. There are also a few cases where bland messages such + as "unrouteable address" or "local delivery error" are given. + +PH/43 $value is now also set for the "else" part of a ${run expansion. + +PH/44 Applied patch from the Sieve maintainer: "The vacation draft is still + being worked on, but at least Exim now implements the latest version to + play with." + +PH/45 In a pipe transport, although a timeout while waiting for the pipe + process to complete was treated as a delivery failure, a timeout while + writing the message to the pipe was logged, but erroneously treated as a + successful delivery. Such timeouts include transport filter timeouts. For + consistency with the overall process timeout, these timeouts are now + treated as errors, giving rise to delivery failures by default. However, + there is now a new Boolean option for the pipe transport called + timeout_defer, which, if set TRUE, converts the failures into defers for + both kinds of timeout. A transport filter timeout is now identified in + the log output. + +PH/46 The "scripts/Configure-config.h" script calls "make" at one point. On + systems where "make" and "gmake" are different, calling "gmake" at top + level broke things. I've arranged for the value of $(MAKE) to be passed + from the Makefile to this script so that it can call the same version of + "make". + + +A note about Exim versions 4.44 and 4.50 +---------------------------------------- + +Exim 4.50 was meant to be the next release after 4.43. It contains a lot of +changes of various kinds. As a consequence, a big documentation update was +needed. This delayed the release for rather longer than seemed good, especially +in the light of a couple of (minor) security issues. Therefore, the changes +that fixed bugs were backported into 4.43, to create a 4.44 maintenance +release. So 4.44 and 4.50 are in effect two different branches that both start +from 4.43. + +I have left the 4.50 change log unchanged; it contains all the changes since +4.43. The change log for 4.44 is below; many of its items are identical to +those for 4.50. This seems to be the most sensible way to preserve the +historical information. + + +Exim version 4.50 +----------------- + + 1. Minor wording change to the doc/README.SIEVE file. + + 2. Change 4.43/35 introduced a bug: if quota_filecount was set, the + computation of the current number of files was incorrect. + + 3. Closing a stable door: arrange to panic-die if setitimer() ever fails. The + bug fixed in 4.43/37 would have been diagnosed quickly if this had been in + place. + + 4. Give more explanation in the error message when the command for a transport + filter fails to execute. + + 5. There are several places where Exim runs a non-Exim command in a + subprocess. The SIGUSR1 signal should be disabled for these processes. This + was being done only for the command run by the queryprogram router. It is + now done for all such subprocesses. The other cases are: ${run, transport + filters, and the commands run by the lmtp and pipe transports. + + 6. Added CONFIGURE_GROUP build-time option. + + 7. Some older OS have a limit of 256 on the maximum number of file + descriptors. Exim was using setrlimit() to set 1000 as a large value + unlikely to be exceeded. Change 4.43/17 caused a lot of logging on these + systems. I've change it so that if it can't get 1000, it tries for 256. + + 8. "control=submission" was allowed, but had no effect, in a DATA ACL. This + was an oversight, and furthermore, ever since the addition of extra + controls (e.g. 4.43/32), the checks on when to allow different forms of + "control" were broken. There should now be diagnostics for all cases when a + control that does not make sense is encountered. + + 9. Added the /retain_sender option to "control=submission". + +10. $recipients is now available in the predata ACL (oversight). + +11. Tidy the search cache before the fork to do a delivery from a message + received from the command line. Otherwise the child will trigger a lookup + failure and thereby defer the delivery if it tries to use (for example) a + cached ldap connection that the parent has called unbind on. + +12. If verify=recipient was followed by verify=sender in a RCPT ACL, the value + of $address_data from the recipient verification was clobbered by the + sender verification. + +13. The value of address_data from a sender verification is now available in + $sender_address_data in subsequent conditions in the ACL statement. + +14. Added forbid_sieve_filter and forbid_exim_filter to the redirect router. + +15. Added a new option "connect=<time>" to callout options, to set a different + connection timeout. + +16. If FIXED_NEVER_USERS was defined, but empty, Exim was assuming the uid 0 + was its contents. (It was OK if the option was not defined at all.) + +17. A "Completed" log line is now written for messages that are removed from + the spool by the -Mrm option. + +18. New variables $sender_verify_failure and $recipient_verify_failure contain + information about exactly what failed. + +19. Added -dd to debug only the daemon process. + +20. Incorporated Michael Haardt's patch to ldap.c for improving the way it + handles timeouts, both on the server side and network timeouts. Renamed the + CONNECT parameter as NETTIMEOUT (but kept the old name for compatibility). + +21. The rare case of EHLO->STARTTLS->HELO was setting the protocol to "smtp". + It is now set to "smtps". + +22. $host_address is now set to the target address during the checking of + ignore_target_hosts. + +23. When checking ignore_target_hosts for an ipliteral router, no host name was + being passed; this would have caused $sender_host_name to have been used if + matching the list had actually called for a host name (not very likely, + since this list is usually IP addresses). A host name is now passed as + "[x.x.x.x]". + +24. Changed the calls that set up the SIGCHLD handler in the daemon to use the + code that specifies a non-restarting handler (typically sigaction() in + modern systems) in an attempt to fix a rare and obscure crash bug. + +25. Narrowed the window for a race in the daemon that could cause it to ignore + SIGCHLD signals. This is not a major problem, because they are used only to + wake it up if nothing else does. + +26. A malformed maildirsize file could cause Exim to calculate negative values + for the mailbox size or file count. Odd effects could occur as a result. + The maildirsize information is now recalculated if the size or filecount + end up negative. + +27. Added HAVE_SYS_STATVFS_H to the os.h file for Linux, as it has had this + support for a long time. Removed HAVE_SYS_VFS_H. + +28. Installed the latest version of exipick from John Jetmore. + +29. In an address list, if the pattern was not a regular expression, an empty + subject address (from a bounce message) matched only if the pattern was an + empty string. Non-empty patterns were not even tested. This was the wrong + because it is perfectly reasonable to use an empty address as part of a + database query. An empty address is now tested by patterns that are + lookups. However, all the other forms of pattern expect the subject to + contain a local part and a domain, and therefore, for them, an empty + address still always fails if the pattern is not itself empty. + +30. Exim went into a mad DNS loop when attempting to do a callout where the + host was specified on an smtp transport, and looking it up yielded more + than one IP address. + +31. Re-factored the code for checking spool and log partition space into a + function that finds that data and another that does the check. The former + is then used to implement four new variables: $spool_space, $log_space, + $spool_inodes, and $log_inodes. + +32. The RFC2047 encoding function was originally intended for short strings + such as real names; it was not keeping to the 75-character limit for + encoded words that the RFC imposes. It now respects the limit, and + generates multiple encoded words if necessary. To be on the safe side, I + have increased the buffer size for the ${rfc2047: expansion operator from + 1024 to 2048 bytes. + +33. It is now permitted to omit both strings after an "if" condition; if the + condition is true, the result is "true". As before, when the second string + is omitted, a false condition yields an empty string. This makes it less + cumbersome to write custom ACL and router conditions. + +34. Failure to deliver a bounce message always caused it to be frozen, even if + there was an errors_to setting on the router. The errors_to setting is now + respected. + +35. If an IPv6 address is given for -bh or -bhc, it is now converted to the + canonical form (fully expanded) before being placed in + $sender_host_address. + +36. The table in the code that translates DNS record types into text (T_A to + "A" for instance) was missing entries for NS and CNAME. It is just possible + that this could have caused confusion if both these types were looked up + for the same domain, because the text type is used as part of Exim's + per-process caching. But the chance of anyone hitting this buglet seems + very small. + +37. The dnsdb lookup has been extended in a number of ways. + + (1) There is a new type, "zns", which walks up the domain tree until it + finds some nameserver records. It should be used with care. + + (2) There is a new type, "mxh", which is like "mx" except that it returns + just the host names, not the priorities. + + (3) It is now possible to give a list of domains (or IP addresses) to be + looked up. The behaviour when one of the lookups defers can be + controlled by a keyword. + + (4) It is now possible to specify the separator character for use when + multiple records are returned. + +38. The dnslists ACL condition has been extended: it is now possible to supply + a list of IP addresses and/or domains to be looked up in a particular DNS + domain. + +39. Added log_selector=+queue_time_overall. + +40. When running the queue in the test harness, wait just a tad after forking a + delivery process, to get repeatability of debugging output. + +41. Include certificate and key file names in error message when GnuTLS fails + to set them up, because the GnuTLS error message doesn't include the name + of the failing file when there is a problem reading it. + +42. Allow both -bf and -bF in the same test run. + +43. Did the same fix as 41 above for OpenSSL, which had the same infelicity. + +44. The "Exiscan patch" is now merged into the mainline Exim source. + +45. Sometimes the final signoff response after QUIT could fail to get + transmitted in the non-TLS case. Testing !tls_active instead of tls_active + < 0 before doing a fflush(). This bug looks as though it goes back to the + introduction of TLS in release 3.20, but "sometimes" must have been rare + because the tests only now provoked it. + +46. Reset the locale to "C" after calling embedded Perl, in case it was changed + (this can affect the format of dates). + +47. exim_tidydb, when checking for the continued existence of a message for + which it has found a message-specific retry record, was not finding + messages that were in split spool directories. Consequently, it was + deleting retry records that should have stayed in existence. + +48. Steve fixed some bugs in eximstats. + +49. The SPA authentication driver was not abandoning authentication and moving + on to the next authenticator when an expansion was forced to fail, + contradicting the general specification for all authenticators. Instead it + was generating a temporary error. It now behaves as specified. + +50. The default ordering of permitted cipher suites for GnuTLS was pessimal + (the order specifies the preference for clients). The order is now AES256, + AES128, 3DES, ARCFOUR128. + +51. Small patch to Sieve code - explicitly set From: when generating an + autoreply. + +52. Exim crashed if a remote delivery caused a very long error message to be + recorded - for instance if somebody sent an entire SpamAssassin report back + as a large number of 550 error lines. This bug was coincidentally fixed by + increasing the size of one of Exim's internal buffers (big_buffer) that + happened as part of the Exiscan merge. However, to be on the safe side, I + have made the code more robust (and fixed the comments that describe what + is going on). + +53. Now that there can be additional text after "Completed" in log lines (if + the queue_time_overall log selector is set), a one-byte patch to exigrep + was needed to allow it to recognize "Completed" as not the last thing in + the line. + +54. The LDAP lookup was not handling a return of LDAP_RES_SEARCH_REFERENCE. A + patch that reportedly fixes this has been added. I am not expert enough to + create a test for it. This is what the patch creator wrote: + + "I found a little strange behaviour of ldap code when working with + Windows 2003 AD Domain, where users was placed in more than one + Organization Units. When I tried to give exim partial DN, the exit code + of ldap_search was unknown to exim because of LDAP_RES_SEARCH_REFERENCE. + But simultaneously result of request was absolutely normal ldap result, + so I produce this patch..." + + Later: it seems that not all versions of LDAP support LDAP_RES_SEARCH_ + REFERENCE, so I have modified the code to exclude the patch when that macro + is not defined. + +55. Some experimental protocols are using DNS PTR records for new purposes. The + keys for these records are domain names, not reversed IP addresses. The + dnsdb PTR lookup now tests whether its key is an IP address. If not, it + leaves it alone. Component reversal etc. now happens only for IP addresses. + CAN-2005-0021 + +56. Improve error message when ldap_search() fails in OpenLDAP or Solaris LDAP. + +57. Double the size of the debug message buffer (to 2048) so that more of very + long debug lines gets shown. + +58. The exicyclog utility now does better if the number of log files to keep + exceeds 99. In this case, it numbers them 001, 002 ... instead of 01, 02... + +59. Two changes related to the smtp_active_hostname option: + + (1) $smtp_active_hostname is now available as a variable. + (2) The default for smtp_banner uses $smtp_active_hostname instead + of $primary_hostname. + +60. The host_aton() function is supposed to be passed a string that is known + to be a valid IP address. However, in the case of IPv6 addresses, it was + not checking this. This is a hostage to fortune. Exim now panics and dies + if the condition is not met. A case was found where this could be provoked + from a dnsdb PTR lookup with an IPv6 address that had more than 8 + components; fortuitously, this particular loophole had already been fixed + by change 4.50/55 above. + + If there are any other similar loopholes, the new check in host_aton() + itself should stop them being exploited. The report I received stated that + data on the command line could provoke the exploit when Exim was running as + exim, but did not say which command line option was involved. All I could + find was the use of -be with a bad dnsdb PTR lookup, and in that case it is + running as the user. + CAN-2005-0021 + +61. There was a buffer overflow vulnerability in the SPA authentication code + (which came originally from the Samba project). I have added a test to the + spa_base64_to_bits() function which I hope fixes it. + CAN-2005-0022 + +62. Configuration update for GNU/Hurd and variations. Updated Makefile-GNU and + os.h-GNU, and added configuration files for GNUkFreeBSD and GNUkNetBSD. + +63. The daemon start-up calls getloadavg() while still root for those OS that + need the first call to be done as root, but it missed one case: when + deliver_queue_load_max is set with deliver_drop_privilege. This is + necessary for the benefit of the queue runner, because there is no re-exec + when deliver_drop_privilege is set. + +64. A call to exiwhat cut short delays set up by "delay" modifiers in ACLs. + This has been fixed. + +65. Caching of lookup data for "hosts =" ACL conditions, when a named host list + was in use, was not putting the data itself into the right store pool; + consequently, it could be overwritten for a subsequent message in the same + SMTP connection. (Fix 4.40/11 dealt with the non-cache case, but overlooked + the caching.) + +66. Added hosts_max_try_hardlimit to the smtp transport, default 50. + +67. The string_is_ip_address() function returns 0, 4, or 6, for "no an IP + address", "IPv4 address", and "IPv6 address", respectively. Some calls of + the function were treating the return as a boolean value, which happened to + work because 0=false and not-0=true, but is not correct code. + +68. The host_aton() function was not handling scoped IPv6 addresses (those + with, for example, "%eth0" on the end) correctly. + +69. Fixed some compiler warnings in acl.c for the bitmaps specified with + negated items (that is, ~something) in unsigned ints. Some compilers + apparently mutter when there is no cast. + +70. If an address verification called from an ACL failed, and did not produce a + user-specific message (i.e. there was only a "system" message), nothing was + put in $acl_verify_message. In this situation, it now puts the system + message there. + +71. Change 4.23/11 added synchronization checking at the start of an SMTP + session; change 4.31/43 added the unwanted input to the log line - except + that it did not do this in the start of session case. It now does. + +72. After a timeout in a callout SMTP session, Exim still sent a QUIT command. + This is wrong and can cause the other end to generate a synchronization + error if it is another Exim or anything else that does the synchronization + check. A QUIT command is no longer sent after a timeout. + +73. $host_lookup_deferred has been added, to make it easier to detect DEFERs + during host lookups. + +74. The defer_ok option of callout verification was not working if it was used + when verifying addresses in header lines, that is, for this case: + + verify = header_sender/callout=defer_ok + +75. A backgrounded daemon closed stdin/stdout/stderr on entry; this meant that + those file descriptors could be used for SMTP connections. If anything + wrote to stderr (the example that came up was "warn" in embedded Perl), it + could be sent to the SMTP client, causing chaos. The daemon now opens + stdin, stdout, and stderr to /dev/null when it puts itself into the + background. + +76. Arrange for output from Perl's "warn" command to be written to Exim's main + log by default. The user can override this with suitable Perl magic. + +77. The use of log_message on a "discard" ACL verb, which is supposed to add to + the log message when discard triggers, was not working for the DATA ACL or + for the non-SMTP ACL. + +78. Error message wording change in sieve.c. + +79. If smtp_accept_max_per_host was set, the number of connections could be + restricted to fewer than expected, because the daemon was trying to set up + a new connection before checking whether the processes handling previous + connections had finished. The check for completed processes is now done + earlier. On busy systems, this bug wouldn't be noticed because something + else would have woken the daemon, and it would have reaped the completed + process earlier. + +80. If a message was submitted locally by a user whose login name contained one + or more spaces (ugh!), the spool file that Exim wrote was not re-readable. + It caused a spool format error. I have fixed the spool reading code. A + related problem was that the "from" clause in the Received: line became + illegal because of the space(s). It is now covered by ${quote_local_part. + +81. Included the latest eximstats from Steve (adds average sizes to HTML Top + tables). + +82. Updated OS/Makefile-AIX as per message from Mike Meredith. + +83. Patch from Sieve maintainer to fix unterminated string problem in + "vacation" handling. + +84. Some minor changes to the Linux configuration files to help with other + OS variants using glibc. + +85. One more patch for Sieve to update vacation handling to latest spec. + + +---------------------------------------------------- +See the note above about the 4.44 and 4.50 releases. +---------------------------------------------------- + + +Exim version 4.44 +----------------- + + 1. Change 4.43/35 introduced a bug that caused file counts to be + incorrectly computed when quota_filecount was set in an appendfile + transport + + 2. Closing a stable door: arrange to panic-die if setitimer() ever fails. The + bug fixed in 4.43/37 would have been diagnosed quickly if this had been in + place. + + 3. Give more explanation in the error message when the command for a transport + filter fails to execute. + + 4. There are several places where Exim runs a non-Exim command in a + subprocess. The SIGUSR1 signal should be disabled for these processes. This + was being done only for the command run by the queryprogram router. It is + now done for all such subprocesses. The other cases are: ${run, transport + filters, and the commands run by the lmtp and pipe transports. + + 5. Some older OS have a limit of 256 on the maximum number of file + descriptors. Exim was using setrlimit() to set 1000 as a large value + unlikely to be exceeded. Change 4.43/17 caused a lot of logging on these + systems. I've change it so that if it can't get 1000, it tries for 256. + + 6. "control=submission" was allowed, but had no effect, in a DATA ACL. This + was an oversight, and furthermore, ever since the addition of extra + controls (e.g. 4.43/32), the checks on when to allow different forms of + "control" were broken. There should now be diagnostics for all cases when a + control that does not make sense is encountered. + + 7. $recipients is now available in the predata ACL (oversight). + + 8. Tidy the search cache before the fork to do a delivery from a message + received from the command line. Otherwise the child will trigger a lookup + failure and thereby defer the delivery if it tries to use (for example) a + cached ldap connection that the parent has called unbind on. + + 9. If verify=recipient was followed by verify=sender in a RCPT ACL, the value + of $address_data from the recipient verification was clobbered by the + sender verification. + +10. If FIXED_NEVER_USERS was defined, but empty, Exim was assuming the uid 0 + was its contents. (It was OK if the option was not defined at all.) + +11. A "Completed" log line is now written for messages that are removed from + the spool by the -Mrm option. + +12. $host_address is now set to the target address during the checking of + ignore_target_hosts. + +13. When checking ignore_target_hosts for an ipliteral router, no host name was + being passed; this would have caused $sender_host_name to have been used if + matching the list had actually called for a host name (not very likely, + since this list is usually IP addresses). A host name is now passed as + "[x.x.x.x]". + +14. Changed the calls that set up the SIGCHLD handler in the daemon to use the + code that specifies a non-restarting handler (typically sigaction() in + modern systems) in an attempt to fix a rare and obscure crash bug. + +15. Narrowed the window for a race in the daemon that could cause it to ignore + SIGCHLD signals. This is not a major problem, because they are used only to + wake it up if nothing else does. + +16. A malformed maildirsize file could cause Exim to calculate negative values + for the mailbox size or file count. Odd effects could occur as a result. + The maildirsize information is now recalculated if the size or filecount + end up negative. + +17. Added HAVE_SYS_STATVFS_H to the os.h file for Linux, as it has had this + support for a long time. Removed HAVE_SYS_VFS_H. + +18. Updated exipick to current release from John Jetmore. + +19. Allow an empty sender to be matched against a lookup in an address list. + Previously the only cases considered were a regular expression, or an + empty pattern. + +20. Exim went into a mad DNS lookup loop when doing a callout where the + host was specified on the transport, if the DNS lookup yielded more than + one IP address. + +21. The RFC2047 encoding function was originally intended for short strings + such as real names; it was not keeping to the 75-character limit for + encoded words that the RFC imposes. It now respects the limit, and + generates multiple encoded words if necessary. To be on the safe side, I + have increased the buffer size for the ${rfc2047: expansion operator from + 1024 to 2048 bytes. + +22. Failure to deliver a bounce message always caused it to be frozen, even if + there was an errors_to setting on the router. The errors_to setting is now + respected. + +23. If an IPv6 address is given for -bh or -bhc, it is now converted to the + canonical form (fully expanded) before being placed in + $sender_host_address. + +24. Updated eximstats to version 1.33 + +25. Include certificate and key file names in error message when GnuTLS fails + to set them up, because the GnuTLS error message doesn't include the name + of the failing file when there is a problem reading it. + +26. Expand error message when OpenSSL has problems setting up cert/key files. + As per change 25. + +27. Reset the locale to "C" after calling embedded Perl, in case it was changed + (this can affect the format of dates). + +28. exim_tidydb, when checking for the continued existence of a message for + which it has found a message-specific retry record, was not finding + messages that were in split spool directories. Consequently, it was + deleting retry records that should have stayed in existence. + +29. eximstats updated to version 1.35 + 1.34 - allow eximstats to parse syslog lines as well as mainlog lines + 1.35 - bugfix such that pie charts by volume are generated correctly + +30. The SPA authentication driver was not abandoning authentication and moving + on to the next authenticator when an expansion was forced to fail, + contradicting the general specification for all authenticators. Instead it + was generating a temporary error. It now behaves as specified. + +31. The default ordering of permitted cipher suites for GnuTLS was pessimal + (the order specifies the preference for clients). The order is now AES256, + AES128, 3DES, ARCFOUR128. + +31. Small patch to Sieve code - explicitly set From: when generating an + autoreply. + +32. Exim crashed if a remote delivery caused a very long error message to be + recorded - for instance if somebody sent an entire SpamAssassin report back + as a large number of 550 error lines. This bug was coincidentally fixed by + increasing the size of one of Exim's internal buffers (big_buffer) that + happened as part of the Exiscan merge. However, to be on the safe side, I + have made the code more robust (and fixed the comments that describe what + is going on). + +33. Some experimental protocols are using DNS PTR records for new purposes. The + keys for these records are domain names, not reversed IP addresses. The + dnsdb PTR lookup now tests whether its key is an IP address. If not, it + leaves it alone. Component reversal etc. now happens only for IP addresses. + CAN-2005-0021 + +34. The host_aton() function is supposed to be passed a string that is known + to be a valid IP address. However, in the case of IPv6 addresses, it was + not checking this. This is a hostage to fortune. Exim now panics and dies + if the condition is not met. A case was found where this could be provoked + from a dnsdb PTR lookup with an IPv6 address that had more than 8 + components; fortuitously, this particular loophole had already been fixed + by change 4.50/55 or 4.44/33 above. + + If there are any other similar loopholes, the new check in host_aton() + itself should stop them being exploited. The report I received stated that + data on the command line could provoke the exploit when Exim was running as + exim, but did not say which command line option was involved. All I could + find was the use of -be with a bad dnsdb PTR lookup, and in that case it is + running as the user. + CAN-2005-0021 + +35. There was a buffer overflow vulnerability in the SPA authentication code + (which came originally from the Samba project). I have added a test to the + spa_base64_to_bits() function which I hope fixes it. + CAN-2005-0022 + +36. The daemon start-up calls getloadavg() while still root for those OS that + need the first call to be done as root, but it missed one case: when + deliver_queue_load_max is set with deliver_drop_privilege. This is + necessary for the benefit of the queue runner, because there is no re-exec + when deliver_drop_privilege is set. + +37. Caching of lookup data for "hosts =" ACL conditions, when a named host list + was in use, was not putting the data itself into the right store pool; + consequently, it could be overwritten for a subsequent message in the same + SMTP connection. (Fix 4.40/11 dealt with the non-cache case, but overlooked + the caching.) + +38. Sometimes the final signoff response after QUIT could fail to get + transmitted in the non-TLS case. Testing !tls_active instead of tls_active + < 0 before doing a fflush(). This bug looks as though it goes back to the + introduction of TLS in release 3.20, but "sometimes" must have been rare + because the tests only now provoked it. + + +Exim version 4.43 +----------------- + + 1. Fixed a longstanding but relatively impotent bug: a long time ago, before + PIPELINING, the function smtp_write_command() used to return TRUE or FALSE. + Now it returns an integer. A number of calls were still expecting a T/F + return. Fortuitously, in all cases, the tests worked in OK situations, + which is the norm. However, things would have gone wrong on any write + failures on the smtp file descriptor. This function is used when sending + messages over SMTP and also when doing verify callouts. + + 2. When Exim is called to do synchronous delivery of a locally submitted + message (the -odf or -odi options), it no longer closes stderr before doing + the delivery. + + 3. Implemented the mua_wrapper option. + + 4. Implemented mx_fail_domains and srv_fail_domains for the dnslookup router. + + 5. Implemented the functions header_remove(), header_testname(), + header_add_at_position(), and receive_remove_recipient(), and exported them + to local_scan(). + + 6. If an ACL "warn" statement specified the addition of headers, Exim already + inserted X-ACL-Warn: at the start if there was no header name. However, it + was not making this test for the second and subsequent header lines if + there were newlines in the string. This meant that an invalid header could + be inserted if Exim was badly configured. + + 7. Allow an ACL "warn" statement to add header lines at the start or after all + the Received: headers, as well as at the end. + + 8. Added the rcpt_4xx retry error code. + + 9. Added postmaster_mailfrom=xxx to callout verification option. + +10. Added mailfrom=xxxx to the callout verification option, for verify= + header_sender only. + +11. ${substr_1_:xxxx} and ${substr__3:xxxx} are now diagnosed as syntax errors + (they previously behaved as ${substr_1_0:xxxx} and ${substr:_0_3:xxxx}). + +12. Inserted some casts to stop certain compilers warning when using pointer + differences as field lengths or precisions in printf-type calls (mostly + affecting debugging statements). + +13. Added optional readline() support for -be (dynamically loaded). + +14. Obscure bug fix: if a message error (e.g. 4xx to MAIL) happened within the + same clock tick as a message's arrival, so that its received time was the + same as the "first fail" time on the retry record, and that message + remained on the queue past the ultimate address timeout, every queue runner + would try a delivery (because it was past the ultimate address timeout) but + after another failure, the ultimate address timeout, which should have then + bounced the address, did not kick in. This was a "< instead of <=" error; + in most cases the first failure would have been in the next clock tick + after the received time, and all would be well. + +15. The special items beginning with @ in domain lists (e.g. @mx_any) were not + being recognized when the domain list was tested by the match_domain + condition in an expansion string. + +16. Added the ${str2b64: operator. + +17. Exim was always calling setrlimit() to set a large limit for the number of + processes, without checking whether the existing limit was already + adequate. (It did check for the limit on file descriptors.) Furthermore, + errors from getrlimit() and setrlimit() were being ignored. Now they are + logged to the main and panic logs, but Exim does carry on, to try to do its + job under whatever limits there are. + +18. Imported PCRE 5.0. + +19. Trivial typo in log message " temporarily refused connection" (the leading + space). + +20. If the log selector return_path_on_delivery was set and an address was + redirected to /dev/null, the delivery process crashed because it assumed + that a return path would always be set for a "successful" delivery. In this + case, the whole delivery is bypassed as an optimization, and therefore no + return path is set. + +21. Internal re-arrangement: the function for sending a challenge and reading + a response while authentication was assuming a zero-terminated challenge + string. It's now changed to take a pointer and a length, to allow for + binary data in such strings. + +22. Added the cyrus_sasl authenticator (code supplied by MBM). + +23. Exim was not respecting finduser_retries when seeking the login of the + uid under which it was called; it was always trying 10 times. (The default + setting of finduser_retries is zero.) Also, it was sleeping after the final + failure, which is pointless. + +24. Implemented tls_on_connect_ports. + +25. Implemented acl_smtp_predata. + +26. If the domain in control=submission is set empty, Exim assumes that the + authenticated id is a complete email address when it generates From: or + Sender: header lines. + +27. Added "#define SOCKLEN_T int" to OS/os.h-SCO and OS/os.h-SCO_SV. Also added + definitions to OS/Makefile-SCO and OS/Makefile-SCO_SV that put basename, + chown and chgrp in /bin and hostname in /usr/bin. + +28. Exim was keeping the "process log" file open after each use, just as it + does for the main log. This opens the possibility of it remaining open for + long periods when the USR1 signal hits a daemon. Occasional processlog + errors were reported, that could have been caused by this. Anyway, it seems + much more sensible not to leave this file open at all, so that is what now + happens. + +29. The long-running daemon process does not normally write to the log once it + has entered its main loop, and it closes the log before doing so. This is + so that log files can straightforwardly be renamed and moved. However, + there are a couple of unusual error situations where the daemon does write + log entries, and I had neglected to close the log afterwards. + +30. The text of an SMTP error response that was received during a remote + delivery was being truncated at 512 bytes. This is too short for some of + the long messages that one sometimes sees. I've increased the limit to + 1024. + +31. It is now possible to make retry rules that apply only when a message has a + specific sender, in particular, an empty sender. + +32. Added "control = enforce_sync" and "control = no_enforce_sync". This makes + it possible to be selective about when SMTP synchronization is enforced. + +33. Added "control = caseful_local_part" and "control = "caselower_local_part". + +32. Implemented hosts_connection_nolog. + +33. Added an ACL for QUIT. + +34. Setting "delay_warning=" to disable warnings was not working; it gave a + syntax error. + +35. Added mailbox_size and mailbox_filecount to appendfile. + +36. Added control = no_multiline_responses to ACLs. + +37. There was a bug in the logic of the code that waits for the clock to tick + in the case where the clock went backwards by a substantial amount such + that the microsecond fraction of "now" was more than the microsecond + fraction of "then" (but the whole seconds number was less). + +38. Added support for the libradius Radius client library this is found on + FreeBSD (previously only the radiusclient library was supported). + + +Exim version 4.42 +----------------- + + 1. When certain lookups returned multiple values in the form name=value, the + quoting of the values was not always being done properly. Specifically: + (a) If the value started with a double quote, but contained no whitespace, + it was not quoted. + (b) If the value contained whitespace other than a space character (i.e. + tabs or newlines or carriage returns) it was not quoted. + This fix has been applied to the mysql and pgsql lookups by writing a + separate quoting function and calling it from the lookup code. The fix + should probably also be applied to nisplus, ibase and oracle lookups, but + since I cannot test any of those, I have not disturbed their existing code. + + 2. A hit in the callout cache for a specific address caused a log line with no + reason for rejecting RCPT. Now it says "Previous (cached) callout + verification failure". + + 3. There was an off-by-one bug in the queryprogram router. An over-long + return line was truncated at 256 instead of 255 characters, thereby + overflowing its buffer with the terminating zero. As well as fixing this, I + have increased the buffer size to 1024 (and made a note to document this). + + 4. If an interrupt, such as the USR1 signal that is send by exiwhat, arrives + when Exim is waiting for an SMTP response from a remote server, Exim + restarts its select() call on the socket, thereby resetting its timeout. + This is not a problem when such interrupts are rare. Somebody set up a cron + job to run exiwhat every 2 minutes, which is less than the normal select() + timeout (5 or 10 minutes). This meant that the select() timeout never + kicked in because it was always reset. I have fixed this by comparing the + time when an interrupt arrives with the time at the start of the first call + to select(). If more time than the timeout has elapsed, the interrupt is + treated as a timeout. + + 5. Some internal re-factoring in preparation for the addition of Sieve + extensions (by MH). In particular, the "personal" test is moved to a + separate function, and given an option for scanning Cc: and Bcc: (which is + not set for Exim filters). + + 6. When Exim created an email address using the login of the caller as the + local part (e.g. when creating a From: or Sender: header line), it was not + quoting the local part when it contained special characters such as @. + + 7. Installed new OpenBSD configuration files. + + 8. Reworded some messages for syntax errors in "and" and "or" conditions to + try to make them clearer. + + 9. Callout options, other than the timeout value, were being ignored when + verifying sender addresses in header lines. For example, when using + + verify = header_sender/callout=no_cache + + the cache was (incorrectly) being used. + +10. Added a missing instance of ${EXE} to the exim_install script; this affects + only the Cygwin environment. + +11. When return_path_on_delivery was set as a log selector, if different remote + addresses in the same message used different return paths and parallel + remote delivery occurred, the wrong values would sometimes be logged. + (Whenever a remote delivery process finished, the return path value from + the most recently started remote delivery process was logged.) + +12. RFC 3848 specifies standard names for the "with" phrase in Received: header + lines when AUTH and/or TLS are in use. This is the "received protocol" + field. Exim used to use "asmtp" for authenticated SMTP, without any + indication (in the protocol name) for TLS use. Now it follows the RFC and + uses "esmtpa" if the connection is authenticated, "esmtps" if it is + encrypted, and "esmtpsa" if it is both encrypted and authenticated. These + names appear in log lines as well as in Received: header lines. + +13. Installed MH's patches for Sieve to add the "copy" and "vacation" + extensions, and comparison tests, and to fix some bugs. + +14. Changes to the "personal" filter test: + + (1) The test was buggy in that it was just doing the equivalent of + "contains" tests on header lines. For example, if a user's address was + anne@some.where, the "personal" test would incorrectly be true for + + To: susanne@some.where + + This test is now done by extracting each address from the header in turn, + and checking the entire address. Other tests that are part of "personal" + are now done using regular expressions (for example, to check local parts + of addresses in From: header lines). + + (2) The list of non-personal local parts in From: addresses has been + extended to include "listserv", "majordomo", "*-request", and "owner-*", + taken from the Sieve specification recommendations. + + (3) If the message contains any header line starting with "List-" it is + treated as non-personal. + + (4) The test for "circular" in the Subject: header line has been removed + because it now seems ill-conceived. + +15. Minor typos in src/EDITME comments corrected. + +16. Installed latest exipick from John Jetmore. + +17. If headers_add on a router specified a text string that was too long for + string_sprintf() - that is, longer than 8192 bytes - Exim panicked. The use + of string_sprintf() is now avoided. + +18. $message_body_size was not set (it was always zero) when running the DATA + ACL and the local_scan() function. + +19. For the "mail" command in an Exim filter, no default was being set for + the once_repeat time, causing a random time value to be used if "once" was + specified. (If the value happened to be <= 0, no repeat happened.) The + default is now 0s, meaning "never repeat". The "vacation" command was OK + (its default is 7d). It's somewhat surprising nobody ever noticed this bug + (I found it when inspecting the code). + +20. There is now an overall timeout for performing a callout verification. It + defaults to 4 times the callout timeout, which applies to individual SMTP + commands during the callout. The overall timeout applies when there is more + than one host that can be tried. The timeout is checked before trying the + next host. This prevents very long delays if there are a large number of + hosts and all are timing out (e.g. when the network connections are timing + out). The value of the overall timeout can be changed by specifying an + additional sub-option for "callout", called "maxwait". For example: + + verify = sender/callout=5s,maxwait=20s + +21. Add O_APPEND to the open() call for maildirsize files (Exim already seeks + to the end before writing, but this should make it even safer). + +22. Exim was forgetting that it had advertised PIPELINING for the second and + subsequent messages on an SMTP connection. It was also not resetting its + memory on STARTTLS and an internal HELO. + +23. When Exim logs an SMTP synchronization error within a session, it now + records whether PIPELINING has been advertised or not. + +24. Added 3 instances of "(long int)" casts to time_t variables that were being + formatted using %ld, because on OpenBSD (and perhaps others), time_t is int + rather than long int. + +25. Installed the latest Cygwin configuration files from the Cygwin maintainer. + +26. Added the never_mail option to autoreply. + + +Exim version 4.41 +----------------- + + 1. A reorganization of the code in order to implement 4.40/8 caused a daemon + crash if the getsockname() call failed; this can happen if a connection is + closed very soon after it is established. The problem was simply in the + order in which certain operations were done, causing Exim to try to write + to the SMTP stream before it had set up the file descriptor. The bug has + been fixed by making things happen in the correct order. + + +Exim version 4.40 +----------------- + + 1. If "drop" was used in a DATA ACL, the SMTP output buffer was not flushed + before the connection was closed, thus losing the rejection response. + + 2. Commented out the definition of SOCKLEN_T in os.h-SunOS5. It is needed for + some early Solaris releases, but causes trouble in current releases where + socklen_t is defined. + + 3. When std{in,out,err} are closed, re-open them to /dev/null so that they + always exist. + + 4. Minor refactoring of os.c-Linux to avoid compiler warning when IPv6 is not + configured. + + 5. Refactoring in expand.c to improve memory usage. Pre-allocate a block so + that releasing the top of it at the end releases what was used for sub- + expansions (unless the block got too big). However, discard this block if + the first thing is a variable or header, so that we can use its block when + it is dynamic (useful for very large $message_headers, for example). + + 6. Lookups now cache *every* query, not just the most recent. A new, separate + store pool is used for this. It can be recovered when all lookup caches are + flushed. Lookups now release memory at the end of their result strings. + This has involved some general refactoring of the lookup sources. + + 7. Some code has been added to the store_xxx() functions to reduce the amount + of flapping under certain conditions. + + 8. log_incoming_interface used to affect only the <= reception log lines. Now + it causes the local interface and port to be added to several more SMTP log + lines, for example "SMTP connection from", and rejection lines. + + 9. The Sieve author supplied some patches for the doc/README.SIEVE file. + +10. Added a conditional definition of _BSD_SOCKLEN_T to os.h-Darwin. + +11. If $host_data was set by virtue of a hosts lookup in an ACL, its value + could be overwritten at the end of the current message (or the start of a + new message if it was set in a HELO ACL). The value is now preserved for + the duration of the SMTP connection. + +12. If a transport had a headers_rewrite setting, and a matching header line + contained an unqualified address, that address was qualified, even if it + did not match any rewriting rules. The underlying bug was that the values + of the flags that permit the existence of unqualified sender and recipient + addresses in header lines (set by {sender,recipient}_unqualified_hosts for + non-local messages, and by -bnq for local messages) were not being + preserved with the message after it was received. + +13. When Exim was logging an SMTP synchronization error, it could sometimes log + "next input=" as part of the text comprising the host identity instead of + the correct text. The code was using the same buffer for two different + strings. However, depending on which order the printing function evaluated + its arguments, the bug did not always show up. Under Linux, for example, my + test suite worked just fine. + +14. Exigrep contained a use of Perl's "our" scoping after change 4.31/70. This + doesn't work with some older versions of Perl. It has been changed to "my", + which in any case is probably the better facility to use. + +15. A really picky compiler found some instances of statements for creating + error messages that either had too many or two few arguments for the format + string. + +16. The size of the buffer for calls to the DNS resolver has been increased + from 1024 to 2048. A larger buffer is needed when performing PTR lookups + for addresses that have a lot of PTR records. This alleviates a problem; it + does not fully solve it. + +17. A dnsdb lookup for PTR records that receives more data than will fit in the + buffer now truncates the list and logs the incident, which is the same + action as happens when Exim is looking up a host name and its aliases. + Previously in this situation something unpredictable would happen; + sometimes it was "internal error: store_reset failed". + +18. If a server dropped the connection unexpectedly when an Exim client was + using GnuTLS and trying to read a response, the client delivery process + crashed while trying to generate an error log message. + +19. If a "warn" verb in an ACL added multiple headers to a message in a single + string, for example: + + warn message = H1: something\nH2: something + + the text was added as a single header line from Exim's point of view + though it ended up OK in the delivered message. However, searching for the + second and subsequent header lines using $h_h2: did not work. This has been + fixed. Similarly, if a system filter added multiple headers in this way, + the routers could not see them. + +20. Expanded the error message when iplsearch is called with an invalid key to + suggest using net-iplsearch in a host list. + +21. When running tests using -bh, any delays imposed by "delay" modifiers in + ACLs are no longer actually imposed (and a message to that effect is + output). + +22. If a "gecos" field in a passwd entry contained escaped characters, in + particular, if it contained a \" sequence, Exim got it wrong when building + a From: or a Sender: header from that name. A second bug also caused + incorrect handling when an unquoted " was present following a character + that needed quoting. + +23. "{crypt}" as a password encryption mechanism for a "crypteq" expansion item + was not being matched caselessly. + +24. Arranged for all hyphens in the exim.8 source to be escaped with + backslashes. + +25. Change 16 of 4.32, which reversed 71 or 4.31 didn't quite do the job + properly. Recipient callout cache records were still being keyed to include + the sender, even when use_sender was set false. This led to far more + callouts that were necessary. The sender is no longer included in the key + when use_sender is false. + +26. Added "control = submission" modifier to ACLs. + +27. Added the ${base62d: operator to decode base 62 numbers. + +28. dnsdb lookups can now access SRV records. + +29. CONFIGURE_OWNER can be set at build time to define an alternative owner for + the configuration file. + +30. The debug message "delivering xxxxxx-xxxxxx-xx" is now output in verbose + (-v) mode. This makes the output for a verbose queue run more intelligible. + +31. Added a use_postmaster feature to recipient callouts. + +32. Added the $body_zerocount variable, containing the number of binary zero + bytes in the message body. + +33. The time of last modification of the "new" subdirectory is now used as the + "mailbox time last read" when there is a quota error for a maildir + delivery. + +34. Added string comparison operators lt, lti, le, lei, gt, gti, ge, gei. + +35. Added +ignore_unknown as a special item in host lists. + +36. Code for decoding IPv6 addresses in host lists is now included, even if + IPv6 support is not being compiled. This fixes a bug in which an IPv6 + address was recognized as an IP address, but was then not correctly decoded + into binary, causing unexpected and incorrect effects when compared with + another IP address. + + +Exim version 4.34 +----------------- + + 1. Very minor rewording of debugging text in manualroute to say "list of + hosts" instead of "hostlist". + + 2. If verify=header_syntax was set, and a header line with an unqualified + address (no domain) and a large number of spaces between the end of the + name and the colon was received, the reception process suffered a buffer + overflow, and (when I tested it) crashed. This was caused by some obsolete + code that should have been removed. The fix is to remove it! + + 3. When running in the test harness, delay a bit after writing a bounce + message to get a bit more predictability in the log output. + + 4. Added a call to search_tidyup() just before forking a reception process. In + theory, someone could use a lookup in the expansion of smtp_accept_max_ + per_host which, without the tidyup, could leave open a database connection. + + 5. Added the variables $recipient_data and $sender_data which get set from a + lookup success in an ACL "recipients" or "senders" condition, or a router + "senders" option, similar to $domain_data and $local_part_data. + + 6. Moved the writing of debug_print from before to after the "senders" test + for routers. + + 7. Change 4.31/66 (moving the time when the Received: is generated) caused + problems for message scanning, either using a data ACL, or using + local_scan() because the Received: header was not generated till after they + were called (in order to set the time as the time of reception completion). + I have revised the way this works. The header is now generated after the + body is received, but before the ACL or local_scan() are called. After they + are run, the timestamp in the header is updated. + + +Exim version 4.33 +----------------- + + 1. Change 4.24/6 introduced a bug because the SIGALRM handler was disabled + before starting a queue runner without re-exec. This happened only when + deliver_drop_privilege was set or when the Exim user was set to root. The + effect of the bug was that timeouts during subsequent deliveries caused + crashes instead of being properly handled. The handler is now left at its + default (and expected) setting. + + 2. The other case in which a daemon avoids a re-exec is to deliver an incoming + message, again when deliver_drop_privilege is set or Exim is run as root. + The bug described in (1) was not present in this case, but the tidying up + of the other signals was missing. I have made the two cases consistent. + + 3. The ignore_target_hosts setting on a manualroute router was being ignored + for hosts that were looked up using the /MX notation. + + 4. Added /ignore=<ip list> feature to @mx_any, @mx_primary, and @mx_secondary + in domain lists. + + 5. Change 4.31/55 was buggy, and broke when there was a rewriting rule that + operated on the sender address. After changing the $sender_address to <> + for the sender address verify, Exim was re-instated it as the original + (before rewriting) address, but remembering that it had rewritten it, so it + wasn't rewriting it again. This bug also had the effect of breaking the + sender address verification caching when the sender address was rewritten. + + 6. The ignore_target_hosts option was being ignored by the ipliteral router. + This has been changed so that if the ip literal address matches + ignore_target_hosts, the router declines. + + 7. Added expansion conditions match_domain, match_address, and match_local_ + part (NOT match_host). + + 8. The placeholder for the Received: header didn't have a length field set. + + 9. Added code to Exim itself and to exim_lock to test for a specific race + condition that could lead to file corruption when using MBX delivery. The + issue is with the lockfile that is created in /tmp. If this file is removed + after a process has opened it but before that process has acquired a lock, + there is the potential for a second process to recreate the file and also + acquire a lock. This could lead to two Exim processes writing to the file + at the same time. The added code performs the same test as UW imapd; it + checks after acquiring the lock that its file descriptor still refers to + the same named file. + +10. The buffer for building added header lines was of fixed size, 8192 bytes. + It is now parameterized by HEADER_ADD_BUFFER_SIZE and this can be adjusted + when Exim is built. + +11. Added the smtp_active_hostname option. If used, this will typically be made + to depend on the incoming interface address. Because $interface_address is + not set up until the daemon has forked a reception process, error responses + that can happen earlier (such as "too many connections") no longer contain + a host name. + +12. If an expansion in a condition on a "warn" statement fails because a lookup + defers, the "warn" statement is abandoned, and the next ACL statement is + processed. Previously this caused the whole ACL to be aborted. + +13. Added the iplsearch lookup type. + +14. Added ident_timeout as a log selector. + +15. Added tls_certificate_verified as a log selector. + +16. Added a global option tls_require_ciphers (compare the smtp transport + option of the same name). This controls incoming TLS connections. + +17. I finally figured out how to make tls_require_ciphers do a similar thing + in GNUtls to what it does in OpenSSL, that is, set up an appropriate list + before starting the TLS session. + +18. Tabs are now shown as \t in -bP output. + +19. If the log selector return_path_on_delivery was set, Exim crashed when + bouncing a message because it had too many Received: header lines. + +20. If two routers both had headers_remove settings, and the first one included + a superfluous trailing colon, the final name in the first list and the + first name in the second list were incorrectly joined into one item (with a + colon in the middle). + + +Exim version 4.32 +----------------- + + 1. Added -C and -D options to the exinext utility, mainly to make it easier + to include in the automated testing, but these could be helpful when + multiple configurations are in use. + + 2. The exinext utility was not formatting the output nicely when there was + an alternate port involved in the retry record key, nor when there was a + message id as well (for retries that were specific to a specific message + and a specific host). It was also confused by IPv6 addresses, because of + the additional colons they contain. I have fixed the IPv4 problem, and + patched it up to do a reasonable job for IPv6. + + 3. When there is an error after a MAIL, RCPT, or DATA SMTP command during + delivery, the log line now contains "pipelined" if PIPELINING was used. + + 4. An SMTP transport process used to panic and die if the bind() call to set + an explicit outgoing interface failed. This has been changed; it is now + treated in the same way as a connect() failure. + + 5. A reference to $sender_host_name in the part of a conditional expansion + that was being skipped was still causing a DNS lookup. This no longer + occurs. + + 6. The def: expansion condition was not recognizing references to header lines + that used bh_ and bheader_. + + 7. Added the _cache feature to named lists. + + 8. The code for checking quota_filecount in the appendfile transport was + allowing one more file than it should have been. + + 9. For compatibility with Sendmail, the command line option + + -prval:sval + + is equivalent to + + -oMr rval -oMs sval + + and sets the incoming protocol and host name (for trusted callers). The + host name and its colon can be omitted when only the protocol is to be set. + Note the Exim already has two private options, -pd and -ps, that refer to + embedded Perl. It is therefore impossible to set a protocol value of "d" or + "s", but I don't think that's a major issue. + +10. A number of refactoring changes to the code, none of which should affect + Exim's behaviour: + + (a) The number of logging options was getting close to filling up the + 32-bit word that was used as a bit map. I have split them into two classes: + those that are passed in the argument to log_write(), and those that are + only ever tested independently outside of that function. These are now in + separate 32-bit words, so there is plenty of room for expansion again. + There is no change in the user interface or the logging behaviour. + + (b) When building, for example, log lines, the code previously used a + macro that called string_cat() twice, in order to add two strings. This is + not really sufficiently general. Furthermore, there was one instance where + it was actually wrong because one of the argument was used twice, and in + one call a function was used. (As it happened, calling the function twice + did not affect the overall behaviour.) The macro has been replaced by a + function that can join an arbitrary number of extra strings onto a growing + string. + + (c) The code for expansion conditions now uses a table and a binary chop + instead of a serial search (which was left over from when there were very + few conditions). Also, it now recognizes conditions like "pam" even when + the relevant support is not compiled in: a suitably worded error message is + given if an attempt is made to use such a condition. + +11. Added ${time_interval:xxxxx}. + +12. A bug was causing one of the ddress fields not to be passed back correctly + from remote delivery subprocesses. The field in question was not being + subsequently used, so this caused to problems in practice. + +13. Added new log selectors queue_time and deliver_time. + +14. Might have fixed a bug in maildirsizefile handling that threw up + "unexpected character" debug warnings, and recalculated the data + unnecessarily. In any case, I expanded the warning message to give more + information. + +15. Added the message "Restricted characters in address" to the statements in + the default ACL that block characters like @ and % in local parts. + +16. Change 71 for release 4.31 proved to be much less benign that I imagined. + Three changes have been made: + + (a) There was a serious bug; a negative response to MAIL caused the whole + recipient domain to be cached as invalid, thereby blocking all messages + to all local parts at the same domain, from all senders. This bug has + been fixed. The domain is no longer cached after a negative response to + MAIL if the sender used is not empty. + + (b) The default behaviour of using MAIL FROM:<> for recipient callouts has + been restored. + + (c) A new callout option, "use_sender" has been added for people who want + the modified behaviour. + + +Exim version 4.31 +----------------- + + 1. Removed "EXTRALIBS=-lwrap" from OS/Makefile-Unixware7 on the advice of + Larry Rosenman. + + 2. Removed "LIBS = -lresolv" from OS/Makefile-Darwin as it is not needed, and + indeed breaks things for older releases. + + 3. Added additional logging to the case where there is a problem reading data + from a filter that is running in a subprocess using a pipe, in order to + try to track down a specific problem. + + 4. Testing facility fudge: when running in the test harness and attempting + to connect to 10.x.x.x (expecting a connection timeout) I'm now sometimes + getting "No route to host". Convert this to a timeout. + + 5. Define ICONV_ARG2_TYPE as "char **" for Unixware7 to avoid compiler + warning. + + 6. Some OS don't have socklen_t but use size_t instead. This affects the + fifth argument of getsockopt() amongst other things. This is now + configurable by a macro called SOCKLEN_T which defaults to socklen_t, but + can be set for individual OS. I have set it for SunOS5, OSF1, and + Unixware7. Current versions of SunOS5 (aka Solaris) do have socklen_t, but + some earlier ones do not. + + 7. Change 4.30/15 was not doing the test caselessly. + + 8. The standard form for an IPv6 address literal was being rejected by address + parsing in, for example, MAIL and RCPT commands. An example of this kind of + address is [IPv6:2002:c1ed:8229:10:202:2dff:fe07:a42a]. Exim now accepts + this, as well as the form without the "IPv6" on the front (but only when + address literals are enabled, of course). + + 9. Added some casts to avoid compiler warnings in OS/os.c-Linux. + +10. Exim crashed if a message with an empty sender address specified by -f + encountered a router with an errors_to setting. This could be provoked only + by a command such as + + exim -f "" ... + + where an empty string was supplied; "<>" did not hit this bug. + +11. Installed PCRE release 4.5. + +12. If EHLO/HELO was rejected by an ACL, the value of $sender_helo_name + remained set. It is now erased. + +13. exiqgrep wasn't working on MacOS X because it didn't correctly compute + times from message ids (which are base 36 rather than the normal 62). + +14. "Expected" SMTP protocol errors that can arise when PIPELINING is in use + were being counted as actual protocol errors, and logged if the log + selector +smtp_protocol_error was set. One cannot be perfect in this test, + but now, if PIPELINING has been advertised, RCPT following a rejected MAIL, + and DATA following a set of rejected RCPTs do not count as protocol errors. + In other words, Exim assumes they were pipelined, though this may not + actually be the case. Of course, in all cases the client gets an + appropriate error code. + +15. If a lookup fails in an ACL condition, a message about the failure may + be available; it is used if testing the ACL cannot continue, because most + such messages specify what the cause of the deferral is. However, some + messages (e.g. "MYSQL: no data found") do not cause a defer. There was bug + that caused an old message to be retained and used if a later statement + caused a defer, replacing the real cause of the deferral. + +16. If an IP address had so many PTR records that the DNS lookup buffer + was not large enough to hold them, Exim could crash while trying to process + the truncated data. It now detects and logs this case. + +17. Further to 4.21/58, another change has been made: if (and only if) the + first line of a message (the first header line) ends with CRLF, a bare LF + in a subsequent header line has a space inserted after it, so as not to + terminate the header. + +18. Refactoring: tidied an ugly bit of code in appendfile that copied data + unnecessarily, used atoi() instead of strtol(), and didn't check the + termination when getting file sizes from file names by regex. + +19. Completely re-implemented the support for maildirsize files, in the light + of a number of problems with the previous contributed implementation + (4.30/29). In particular: + + . If the quota is zero, the maildirsize file is maintained, but no quota is + imposed. + + . If the maildir directory does not exist, it is created before any attempt + to write a maildirsize file. + + . The quota value in the file is just a cache; if the quota is changed in + the transport, the new value overrides. + + . A regular expression is available for excluding directories from the + count. + +20. The autoreply transport checks the characters in options that define the + message's headers; it allows continued headers, but it was checking with + isspace() after an embedded newline instead of explicitly looking for a + space or a tab. + +21. If all the "regular" hosts to which an address was routed had passed their + expiry times, and had not reached their retry times, the address was + bounced, even if fallback hosts were defined. Now Exim should go on to try + the fallback hosts. + +22. Increased buffer sizes in the callout code from 1024 to 4096 to match the + equivalent code in the SMTP transport. Some hosts send humungous responses + to HELO/EHLO, more than 1024 it seems. + +23. Refactoring: code in filter.c used (void *) for "any old type" but this + gives compiler warnings in some environments. I've now done it "properly", + using a union. + +24. The replacement for inet_ntoa() that is used with gcc on IRIX systems + (because of problems with the built-in one) was declared to return uschar * + instead of char *, causing compiler failure. + +25. Fixed a file descriptor leak when processing alias/forward files. + +26. Fixed a minor format string issue in dbfn.c. + +27. Typo in exim.c: ("dmbnz" for "dbmnz"). + +28. If a filter file refered to $h_xxx or $message_headers, and the headers + contained RFC 2047 "words", Exim's memory could, under certain conditions, + become corrupted. + +29. When a sender address is verified, it is cached, to save repeating the test + when there is more than one recipient in a message. However, when the + verification involves a callout, it is possible for different callout + options to be set for different recipients. It is too complicated to keep + track of this in the cache, so now Exim always runs a verification when a + callout is required, relying on the callout cache for the optimization. + The overhead is duplication of the address routing, but this should not be + too great. + +30. Fixed a bug in callout caching. If a RCPT command caused the sender address + to be verified with callout=postmaster, and the main callout worked but the + postmaster check failed, the verification correctly failed. However, if a + subsequent RCPT command asked for sender verification *without* the + postmaster check, incorrect caching caused this verification also to fail, + incorrectly. + +31. Exim caches DNS lookup failures so as to avoid multiple timeouts; however, + it was not caching the DNS options (qualify_single, search_parents) that + were used when the lookup failed. A subsequent lookup with different + options therefore always gave the same answer, though there were cases + where it should not have. (Example: a "domains = !$mx_any" option on a + dnslookup router: the "domains" option is always processed without any + widening, but the router might have qualify_single set.) Now Exim uses the + cached value only when the same options are set. + +32. Added John Jetmore's "exipick" utility to the distribution. + +33. GnuTLS: When an attempt to start a TLS session fails for any reason other + than a timeout (e.g. a certificate is required, and is not provided), an + Exim server now closes the connection immediately. Previously it waited for + the client to close - but if the client is SSL, it seems that they each + wait for each other, leading to a delay before one of them times out. + +34: GnuTLS: Updated the code to use the new GnuTLS 1.0.0 API. I have not + maintained 0.8.x compatibility because I don't think many are using it, and + it is clearly obsolete. + +35. Added TLS support for CRLs: a tls_crl global option and one for the smtp + transport. + +36. OpenSSL: $tls_certificate_verified was being set to 1 even if the + client certificate was expired. A simple patch fixes this, though I don't + understand the full logic of why the verify callback is called multiple + times. + +37. OpenSSL: a patch from Robert Roselius: "Enable client-bug workaround. + Versions of OpenSSL as of 0.9.6d include a 'CBC countermeasure' feature, + which causes problems with some clients (such as the Certicom SSL Plus + library used by Eudora). This option, SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS, + disables the coutermeasure allowing Eudora to connect." + +38. Exim was not checking that a write() to a log file succeeded. This could + lead to Bad Things if a log got too big, in particular if it hit a file + size limit. Exim now panics and dies if it cannot write to a log file, just + as it does if it cannot open a log file. + +39. Modified OS/Makefile-Linux so that it now contains + + CFLAGS=-O -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE + + The two -D definitions ensure that Exim is compiled with large file + support, which makes it possible to handle log files that are bigger than + 2^31. + +40. Fixed a subtle caching bug: if (in an ACL or a set of routers, for + instance) a domain was checked against a named list that involved a lookup, + causing $domain_data to be set, then another domain was checked against the + same list, then the first domain was re-checked, the value of $domain_data + after the final check could be wrong. In particular, if the second check + failed, it could be set empty. This bug probably also applied to + $localpart_data. + +41. The strip_trailing_dot option was not being applied to the address given + with the -f command-line option. + +42. The code for reading a message's header from the spool was incrementing + $received_count, but never initializing it. This meant that the value was + incorrect (doubled) while delivering a message in the same process in which + it was received. In the most common configuration of Exim, this never + happens - a fresh exec is done - but it can happen when + deliver_drop_privilege is set. + +43. When Exim logs an SMTP synchronization error - client data sent too soon - + it now includes up to 150 characters of the unexpected data in the log + line. + +44. The exim_dbmbuild utility uses fixed size buffers for reading input lines + and building data strings. The size of both of these buffers was 10 000 + bytes - far larger than anybody would *ever* want, thought I. Needless to + say, somebody hit the limit. I have increased the maximum line length to + 20 000 and the maximum data length of concatenated lines to 100 000. I have + also fixed two bugs, because there was no checking on these buffers. Tsk, + tsk. Now exim_dbmbuild gives a message and exits with an error code if a + buffer is too small. + +45. The exim_dbmbuild utility did not support quoted keys, as Exim does in + lsearch lookups. Now it does. + +46. When parsing a route_list item in a manualroute router, a fixed-length + buffer was used for the list of hosts. I made this 1024 bytes long, + thinking that nobody would ever have a list of hosts that long. Wrong. + Somebody had a whole pile of complicated expansion conditions, and the + string was silently truncated, leading to an expansion error. It turns out + that it is easier to change to an unlimited length (owing to other changes + that have happened since this code was originally written) than to build + structure for giving a limitation error. The length of the item that + expands into the list of hosts is now unlimited. + +47. The lsearch lookup could not handle data where the length of text line was + more than 4095 characters. Such lines were truncated, leading to shortened + data being returned. It should now handle lines of any length. + +48. Minor wording revision: "cannot test xxx in yyy ACL" becomes "cannot test + xxx condition in yyy ACL" (e.g. "cannot test domains condition in DATA + ACL"). + +49. Cosmetic tidy to scripts like exicyclog that are generated by globally + replacing strings such as BIN_DIRECTORY in a source file: the replacement + no longer happens in comment lines. A list of replacements is now placed + at the head of all of the source files, except those whose only change is + to replace PERL_COMMAND in the very first #! line. + +50. Replaced the slow insertion sort in queue.c, for sorting the list of + messages on the queue, with a bottom-up merge sort, using code contributed + by Michael Haardt. This should make operations like -bp somewhat faster on + large queues. It won't affect queue runners, except when queue_run_in_order + is set. + +51. Installed eximstats 1.31 in the distribution. + +52. Added support for SRV lookups to the dnslookup router. + +53. If an ACL referred to $message_body or $message_body_end, the value was not + reset for any messages that followed in the same SMTP session. + +54. The store-handling optimization for building very long strings was not + differentiating between the different store pools. I don't think this + actually made any difference in practice, but I've tidied it. + +55. While running the routers to verify a sender address, $sender_address + was still set to the sender address. This is wrong, because when routing to + send a bounce to the sender, it would be empty. Therefore, I have changed + it so that, while verifying a sender address, $sender_address is set to <>. + (There is no change to what happens when verifying a recipient address.) + +56. After finding MX (or SRV) records, Exim was doing a DNS lookup for the + target A or AAAA records (if not already returned) without resetting the + qualify_single or search_parents options of the DNS resolver. These are + inappropriate in this case because the targets of MX and SRV records must + be FQDNs. A broken DNS record could cause trouble if it happened to have a + target that, when qualified, matched something in the local domain. These + two options are now turned off when doing these lookups. + +57. It seems that at least some releases of Reiserfs (which does not have the + concept of a fixed number of inodes) returns zero and not -1 for the + number of available inodes. This interacted badly with check_spool_inodes, + which assumed that -1 was the "no such thing" setting. What I have done is + to check that the total number of inodes is greater than zero before doing + the test of how many are available. + +58. When a "warn" ACL statement has a log_message modifier, the message is + remembered, and not repeated. This is to avoid a lot of repetition when a + message has many recipients that cause the same warning to be written. + However, Exim was preserving the list of already written lines for an + entire SMTP session, which doesn't seem right. The memory is now reset if a + new message is started. + +59. The "rewrite" debugging flag was not showing the result of rewriting in the + debugging output unless log_rewrite was also set. + +60. Avoid a compiler warning on 64-bit systems in dsearch.c by avoiding the use + of (int)(handle) when we know that handle contains (void *)(-1). + +61. The Exim daemon panic-logs an error return when it closes the incoming + connection. However "connection reset by peer" seems to be common, and + isn't really an error worthy of noting specially, so that particular error + is no long logged. + +62. When Exim is trying to find all the local interfaces, it used to panic and + die if the ioctl to get the interface flags failed. However, it seems that + on at least one OS (Solaris 9) it is possible to have an interface that is + included in the list of interfaces, but for which you get a failure error + for this call. This happens when the interface is not "plumbed" into a + protocol (i.e. neither IPv4 nor IPv6). I've changed the code so that a + failure of the "get flags" call assumes that the interface is down. + +63. Added a ${eval10: operator, which assumes all numbers are decimal. This + makes life easier for people who are doing arithmetic on fields extracted + from dates, where you often get leading zeros that should not be + interpreted as octal. + +64. Added qualify_domain to the redirect router, to override the global + setting. + +65. If a pathologically long header line contained very many addresses (the + report of this problem mentioned 10 000) and each of them was rewritten, + Exim could use up a very large amount of memory. (It kept on making new + copies of the header line as it rewrote, and never released the old ones.) + At the expense of a bit more processing, the header rewriting function has + been changed so that it no longer eats memory in this way. + +66. The generation of the Received: header has been moved from the time that a + message starts to be received, to the time that it finishes. The timestamp + in the Received: header should now be very close to that of the <= log + line. There are two side-effects of this change: + + (a) If a message is rejected by a DATA or non-SMTP ACL or local_scan(), the + logged header lines no longer include the local Received: line, because + it has not yet been created. The same applies to a copy of the message + that is returned to a non-SMTP sender when a message is rejected. + + (b) When a filter file is tested using -bf, no additional Received: header + is added to the test message. After some thought, I decided that this + is a bug fix. + + This change does not affect the value of $received_for. It is still set + after address rewriting, but before local_scan() is called. + +67. Installed the latest Cygwin-specific files from the Cygwin maintainer. + +68. GnuTLS: If an empty file is specified for tls_verify_certificates, GnuTLS + gave an unhelpful panic error message, and a defer error. I have managed to + change this behaviour so that it now rejects any supplied certificate, + which seems right, as the list of acceptable certificates is empty. + +69. OpenSSL: If an empty file is specified for tls_verify_certificates, OpenSSL + gave an unhelpful defer error. I have not managed to make this reject any + supplied certificates, but the error message it gives is "no certificate + supplied", which is not helpful. + +70. exigrep's output now also includes lines that are not associated with any + message, but which match the given pattern. Implemented by a patch from + Martin Sluka, which also tidied up the Perl a bit. + +71. Recipient callout verification, like sender verification, was using <> in + the MAIL FROM command. This isn't really the right thing, since the actual + sender may affect whether the remote host accepts the recipient or not. I + have changed it to use the actual sender in the callout; this means that + the cache record is now keyed on a recipient/sender pair, not just the + recipient address. There doesn't seem to be a real danger of callout loops, + since a callout by the remote host to check the sender would use <>. + [SEE ABOVE: changed after hitting problems.] + +72. Exim treats illegal SMTP error codes that do not begin with 4 or 5 as + temporary errors. However, in the case of such a code being given after + the end of a data transmission (i.e. after ".") Exim was failing to write + a retry record for the message. (Yes, there was some broken host that was + actually sending 8xx at this point.) + +73. An unknown lookup type in a host list could cause Exim to panic-die when + the list was checked. (An example that provoked this was putting <; in the + middle of a list instead of at the start.) If this happened during a DATA + ACL check, a -D file could be left lying around. This kind of configuration + error no longer causes Exim to die; instead it causes a defer error. The + incident is still logged to the main and panic logs. + +74. Buglet left over from Exim 3 conversion. The message "too many messages + in one connection" was written to the rejectlog but not the mainlog, except + when address rewriting (yes!) was being logged. + +75. Added write_rejectlog option. + +76. When a system filter was run not as root (that is, when system_filter_user + was set), the values of the $n variables were not being returned to the + main process; thus, they were not subsequently available in the $sn + variables. + +77. Added +return_path_on_delivery log selector. + +78. A connection timeout was being treated differently from recipients deferred + when testing hosts_max_try with a message that was older than the host's + retry timeout. (The host should not be counted, thus allowing all hosts to + be tried at least once before bouncing.) This may have been the cause of an + occasionally reported bug whereby a message would remain on the queue + longer than the retry timeout, but would be bounced if a delivery was + forced. I say "may" because I never totally pinned down the problem; + setting up timeout/retry tests is difficult. See also the next item. + +79. The ultimate address timeout was not being applied to errors that involved + a combination of host plus message (for example, a timeout on a MAIL + command). When an address resolved to a number of possible hosts, and they + were not all tried for each delivery (e.g. because of hosts_max_try), a + message could remain on the queue longer than the retry timeout. + +80. Sieve bug: "stop" inside "elsif" was broken. Applied a patch from Michael + Haardt. + +81. Fixed an obscure SMTP outgoing bug which required at least the following + conditions: (a) there was another message waiting for the same server; + (b) the server returned 5xx to all RCPT commands in the first message so + that the message was not completed; (c) the server dropped the connection + or gave a negative response to the RSET that Exim sends to abort the + transaction. The observed case was a dropped connection after DATA that had + been sent in pipelining mode. That is, the server had advertised PIPELINING + but was not implementing it correctly. The effect of the bug was incorrect + behaviour, such as trying another host, and this could lead to a crash. + + +Exim version 4.30 +----------------- + + 1. The 3rd arguments to getsockname(), getpeername(), and accept() in exim.c + and daemon.c were passed as pointers to ints; they should have been + pointers to socklen_t variables (which are typically unsigned ints). + + 2. Some signed/unsigned type warnings in the os.c file for Linux have been + fixed. + + 3. Fixed a really odd bug that affected only the testing scheme; patching a + certain fixed string in the binary changed the value of another string that + happened to be identical to the end of the original first string. + + 4. When gethostbyname() (or equivalent) is passed an IP address as a "host + name", it returns that address as the IP address. On some operating + systems (e.g. Solaris), it also passes back the IP address string as the + "host name". However, on others (e.g. Linux), it passes back an empty + string. Exim wasn't checking for this, and was changing the host name to an + empty string, assuming it had been canonicalized. + + 5. Although rare, it is permitted to have more than one PTR record for a given + IP address. I thought that gethostbyaddr() or getipnodebyaddr() always gave + all the names associated with an address, because they do in Solaris. + However, it seems that they do not in Linux for data that comes from the + DNS. If an address in /etc/hosts has multiple names, they _are_ all given. + I found this out when I moved to a new Linux workstation and tried to run + the Exim test suite. + + To get round this problem I have changed the code so that it now does its + own call to the DNS to look up PTR records when searching for a host name. + If nothing can be found in the DNS, it tries gethostbyaddr(), so that + addresses that are only in /etc/hosts are still found. + + This behaviour is, however, controlled by an option called host_lookup_ + order, which defaults to "bydns:byaddr". If people want to use the other + order, or indeed, just use one or the other means of lookup, they can + specify it in this variable. + + 6. If a PTR record yields an empty name, Exim treats it as non-existent. In + some operating systems, this comes back from gethostbyaddr() as an empty + string, and this is what Exim used to test for. However, it seems that in + other systems, "." is yielded. Exim now tests for this case too. + + 7. The values of check_spool_space and check_log_space are now held internally + as a number of kilobytes instead of an absolute number of bytes. If a + numbers is specified without 'K' or 'M', it is rounded up to the nearest + kilobyte. This means that much larger values can be stored. + + 8. Exim monitor: an attempt to get the action menu when not actually pointing + at a message produces an empty menu entitled "No message selected". This + works on Solaris (OpenWindows). However, XFree86 does not like a menu with + no entries in it ("Shell widget menu has zero width and/or height"). So I + have added a single, blank menu entry in this case. + + 9. Added ${quote_local_part. + +10. MIME decoding is now applied to the contents of Subject: header lines when + they are logged. + +11. Now that a reference to $sender_host_address automatically causes a reverse + lookup to occur if necessary (4.13/18), there is no need to arrange for a + host lookup before query-style lookups in lists that might use this + variable. This has therefore been abolished, and the "net-" prefix is no + longer necessary for query-style lookups. + +12. The Makefile for SCO_SV contained a setting of LDFLAGS. This appears to + have been a typo for LFLAGS, so it has been changed. + +13. The install script calls Exim with "-C /dev/null" in order to find the + version number. If ALT_CONFIG_PREFIX was set, this caused an error message + to be output. However, since Exim outputs its version number before the + error, it didn't break the script. It just looked ugly. I fixed this by + always allowing "-C /dev/null" if the caller is root. + +14. Ignore overlarge ACL variable number when reading spool file - insurance + against a later release with more variables having written the file. + +15. The standard form for an IPv6 address literal was being rejected by EHLO. + Example: [IPv6:2002:c1ed:8229:10:202:2dff:fe07:a42a]. Exim now accepts + this, as well as the form without the "IPv6" on the front. + +16. Added CHOWN_COMMAND=/usr/sbin/chown and LIBS=-lresolv to the + OS/Makefile-Darwin file. + +17. Fixed typo in lookups/ldap.c: D_LOOKUP should be D_lookup. This applied + only to LDAP libraries that do not have LDAP_OPT_DEREF. + +18. After change 4.21/52, "%ld" was used to format the contents of the $inode + variable. However, some OS use ints for inodes. I've added cast to long int + to get rid of the compiler warning. + +19. I had forgotten to lock out "/../" in configuration file names when + ALT_CONFIG_PREFIX was set. + +20. Routers used for verification do not need to specify transports. However, + if such a router generated a host list, and callout was configured, Exim + crashed, because it could not find a port number from the (non-existent) + transport. It now assumes port 25 in this circumstance. + +21. Added the -t option to exigrep. + +22. If LOOKUP_LSEARCH is defined, all three linear search methods (lsearch, + wildlsearch, nwildlsearch) are compiled. LOOKUP_WILDLSEARCH and LOOKUP_ + NWILDLSEARCH are now obsolete, but retained for compatibility. If either of + them is set, LOOKUP_LSEARCH is forced. + +23. "exim -bV" now outputs a list of lookups that are included in the binary. + +24. Added sender and host information to the "rejected by local_scan()" log + line; previously there was no indication of these. + +25. Added .include_if_exists. + +26. Change 3.952/11 added an explicit directory sync on top of a file sync for + Linux. It turns out that not all file systems support this. Apparently some + versions of NFS do not. (It's rare to put Exim's spool on NFS, but people + do it.) To cope with this, the error EINVAL, which means that sync-ing is + not supported on the file descriptor, is now ignored when Exim is trying to + sync a directory. This applies only to Linux. + +27. Added -DBIND_8_COMPAT to the CLFAGS setting for Darwin. + +28. In Darwin (MacOS X), the PAM headers are in /usr/include/pam and not in + /usr/include/security. There's now a flag in OS/os.h-Darwin to cope with + this. + +29. Added support for maildirsize files from supplied patch (modified a bit). + +30. The use of :fail: followed by an empty string could lead Exim to respond to + sender verification failures with (e.g.): + + 550 Verification failed for <xxx> + 550 Sender verify failed + + where the first response line was missing the '-' that indicates it is not + the final line of the response. + +31. The loop for finding the name of the user that called Exim had a hardwired + limit of 10; it now uses the value of finduser_retries, which is used for + all other user lookups. + +32. Added $received_count variable, available in data and not_smtp ACLs, and at + delivery time. + +33. Exim was neglecting to zero errno before one call of strtol() when + expanding a string and expecting an integer value. On some systems this + resulted in spurious "integer overflow" errors. Also, it was casting the + result into an int without checking. + +34. Testing for a connection timeout using "timeout_connect" in the retry rules + did not work. The code looks as if it has *never* worked, though it appears + to have been documented since at least release 1.62. I have made it work. + +35. The "timeout_DNS" error in retry rules, also documented since at least + 1.62, also never worked. As it isn't clear exactly what this means, and + clearly it isn't a major issue, I have abolished the feature by treating it + as "timeout", and writing a warning to the main and panic logs. + +36. The display of retry rules for -brt wasn't always showing the error code + correctly. + +37. Added new error conditions to retry rules: timeout_A, timeout_MX, + timeout_connect_A, timeout_connect_MX. + +38. Rewriting the envelope sender at SMTP time did not allow it to be rewritten + to the empty sender. + +39. The daemon was not analysing the content of -oX till after it had closed + stderr and disconnected from the controlling terminal. This meant that any + syntax errors were only noted on the panic log, and the return code from + the command was 0. By re-arranging the code a little, I've made the + decoding happen first, so such errors now appear on stderr, and the return + code is 1. However, the actual setting up of the sockets still happens in + the disconnected process, so errors there are still only recorded on the + panic log. + +40. A daemon listener on a wildcard IPv6 socket that also accepts IPv4 + connections (as happens on some IP stacks) was logged at start up time as + just listening for IPv6. It now logs "IPv6 with IPv4". This differentiates + it from "IPv6 and IPv4", which means that two separate sockets are being + used. + +41. The debug output for gethostbyname2() or getipnodebyname() failures now + says whether AF_INET or AF_INET6 was passed as an argument. + +42. Exiwhat output was messed up when time zones were included in log + timestamps. + +43. Exiwhat now gives more information about the daemon's listening ports, + and whether -tls-on-connect was used. + +44. The "port" option of the smtp transport is now expanded. + +45. A "message" modifier in a "warn" statement in a non-message ACL was being + silently ignored. Now an error message is written to the main and panic + logs. + +46. There's a new ACL modifier called "logwrite" which writes to a log file + as soon as it is encountered. + +47. Added $local_user_uid and $local_user_gid at routing time. + +48. Exim crashed when trying to verify a sender address that was being + rewritten to "<>". + +49. Exim was recognizing only a space character after ".include". It now also + recognizes a tab character. + +50. Fixed several bugs in the Perl script that creates the exim.8 man page by + extracting the relevant information from the specification. The man page no + longer contains scrambled data for the -d option, and I've added a section + at the front about calling Exim under different names. + +51. Added "extra_headers" argument to the "mail" command in filter files. + +52. Redirecting mail to an unqualified address in a Sieve filter caused Exim to + crash. + +53. Installed eximstats 1.29. + +54. Added transport_filter_timeout as a generic transport option. + +55. Exim no longer adds an empty Bcc: header to messages that have no To: or + Cc: header lines. This was required by RFC 822, but it not required by RFC + 2822. + +56. Exim used to add From:, Date:, and Message-Id: header lines to any + incoming messages that did not have them. Now it does so only if the + message originates locally, that is, if there is no associated remote host + address. When Resent- header lines are present, this applies to the Resent- + lines rather than the non-Resent- lines. + +57. Drop incoming SMTP connection after too many syntax or protocol errors. The + limit is controlled by smtp_max_synprot_errors, defaulting to 3. + +58. Messages for configuration errors now include the name of the main + configuration file - useful now that there may be more than one file in a + list (.included file names were always shown). + +59. Change 4.21/82 (run initgroups() when starting the daemon) causes problems + for those rare installations that do not start the daemon as root or run it + setuid root. I've cut out the call to initgroups() if the daemon is not + root at that time. + +60. The Exim user and group can now be bound into the binary as text strings + that are looked up at the start of Exim's processing. + +61. Applied a small patch for the Interbase code, supplied by Ard Biesheuvel. + +62. Added $mailstore_basename variable. + +63. Installed patch to sieve.c from Michael Haardt. + +64. When Exim failed to open the panic log after failing to open the main log, + the original message it was trying to log was written to stderr and debug + output, but if they were not available (the usual case in production), it + was lost. Now it is written to syslog before the two lines that record the + failures to open the logs. + +65. Users' Exim filters run in subprocesses under the user's uid. It is + possible for a "deliver" command or an alias in a "personal" command to + provoke an address rewrite. If logging of address rewriting is configured, + this fails because the process is not running as root or exim. There may be + a better way of dealing with this, but for the moment (because 4.30 needs + to be released), I have disabled address rewrite logging when running a + filter in a non-root, non-exim process. + + +Exim version 4.24 +----------------- + + 1. The buildconfig auxiliary program wasn't quoting the value set for + HEADERS_CHARSET. This caused a compilation error complaining that 'ISO' was + not defined. This bug was masked in 4.22 by the effect that was fixed in + change 4.23/1. + + 2. Some messages that were rejected after a message id was allocated were + shown as "incomplete" by exigrep. It no longer does this for messages that + are rejected by local_scan() or the DATA or non-SMTP ACLs. + + 3. If a Message-ID: header used a domain literal in the ID, and Exim did not + have allow_domain_literals set, the ID did not get logged in the <= line. + Domain literals are now always recognized in Message-ID: header lines. + + 4. The first argument for a ${extract expansion item is the key name or field + number. Leading and trailing spaces in this item were not being ignored, + causing some misleading effects. + + 5. When deliver_drop_privilege was set, single queue runner processes started + manually (i.e. by the command "exim -q") or by the daemon (which uses the + same command in the process it spins off) were not dropping privilege. + + 6. When the daemon running as "exim" started a queue runner, it always + re-executed Exim in the spun-off process. This is a waste of effort when + deliver_drop_privilege is set. The new process now just calls the + queue-runner function directly. + + +Exim version 4.23 +----------------- + + 1. Typo in the src/EDITME file: it referred to HEADERS_DECODE_TO instead of + HEADERS_CHARSET. + + 2. Change 4.21/73 introduced a bug. The pid file path set by -oP was being + ignored. Though the use of -oP was forcing the writing of a pid file, it + was always written to the default place. + + 3. If the message "no IP address found for host xxxx" is generated during + incoming verification, it is now followed by identification of the incoming + connection (so you can more easily find what provoked it). + + 4. Bug fix for Sieve filters: "stop" inside a block was not working properly. + + 5. Added some features to "harden" Exim a bit more against certain attacks: + + (a) There is now a build-time option called FIXED_NEVER_USERS that can + be put in Local/Makefile. This is like the never_users runtime option, + but it cannot be overridden. The default setting is "root". + + (b) If ALT_CONFIG_PREFIX is defined in Local/Makefile, it specifies a + prefix string with which any file named in a -C command line option + must start. + + (c) If ALT_CONFIG_ROOT_ONLY is defined in Local/Makefile, root privilege + is retained for -C and -D only if the caller of Exim is root. Without + it, the exim user may also use -C and -D and retain privilege. + + (d) If DISABLE_D_OPTION is defined in Local/Makefile, the use of the -D + command line option is disabled. + + 6. Macro names set by the -D option must start with an upper case letter, just + like macro names defined in the configuration file. + + 7. Added "dereference=" facility to LDAP. + + 8. Two instances of the typo "uknown" in the source files are fixed. + + 9. If a PERL_COMMAND setting in Local/Makefile was not at the start of a line, + the Configure-Makefile script screwed up while processing it. + +10. Incorporated PCRE 4.4. + +11. The SMTP synchronization check was not operating right at the start of an + SMTP session. For example, it could not catch a HELO sent before the client + waited for the greeting. There is now a check for outstanding input at the + point when the greeting is written. Because of the duplex, asynchronous + nature of TCP/IP, it cannot be perfect - the incorrect input may be on its + way, but not yet received, when the check is performed. + +12. Added tcp_nodelay to make it possible to turn of the setting of TCP_NODELAY + on TCP/IP sockets, because this apparently causes some broken clients to + timeout. + +13. Installed revised OS/Makefile-CYGWIN and OS/os.c-cygwin (the .h file was + unchanged) from the Cygwin maintainer. + +14. The code for -bV that shows what is in the binary showed "mbx" when maildir + was supported instead of testing for mbx. Effectively a typo. + +15. The spa authenticator server code was not checking that the input it + received was valid base64. + +16. The debug output line for the "set" modifier in ACLs was not showing the + name of the variable that was being set. + +17. Code tidy: the variable type "vtype_string" was never used. Removed it. + +18. Previously, a reference to $sender_host_name did not cause a DNS reverse + lookup on its own. Something else was needed to trigger the lookup. For + example, a match in host_lookup or the need for a host name in a host list. + Now, if $sender_host_name is referenced and the host name has not yet been + looked up, a lookup is performed. If the lookup fails, the variable remains + empty, and $host_lookup_failed is set to "1". + +19. Added "eqi" as a case-independent comparison operator. + +20. The saslauthd authentication condition could segfault if neither service + nor realm was specified. + +21. If an overflowing value such as "2048M" was set for message_size_limit, the + error message that was logged was misleading, and incoming SMTP + connections were dropped. The message is now more accurate, and temporary + errors are given to SMTP connections. + +22. In some error situations (such as 21 above) Exim rejects all SMTP commands + (except RSET) with a 421 error, until QUIT is received. However, it was + failing to send a response to QUIT. + +23. The HELO ACL was being run before the code for helo_try_verify_hosts, + which made it impossible to use "verify = helo" in the HELO ACL. The HELO + ACL is now run after the helo_try_verify_hosts code. + +24. "{MD5}" and "{SHA1}" are now recognized as equivalent to "{md5"} and + "{sha1}" in the "crypteq" expansion condition (in fact the comparison is + case-independent, so other case variants are also recognized). Apparently + some systems use these upper case variants. + +25. If more than two messages were waiting for the same host, and a transport + filter was specified for the transport, Exim sent two messages over the + same TCP/IP connection, and then failed with "socket operation on non- + socket" when it tried to send the third. + +26. Added Exim::debug_write and Exim::log_write for embedded Perl use. + +27. The extern definition of crypt16() in expand.c was not being excluded when + the OS had its own crypt16() function. + +28. Added bounce_return_body as a new option, and bounce_return_size_limit + as a preferred synonym for return_size_limit, both as an option and as an + expansion variable. + +29. Added LIBS=-liconv to OS/Makefile-OSF1. + +30. Changed the default configuration ACL to relax the local part checking rule + for addresses that are not in any local domains. For these addresses, + slashes and pipe symbols are allowed within local parts, but the sequence + /../ is explicitly forbidden. + +31. SPA server authentication was not clearing the challenge buffer before + using it. + +32. log_message in a "warn" ACL statement was writing to the reject log as + well as to the main log, which contradicts the documentation and doesn't + seem right (because no rejection is happening). So I have stopped it. + +33. Added Ard Biesheuvel's lookup code for accessing an Interbase database. + However, I am unable to do any testing of this. + +34. Fixed an infelicity in the appendfile transport. When checking directories + for a mailbox, to see if any needed to be created, it was accidentally + using path names with one or more superfluous leading slashes; tracing + would show up entries such as stat("///home/ph10", 0xFFBEEA48). + +35. If log_message is set on a "discard" verb in a MAIL or RCPT ACL, its + contents are added to the log line that is written for every discarded + recipient. (Previously a log_message setting was ignored.) + +36. The ${quote: operator now quotes the string if it is empty. + +37. The install script runs exim in order to find its version number. If for + some reason other than non-existence or emptiness, which it checks, it + could not run './exim', it was installing it with an empty version number, + i.e. as "exim-". This error state is now caught, and the installation is + aborted. + +38. An argument was missing from the function that creates an error message + when Exim fails to connect to the socket for saslauthd authentication. + This could cause Exim to crash, or give a corrupted message. + +39. Added isip, isip4, and isip6 to ${if conditions. + +40. The ACL variables $acl_xx are now saved with the message, and can be + accessed later in routers, transports, and filters. + +41. The new lookup type nwildlsearch is like wildlsearch, except that the key + strings in the file are not string-expanded. + +42. If a MAIL command specified a SIZE value that was too large to fit into an + int variable, the check against message_size_limit failed. Such values are + now forced to INT_MAX, which is around 2Gb for a 32-bit variable. Maybe one + day this will have to be increased, but I don't think I want to be around + when emails are that large. + + + +Exim version 4.22 +----------------- + + 1. Removed HAVE_ICONV=yes from OS/Makefile-FreeBSD, since it seems that + iconv() is not standard in FreeBSD. + + 2. Change 4.21/17 was buggy and could cause stack overwriting on a system with + IPv6 enabled. The observed symptom was a segmentation fault on return from + the function os_common_find_running_interfaces() in src/os.c. + + 3. In the check_special_case() function in daemon.c I had used "errno" as an + argument name, which causes warnings on some systems. This was basically a + typo, since it was named "eno" in the comments! + + 4. The code that waits for the clock to tick (at a resolution of some fraction + of a second) so as to ensure message-id uniqueness was always waiting for + at least one whole tick, when it could have waited for less. [This is + almost certainly not relevant at current processor speeds, where it is + unlikely to ever wait at all. But we try to future-proof.] + + 5. The function that sleeps for a time interval that includes fractions of a + second contained a race. It did not block SIGALRM between setting the + timer, and suspending (a couple of lines later). If the interval was short + and the sigsuspend() was delayed until after it had expired, the suspension + never ended. On busy systems this could lead to processes getting stuck for + ever. + + 6. Some uncommon configurations may cause a lookup to happen in a queue runner + process, before it forks any delivery processes. The open lookup caching + mechanism meant that the open file or database connection was passed into + the delivery process. The problem was that delivery processes always tidy + up cached lookup data. This could cause a problem for the next delivery + process started by the queue runner, because the external queue runner + process does not know about the closure. So the next delivery process + still has data in the lookup cache. In the case of a file lookup, there was + no problem because closing a file descriptor in a subprocess doesn't affect + the parent. However, if the lookup was caching a connection to a database, + the connection was closed, and the second delivery process was likely to + see errors such as "PGSQL: query failed: server closed the connection + unexpectedly". The problem has been fixed by closing all cached lookups + in a queue runner before running a delivery process. + + 7. Compiler warning on Linux for the second argument of iconv(), which doesn't + seem to have the "const" qualifier which it has on other OS. I've + parameterised it. + + 8. Change 4.21/2 was too strict. It is only if there are two authenticators + *of the same type* (client or server) with the same public name that an + error should be diagnosed. + + 9. When Exim looked up a host name for an IP address, but failed to find the + original IP address when looking up the host name (a safety check), it + output the message "<ip address> does not match any IP for NULL", which was + confusing, to say the least. The bug was that the host name should have + appeared instead of "NULL". + +10. Since release 3.03, if Exim is called by a uid other than root or the Exim + user that is built into the binary, and the -C or -D options is used, root + privilege is dropped before the configuration file is read. In addition, + logging is switched to stderr instead of the normal log files. If the + configuration then re-defines the Exim user, the unprivileged environment + is probably not what is expected, so Exim logs a panic warning message (but + proceeds). + + However, if deliver_drop_privilege is set, the unprivileged state may well + be exactly what is intended, so the warning has been cut out in that case, + and Exim is allowed to try to write to its normal log files. + + +Exim version 4.21 +----------------- + + 1. smtp_return_error_details was not giving details for temporary sender + or receiver verification errors. + + 2. Diagnose a configuration error if two authenticators have the same public + name. + + 3. Exim used not to create the message log file for a message until the first + delivery attempt. This could be confusing when incoming messages were held + for policy or load reasons. The message log file is now created at the time + the message is received, and an initial "Received" line is written to it. + + 4. The automatically generated man page for command line options had a minor + bug that caused no ill effects; however, a more serious problem was that + the procedure for building the man page automatically didn't always + operate. Consequently, release 4.20 contains an out-of-date version. This + shouldn't happen again. + + 5. When building Exim with embedded Perl support, the script that builds the + Makefile was calling 'perl' to find its compile-time parameters, ignoring + any setting of PERL_COMMAND in Local/Makefile. This is now fixed. + + 6. The freeze_tell option was not being used for messages that were frozen on + arrival, either by an ACL or by local_scan(). + + 7. Added the smtp_incomplete_transaction log selector. + + 8. After STARTTLS, Exim was not forgetting that it had advertised AUTH, so it + was accepting AUTH without a new EHLO. + + 9. Added tls_remember_esmtp to cope with YAEB. This allows AUTH and other + ESMTP extensions after STARTTLS without a new EHLO, in contravention of the + RFC. + +10. Logging of TCP/IP connections (when configured) now happens in the main + daemon process instead of the child process, so that the TCP/IP connection + count is more accurate (but it can never be perfect). + +11. The use of "drop" in a nested ACL was not being handled correctly in the + outer ACL. Now, if condition failure induced by the nested "drop" causes + the outer ACL verb to deny access ("accept" or "discard" after "endpass", + or "require"), the connection is dropped. + +12. Similarly, "discard" in a nested ACL wasn't being handled. A nested ACL + that yield "discard" can now be used with an "accept" or a "discard" verb, + but an error is generated for any others (because I can't see a useful way + to define what should happen). + +13. When an ACL is read dynamically from a file (or anywhere else), the lines + are now processed in the same way as lines in the Exim configuration file. + In particular, continuation lines are supported. + +14. Added the "dnslists = a.b.c!=n.n.n.n" feature. + +15. Added -ti meaning -t -i. + +16. Check for letters, digits, hyphens, and dots in the names of dnslist + domains, and warn by logging if others are found. + +17. At least on BSD, alignment is not guaranteed for the array of ifreq's + returned from GIFCONF when Exim is trying to find the list of interfaces on + a host. The code in os.c has been modified to copy each ifreq to an aligned + structure in all cases. + + Also, in some cases, the returned ifreq's were being copied to a 'struct + ifreq' on the stack, which was subsequently passed to host_ntoa(). That + means the last couple of bytes of an IPv6 address could be chopped if the + ifreq contained only a normal sockaddr (14 bytes storage). + +18. Named domain lists were not supported in the hosts_treat_as_local option. + An entry such as +xxxx was not recognized, and was treated as a literal + domain name. + +19. Ensure that header lines added by a DATA ACL are included in the reject log + if the ACL subsequently rejects the message. + +20. Upgrade the cramtest.pl utility script to use Digest::MD5 instead of just + MD5 (which is deprecated). + +21. When testing a filter file using -bf, Exim was writing a message when it + took the sender from a "From " line in the message, but it was not doing so + when it took $return_path from a Return-Path: header line. It now does. + +22. If the contents of a "message" modifier for a "warn" ACL verb do not begin + with a valid header line field name (a series of printing characters + terminated by a colon, Exim now inserts X-ACL-Warn: at the beginning. + +23. Changed "disc" in the source to "disk" to conform to the documentation and + the book and for uniformity. + +24. Ignore Sendmail's -Ooption=value command line item. + +25. When execve() failed while trying to run a command in a pipe transport, + Exim was returning EX_UNAVAILABLE (69) from the subprocess. However, this + could be confused with a return value of 69 from the command itself. This + has been changed to 127, the value the shell returns if it is asked to run + a non-existent command. The wording for the related log line suggests a + non-existent command as the problem. + +26. If received_header_text expands to an empty string, do not add a Received: + header line to the message. (Well, it adds a token one on the spool, but + marks it "old" so that it doesn't get used or transmitted.) + +27. Installed eximstats 1.28 (addition of -nt option). + +28. There was no check for failure on the call to getsockname() in the daemon + code. This can fail if there is a shortage of resources on the system, with + ENOMEM, for example. A temporary error is now given on failure. + +29. Contrary to the C standard, it seems that in some environments, the + equivalent of setlocale(LC_ALL, "C") is not obeyed at the start of a C + program. Exim now does this explicitly; it affects the formatting of + timestamps using strftime(). + +30. If exiqsumm was given junk data, it threw up some uninitialized variable + complaints. I've now initialized all the variables, to avoid this. + +32. Header lines added by a system filter were not being "seen" during + transport-time rewrites. + +33. The info_callback() function passed to OpenSSL is set up with type void + (*)(SSL *, int, int), as described somewhere. However, when calling the + function (actually a macro) that sets it up, the type void(*)() is + expected. I've put in a cast to prevent warnings from picky compilers. + +34. If a DNS black list lookup found a CNAME record, but there were no A + records associated with the domain it pointed at, Exim crashed. + +35. If a DNS black list lookup returned more than one A record, Exim ignored + all but the first. It now scans all returned addresses if a particular IP + value is being sought. In this situation, the contents of the + $dnslist_value variable are a list of all the addresses, separated by a + comma and a space. + +36. Tightened up the rules for host name lookups using reverse DNS. Exim used + to accept a host name and all its aliases if the forward lookup for any of + them yielded the IP address of the incoming connection. Now it accepts only + those names whose forward lookup yields the correct IP address. Any other + names are discarded. This closes a loophole whereby a rogue DNS + administrator could create reverse DNS records to break through a + wildcarded host restriction in an ACL. + +37. If a user filter or a system filter that ran in a subprocess used any of + the numerical variables ($1, $2 etc), or $thisaddress, in a pipe command, + the wrong values were passed to the pipe command ($thisaddress had the + value of $0, $0 had the value of $1, etc). This bug was introduced by + change 4.11/101, and not discovered because I wrote an inadequate test. :-( + +38. Improved the line breaking for long SMTP error messages from ACLs. + Previously, if there was no break point between 40 and 75 characters, Exim + left the rest of the message alone. Two changes have been made: (a) I've + reduced the minimum length to 35 characters; (b) if it can't find a break + point between 35 and 75 characters, it looks ahead and uses the first one + that it finds. This may give the occasional overlong line, but at least the + remaining text gets split now. + +39. Change 82 of 4.11 was unimaginative. It assumed the limit on the number of + file descriptors might be low, and that setting 1000 would always raise it. + It turns out that in some environments, the limit is already over 1000 and + that lowering it causes trouble. So now Exim takes care not to decrease it. + +40. When delivering a message, the value of $return_path is set to $sender_ + address at the start of routing (routers may change the value). By an + oversight, this default was not being set up when an address was tested by + -bt or -bv, which affected the outcome if any router or filter referred to + $return_path. + +41. The idea of the "warn" ACL verb is that it adds a header or writes to the + log only when "message" or "log_message" are set. However, if one of the + conditions was an address verification, or a call to a nested ACL, the + messages generated by the underlying test were being passed through. This + no longer happens. The underlying message is available in $acl_verify_ + message for both "message" and "log_message" expansions, so it can be + passed through if needed. + +42. Added RFC 2047 interpretation of header lines for $h_ expansions, with a + new expansion $bh_ to give the encoded byte string without charset + translation. Translation happens only if iconv() is available; HAVE_ICONV + indicates this at build time. HEADERS_CHARSET gives the charset to + translate to; headers_charset can change it in the configuration, and + "headers charset" can change it in an individual filter file. + +43. Now that we have a default RFC 2047 charset (see above), the code in Exim + that creates RFC 2047 encoded "words" labels them as that charset instead + of always using iso-8859-1. The cases are (i) the explicit ${rfc2047: + expansion operator; (ii) when Exim creates a From: line for a local + message; (iii) when a header line is rewritten to include a "phrase" part. + +44. Nasty bug in exiqsumm: the regex to skip already-delivered addresses was + buggy, causing it to skip the first lines of messages whose message ID + ended in 'D'. This would not have bitten before Exim release 4.14, because + message IDs were unlikely to end in 'D' before then. The effect was to have + incorrect size information for certain domains. + +45. #include "config.h" was missing at the start of the crypt16.c module. This + caused trouble on Tru64 (aka OSF1) systems, because HAVE_CRYPT16 was not + noticed. + +46. If there was a timeout during a "random" callout check, Exim treated it as + a failure of the random address, and carried on sending RSET and the real + address. If the delay was just some slowness somewhere, the response to the + original RCPT would be taken as a response to RSET and so on, causing + mayhem of various kinds. + +47. Change 50 for 4.20 was a heap of junk. I don't know what I was thinking + when I implemented it. It didn't allow for the fact that some option values + may legitimately be negative (e.g. size_addition), and it didn't even do + the right test for positive values. + +48. Domain names in DNS records are case-independent. Exim always looks them up + in lower case. Some resolvers return domain names in exactly the case they + appear in the zone file, that is, they may contain uppercase letters. Not + all resolvers do this - some return always lower case. Exim was treating a + change of case by a resolver as a change of domain, similar to a widening + of a domain abbreviation. This triggered its re-routing code and so it was + trying to route what was effectively the same domain again. This normally + caused routing to fail (because the router wouldn't handle the domain + twice). Now Exim checks for this case specially, and just changes the + casing of the domain that it ultimately uses when it transmits the message + envelope. + +49. Added Sieve (RFC 3028) support, courtesy of Michael Haardt's contributed + module. + +50. If a filter generated a file delivery with a non-absolute name (possible if + no home directory exists for the router), the forbid_file option was not + forbidding it. + +51. Added '&' feature to dnslists, to provide bit mask matching in addition to + the existing equality matching. + +52. Exim was using ints instead of ino_t variables in some places where it was + dealing with inode numbers. + +53. If TMPDIR is defined in Local/Makefile (default in src/EDITME is + TMPDIR="/tmp"), Exim checks for the presence of an environment variable + called TMPDIR, and if it finds it is different, it changes its value. + +54. The smtp_printf() function is now made available to local_scan() so + additional output lines can be written before returning. There is also an + smtp_fflush() function to enable the detection of a dropped connection. + The variables smtp_input and smtp_batched_input are exported to + local_scan(). + +55. Changed the default runtime configuration: the message "Unknown user" + has been removed from the ACL, and instead placed on the localuser router, + using the cannot_route_message feature. This means that any verification + failures that generate their own messages won't get overridden. Similarly, + the "Unrouteable address" message that was in the ACL for unverifiable + relay addresses has also been removed. + +56. Added hosts_avoid_esmtp to the smtp transport. + +57. The exicyclog script was not checking for the esoteric option + CONFIGURE_FILE_USE_EUID in the Local/Makefile. It now does this, but it + will work only if exicyclog is run under the appropriate euid. + +58. Following a discussion on the list, the rules by which Exim recognises line + endings on incoming messages have been changed. The -dropcr and drop_cr + options are now no-ops, retained only for backwards compatibility. The + following line terminators are recognized: LF CRLF CR. However, special + processing applies to CR: + + (i) The sequence CR . CR does *not* terminate an incoming SMTP message, + nor a local message in the state where . is a terminator. + + (ii) If a bare CR is encountered in a header line, an extra space is added + after the line terminator so as not to end the header. The reasoning + behind this is that bare CRs in header lines are most likely either + to be mistakes, or people trying to play silly games. + +59. The size of a message, as listed by "-bp" or in the Exim monitor window, + was being incorrectly given as 18 bytes larger than it should have been. + This is a VOB (very old bug). + +60. This may never have affected anything current, but just in case it has: + When the local host is found other than at the start of a list of hosts, + the local host, those with the same MX, and any that follow, are discarded. + When the list in question was part of a longer list of hosts, the following + hosts (not currently being processed) were also being discarded. This no + longer happens. I'm not sure if this situation could ever has previously + arisen. + +61. Added the "/MX" feature to lists of hosts in the manualroute and query + program routers. + +62. Whenever Exim generates a new message, it now adds an Auto-Submitted: + header. This is something that is recommended in a new Internet Draft, and + is something that is documented as being done by Sendmail. There are two + possible values. For messages generated by the autoreply transport, Exim + adds: + + Auto-Submitted: auto-replied + + whereas for all other generated messages (e.g. bounces) it adds + + Auto-Submitted: auto-generated + +63. The "personal" condition in filters now includes a test for the + Auto-Submitted: header. If it contains the string "auto-" the message it + not considered personal. + +64. Added rcpt_include_affixes as a generic transport option. + +65. Added queue_only_override (default true). + +66. Added the syslog_duplication option. + +67. If what should have been the first header line of a message consisted of + a space followed by a colon, Exim was mis-interpreting it as a header line. + It isn't of course - it is syntactically invalid and should therefore be + treated as the start of the message body. The misbehaviour could have + caused a number of strange effects, including loss of data in subsequent + header lines, and spool format errors. + +68. Formerly, the AUTH parameter on a MAIL command was trusted only if the + client host had authenticated. This control can now be exercised by an ACL + for more flexibility. + +69. By default, callouts do not happen when testing with -bh. There is now a + variant, -bhc, which does actually run the callout code, including + consulting and updating the callout cache. + +70. Added support for saslauthd authentication, courtesy of Alexander + Sabourenkov. + +71. If statvfs() failed on the spool or log directories while checking their + size for availability, Exim confusingly gave the error "space shortage". + Furthermore, in debugging mode it crashed with a floating point exception. + These checks are done if check_{spool,log}_{space,inodes} are set, and when + an SMTP message arrives with SIZE= on the MAIL command. As this is a really + serious problem, Exim now writes to the main and panic logs when this + happens, with details of the failure. It then refuses to accept the + incoming message, giving the message "spool directory problem" or "log + directory problem" with a 421 code for SMTP messages. + +72. When Exim is about to re-exec itself, it ensures that the file descriptors + 0, 1, and 2 exist, because some OS complain for execs without them (see + ChangeLog 4.05/30). If necessary, Exim opens /dev/null to use for these + descriptors. However, the code omitted to check that the open succeeded, + causing mysterious errors if for some reason the permissions on /dev/null + got screwed. Now Exim writes a message to the main and panic logs, and + bombs out if it can't open /dev/null. + +73. Re-vamped the way daemon_smtp_port, local_interfaces, and -oX work and + interact so that it is all more flexible. It is supposed to remain + backwards compatible. Also added extra_local_interfaces. + +74. Invalid data sent to a SPA (NTLM) server authenticator could cause the code + to bomb out with an assertion failure - to the client this appears as a + connection drop. This problem occurs in the part of the code that was taken + from the Samba project. Fortunately, the assertion is in a very simple + function, so I have fixed this by reproducing the function inline in the + one place where it is called, and arranging for authentication to fail + instead of killing the process with assert(). + +75. The SPA client code was not working when the server requested OEM rather + than Unicode encoding. + +76. Added code to make require_files with a specific uid setting more usable in + the case where statting the file as root fails - usually a non-root-mounted + NFS file system. When this happens and the failure is EACCES, Exim now + forks a subprocess and does the per-uid checking as the relevant uid. + +77. Added process_log_path. + +78. If log_file_path was not explicitly set, a setting of check_log_space or + check_log_inodes was ignored. + +79. If a space check for the spool or log partitions fails, the incident is now + logged. Of course, in the latter case the data may get lost... + +80. Added the %p formatting code to string_format() so that it can be used to + print addresses in debug_print(). Adjusted all the address printing in the + debugging in store.c to use %p rather than %d. + +81. There was a concern that a line of code in smtp_in.c could overflow a + buffer if a HELO/EHLO command was given followed by 500 or so spaces. As + initially expressed, the concern was not well-founded, because trailing + spaces are removed early. However, if the trailing spaces were followed by + a NULL, they did not get removed, so the overflow was possible. Two fixes + were applied: + + (a) I re-wrote the offending code in a cleaner fashion. + (b) If an incoming SMTP command contains a NULL character, it is rejected + as invalid. + +82. When Exim changes uid/gid to the Exim user at daemon start time, it now + runs initgroups(), so that if the Exim user is in any additional groups, + they will be used during message reception. + + +Exim version 4.20 +----------------- + +The change log for 4.20 and earlier releases has been archived. + +**** diff --git a/doc/DANE-draft-notes b/doc/DANE-draft-notes new file mode 100644 index 0000000..21b3992 --- /dev/null +++ b/doc/DANE-draft-notes @@ -0,0 +1,11 @@ + +draft 11 + +3.1.2 - Para 4 (records with Sel Full(0) are discouraged) +==> There's a matching type Full but not such a Selector type. + Should this be "Cert(0), or Matching Type Full(0)" ? + Suspect the latter. + +3.1.2 Needs a para added regarding certificate date verification, + to contrast with the requirement to NOT check for + DANE-EE defined in 3.1.1 diff --git a/doc/Exim3.upgrade b/doc/Exim3.upgrade new file mode 100644 index 0000000..4ab94c4 --- /dev/null +++ b/doc/Exim3.upgrade @@ -0,0 +1,671 @@ +This document contains information about upgrading Exim to the last of the 3.xx +releases. It is provided to help anybody who is upgrading to release 4.xx from +a release that is earlier than 3.33. It goes back as far as release 2.12. If +you are upgrading to release 4.xx from an even earlier release, it is probably +best to start again from the default configuration. + + +Upgrading from release 3.16 +--------------------------- + +1. The way LDAP returns values for multiple attributes has been changed to be +the same as the NIS+ lookup. + +If you specify multiple attributes, they are returned as space-separated +strings, quoted if necessary. + +e.g. ldap:///o=base?attr1,attr2?sub?(uid=fred) + + used to give: attr1=value one, attr2=value2 + now gives: attr1="value one" attr2=value2 + +If you don't specify any attributes in the search, you now get them in +the tagged format as well. + +e.g. ldap:///o=base??sub?(uid=fred) + + used to give: top, value one, value2 + now gives: objectClass=top attr1="value one" attr2=value2 + +The reason for these changes is so that the results can be safely parsed - +in fact, the existing ${extract{key}{val}} function does this nicely. +This in turn allows a single LDAP query to be reused - one query can return +the destination delivery address, the quota, and so forth. + +This is NOT a backwards compatible change, so there is a compile-time option +to reverse it in the src/lookups/ldap.c module, for use in emergency. But it is +not thought that the old behaviour was particularly useful as it stood, because +a field that contained ',' or '=' would make the result unparseable. + +In the common case where you explicitly ask for a single attribute in your +LDAP query, the behaviour is unchanged - the result is not quoted, and if there +are multiple values they are comma-separated. + +2. The hosts_max_try option in the smtp transport limits the number of IP +addresses that will actually be tried during one delivery attempt. The default +is 5. Previously, all available addresses were tried. + +3. The extension of the "extract" expansion item has resulted in a change to +the way Exim decides between the keyed form and the numeric form. If the first +argument consists entirely of digits, the numeric form is assumed. This means +that it is impossible to have keys that are digit strings, without manipulating +the data first (e.g. by using ${sg} to add a letter to each key). + + +Upgrading from release 3.15 +--------------------------- + +1. The handling of "freeze" and "fail" in system filter files has changed. +Previously, any deliveries set up by a filter that ended with "freeze" or +"fail" were discarded. This no longer happens; such deliveries are honoured. +A consequence of this is that first_delivery becomes false after freezing in a +system filter; previously it remained true until a real delivery attempt +happened. + + +Upgrading from release 3.13 +--------------------------- + +1. The handling of maildir_tag has been changed (see NewStuff). There are two +small incompatibilities: (a) Exim now inserts a leading colon only if the +string begins with an alphanumeric character. So if you were using a string +starting with a special character, you will have to add the leading colon to +it to remain compatible. (b) The expansion of maildir_tag now happens after the +file has been written, and $message_size is updated to the correct file size +before the expansion. The tag is not used on the temporary file (it was +previously). + +2. The handling of Exim's configuration has changed in two ways: + + (a) Any line may be continued by ending it with a backslash. Trailing white + space after the backslash, and leading white space on continuation lines is + ignored. This means that quotes are no longer needed just to make it possible + to continue an option setting. The difference between quoted and non-quoted + strings is that quoted strings are processed for internal backslashed items + such as \n. The only possible incompatibility of this change is if any + existing configuration has a non-quoted line ended in backslash, which seems + a very remote possibility. + + (b) All lists, with the exception of log_file_path, can now use a different + character to colon as the separator. This is specified by starting the list + with <x where x is any punctuation character. For example: + + local_interfaces = <; 127.0.0.1 ; ::1 + + The new feature is provided to make life easier with IPv6 addresses. It is + recommended that its use be confined to circumstances where it really is + needed, and that colon be used in most cases. I don't believe this change + is incompatible, because I don't think any list item can legitimately begin + with a '<' character. + +3. Previously, Exim took no action to ensure that the timestamps in its log +files were "wall clock time". If the TZ environment variable was set when Exim +was called, it could cause strange times to be logged. For the majority of +operating systems, I have been able to fix this problem by deleting the entire +environment. However, this doesn't work in some systems, and a macro called +HANDS_OFF_ENVIRONMENT is defined in their OS/os.h files to suppress the action. +These OS are: AIX, DGUX, HP-UX, IRIX, and SCO, and their behaviour should be +unchanged from previous releases. On any other OS, if you find you are getting +weird timestamps, it may be that your OS needs HANDS_OFF_ENVIRONMENT. + +4. As a result of the change described in 3, there may be some cases where Exim +runs an external program that previously got passed the environment, and now do +not. This does *not* apply to the pipe transport, where the environment has +always been set up specifically, as described in the manual. + +5. The way in which Exim scans its queue when split_spool_directory is set has +changed, but this shouldn't make any noticeable difference. See doc/NewStuff +for details. + + +Upgrading from release 3.03 +--------------------------- + +The from_hack option in the appendfile and pipe transports has been replace by +two string options, check_string and escape_string. If your configuration +contains any references to from_hack they should be replaced. Exim continues to +recognize from_hack as a transitional measure. If no_from_hack is specified in +an appendfile transport, the two new options are forced to be unset. Otherwise +the setting of from_hack is ignored. + + +Upgrading from release 3.02 +--------------------------- + +The exim_dbmbuild utility has been changed to write a warning to stderr on +encountering a duplicate key, and to return a value of 1. Formerly, it ignored +all but the last of a set of duplicates; now it ignores all but the first, to +make dbm-searched files behave the same way as lsearch-searched files. However, +there is an option -lastdup which makes it behave as before. The -nowarn option +suppresses the individual warnings, but the number of duplicates is always +listed on stdout at the end. + + +Updating from a release prior to 3.00 +------------------------------------- + +Prior to release 3.00 a lot of options which contained lists of various kinds +came in groups such as sender_accept, sender_reject, sender_reject_except. This +style of configuration has been abolished. Instead, it is now possible to put +negative entries in such lists, so that a single option is all that is +required. In addition to this, net lists have been abolished, and instead, +host lists can now contain items that specify networks as well as hosts. The +names of some of these options have also been changed. + +As a result of these changes, most configuration files used for earlier +versions of Exim need to be changed. The opportunity has therefore been taken +to remove a number of other obsolete features and options. + +A Perl script is built in the file util/convert4r3 to assist in updating Exim +configuration files. It reads a configuration file on the standard input, +writes a modified file on the standard output, and writes comments about what +it has done to the standard error file. It assumes that the input is a valid +Exim configuration file. A typical call to the conversion script might be + + util/convert4r3 </opt/exim/configure >/opt/exim/configure.new + +The way the script merges an accept/reject/reject_except triple into a single +accept option is to put the reject_except list first, followed by the reject +list with every item negated, followed by the accept list. For example, if an +old configuration file contains + + sender_host_accept_relay = *.c.d : e.f.g + sender_host_reject_relay = *.b.c.d + sender_host_reject_relay_except = a.b.c.d + +the new configuration will contain + + host_accept_relay = a.b.c.d : ! *.b.c.d : *.c.d : e.f.g + +The same ordering is used to merge a triple into a reject option, but this time +the first and third sublists are negated. For example, if an old configuration +file contains + + sender_host_accept = *.c.d : e.f.g + sender_host_reject = *.b.c.d + sender_host_reject_except = a.b.c.d + +the new configuration file will contain + + host_reject = ! a.b.c.d : *.b.c.d : ! *.c.d : ! e.f.g : * + +The output file should be checked before trying to use it. Each option change +is preceded by an identifying comment. There are several specific things that +you should look out for when checking: + +(1) If you are using macros to contain lists of items, and these have to be + negated in the new world, convert4r3 won't get it right. For example, if + the old configuration contains + + ACCEPTHOSTS = *.c.d : e.f.g + sender_host_reject = ACCEPTHOSTS + + then the rewritten configuration will be + + ACCEPTHOSTS = *.c.d : e.f.g + host_reject = !ACCEPTHOSTS + + but because this is just textual macro handling, that is equivalent to + + host_reject = !*.c.d : e.f.g + + which is not the correct translation, because the second item is not + negated. There is unfortunately no easy way to use a macro to provide a + list of things that are sometimes negated. + +(2) The conversion adds some settings of file_transport, pipe_transport, and + reply_transport to aliasfile and forwardfile directors. This is done + because the global implicit defaults for these options have been removed. + The default configuration now contains explicit settings, so convert4r3 + makes these additions to be compatible with that. If your aliasfile and + forwardfile directors do not make use of the pipe, file, or autoreply + facilities, you can remove these new settings. + +(3) If you are using +allow_unknown in a host list which also has an exception + list, you may need to move +allow_unknown in the new configuration. For + example, if the old configuration contains + + sender_host_reject = +allow_unknown : *.b.c + sender_host_reject_except = *.a.b.c + + then the rewritten configuration will be + + host_reject = ! *.a.b.c : +allow_unknown : *.b.c + + Because the negated item contains a wild card, the reverse lookup for the + host name will occur before +allow_unknown is encountered, and therefore + +allow_unknown will have no effect. It should be moved to the start of the + list. + +One way of upgrading Exim from a pre-3.00 release to a post-3.00 release is as +follows: + +1. Suppose your configuration file is called /opt/exim/configure, and you want + to continue with this name after upgrading. The first thing to do is to make + another copy of this file called, say, /opt/exim/configure.pre-3.00. + +2. Rebuild your existing Exim to use the copy of the configuration file instead + of the standard file. Install this version of Exim under a special name such + as exim-2.12, and point a symbolic link called "exim" at it. Then HUP your + daemon. You can check on the name of the configuration file by running + + exim -bP configure_file + + Ensure that everything is running smoothly. + +3. Build the new release, configured to use the standard configuration file. + +4. Use the convert4r3 utility to upgrade your configuration file for the new + release. After running it, check the file by hand. + +5. If any of the options that convert4r3 rewrote contained regular expressions + that had backslashes in them, and were not previously in quotes, they will + need modification if convert4r3 has put them into quotes. Either re-arrange + the option to remove the quoting, or escape each backslash. For example, if + you had + + sender_reject_recipients = ^\d{8}@ + sender_reject_except = ^\d{8}@x.y.z + + convert4r3 will have combined the two settings into + + sender_reject_recipients = "! ^\d{8}@x.y.z : \ + ^\d{8}@" + + This must be changed to + + sender_reject_recipients = ! ^\d{8}@x.y.z : ^\d{8}@ + or + sender_reject_recipients = "! ^\\d{8}@x.y.z : ^\\d{8}@" + + In the second case, the quoted string could of course still be split + over several lines. + +6. If your configuration refers to any external lists of networks, check them + to ensure that all the masks are in the single-number form, because Exim no + longer recognizes the dotted quad form of mask. For example, if an item in + a netlist file is + + 131.111.8.0/255.255.255.0 + + you must change it to + + 131.111.8.0/24 + + Otherwise Exim will not recognize it as a masked IP address, and will treat + it as a host name. The convert4r3 utility makes this conversion for networks + that are mentioned inline in the configuration, but it does not handle + referenced files. + +7. Check the newly-built Exim as much as possible without installing; you can, + for example, use a command such as + + ./exim -bV + + in the build directory to test that it successfully reads the new + configuration file. You can also do tests using -bt and -bh. + +8. Install the new release under a special name such as exim-3.00. + +9. You can then easily change between the new and old releases simply by moving + the symbolic link and HUPping your daemon. + + +Details of syntax changes at 3.00 +================================= + +1. A bare file name without a preceding search type may appear in a domain +list; this causes each line of the file to be read and processed as if it were +an item in the list, except that it cannot itself be a bare file name (that is, +this facility cannot be used recursively). Wild cards and regular expressions +may be used in the lines of the file just as in the main list. +For example, if + + local_domains = /etc/local-domains + +then the file could contain lines like + + *.mydomain.com + +This is different to an lsearch file, which operates like any other lookup type +and does an exact search for the key. If a # character appears anywhere in a +line of the file, it and all following characters are ignored. Blank lines are +also ignored. + +2. Any item in a domain list (including a bare file name) can be preceded by an +exclamation mark character, to indicate negation. White space after the ! is +ignored. If the domain matches the rest of the item, it is *not* in the set of +domains that the option is defining. If the end of the list is reached, the +domain is accepted if the last item was a negative one, but not if it was a +positive one. If ! precedes a bare file name, then all items in the file are +negated, unless they are preceded by another exclamation mark. For example: + + relay_domains = !a.b.c : *.b.c + +sets up a.b.c as an exception to the more general item *.b.c, because lists are +processed from left to right. If the domain that is being checked matches +neither a.b.c nor *.b.c, then it is not accepted as a relay domain, because the +last item in the list is a positive item. However, if the option were just + + relay_domains = !a.b.c + +then all domains other than a.b.c would be relay domains, because the last item +in the list is a negative item. In effect, a list that ends with a negative +item has ": *" appended to it. + +3. Negation and bare file names are available as above in lists of local parts +(e.g. in local_parts options) and complete addresses (address lists). For the +special "@@" lookup form in address lists, negation also can be used in the +list of local parts that is looked up for the domain. For example, with + + sender_reject_recipients = @@dbm;/etc/reject-by-domain + +the file could contain lines like this: + + baddomain.com: !postmaster : !hostmaster : * + +If a local part that actually begins with ! is required, it has to be specified +using a regular expression. Because local parts may legitimately contain # +characters, a comment in the file is recognized only if # is followed by white +space or the end of the line. + +4. Host lists may now contain network items, as in the former net list options, +which have all been abolished. The only form of network masking is the /n +variety. Negation and bare file names can appear in host lists, and there is a +new type of item which allows masked network numbers to be used as keys in +lookups, thus making it possible to used DBM files for faster checking when the +list of networks is large. + +The complete list of types of item which can now appear in a host list is: + +. An item may be a bare file name; each line of the file may take the form of + any of the items below, but it may not itself be another bare file name. If + the file name is preceded by ! then all items in the file are negated, unless + they are preceded by another exclamation mark. Comments in the file are + introduced by # and blank lines are ignored. + +. If the entire item is "*" it matches any host. + +. If the item is in the form of an IP address, it is matched against the IP + address of the incoming call. + +. If the item is in the form of an IP address followed by a slash and a mask + length (e.g. 131.111.0.0/16) then it is matched against the IP address of the + incoming call, subject to the mask. + +. If the item is of the form "net<number>-<search-type>;<search-data>", for + example: + + net24-dbm;/networks.db + + then the IP address of the incoming call is masked using <number> as the mask + length; a textual string is then constructed from the masked value, followed + by the mask, and this is then used as the key for the lookup. For example, if + the incoming IP address is 192.152.34.6 then the key that is looked up for + the above example is "192.152.34.0/24". + +. If the entire item is "@" the primary host name is used as the the match + item, and the following applies: + +. If the item is a plain domain name, then a forward DNS lookup is done on that + name to find its IP address(es), and the result is compared with the IP + address of the incoming call. + +The remaining items require the host name to be obtained by a reverse DNS +lookup. If the lookup fails, Exim takes a hard line by default and access is +not permitted. If the list is an "accept" list, Exim behaves as if the current +host is not in the set defined by the list, whereas if it is a "reject" list, +it behaves as if it is. + +To change this behaviour, the special item "+allow_unknown" may appear in the +list (at top level - it is not recognized in an indirected file); if any +subsequent items require a host name, and the reverse DNS lookup fails, Exim +permits the access, that is, its behaviour is the opposite to the default. + +. If the item starts with "*" then the remainder of the item must match the end + of the host name. For example, *.b.c matches all hosts whose names end in + .b.c. This special simple form is provided because this is a very common + requirement. Other kinds of wildcarding require the use of a regular + expression. + +. If the item starts with "^" then it is taken to be a regular expression which + is matched against the host name. For example, ^(a|b)\.c\.d$ matches either + of the two hosts a.c.d or b.c.d. If the option string in which this occurs is + given in quotes, then the backslash characters must be doubled, because they + are significant in quoted strings. The following two settings are exactly + equivalent: + + host_accept = ^(a|b)\.c\.d$ + host_accept = "^(a|b)\\.c\\.d$" + +. If the item is of the form <search-type>;<filename or query>, for example + + dbm;/host/accept/list + + then the host name is looked up using the search type and file name or query + (as appropriate). The actual data that is looked up is not used. + +5. Early versions of Exim required commas and semicolons to terminate option +settings in drivers. This hasn't been the case for quite some time. The code to +handle them has now been removed. + + +Details of option changes at 3.00 +================================= + +Main options +------------ + + * address_directory_transport, address_directory2_transport, + address_file_transport, address_pipe_transport, and address_reply_transport + have been abolished as obsolete. The aliasfile and forwardfile directors + have been able for some time to set the transports they want to use for + these special kinds of delivery; there seems little need for global + defaults. The default configuration has been altered to add settings for + file_transport and pipe_transport to the aliasfile and forwardfile + directors, and to add reply_transport to forwardfile. + + * check_dns_names, a deprecated synonym for dns_check_names, has been + abolished. + + * helo_accept_junk_nets is abolished; nets can now appear in + helo_accept_junk_hosts. + + * helo_verify_except_hosts and helo_verify_except_nets have been abolished, + and helo_verify has been changed from a boolean to a host list, listing + those hosts for which HELO verification is required. + + * the obsolete option helo_verify_nets (a synonym for host_lookup_nets) has + been abolished. Note that host_lookup_nets itself has been replaced by + host_lookup. + + * hold_domains_except has been abolished. Use negated items in hold_domains. + + * host_lookup_nets has been replaced by host_lookup, which can contain hosts + and nets. + + * ignore_fromline_nets has been replaced by ignore_fromline_hosts. + + * If message_filter is set and the filter generates any deliveries to files, + pipes, or any autoreplies, then the appropriate message_filter_*_transport + options must be set to define the transports, following the abolition of + the global defaults (see above). + + * queue_remote and queue_remote_except have been abolished and replaced by + queue_remote_domains, which lists those domains that should be queued. The + effect of queue_remote=true is now obtained by queue_remote_domains=*. + + * queue_smtp and queue_smtp_except have been abolished and replaced by + queue_smtp_domains, which lists those domains that should be queued after + routing. The effect of queue_smtp=true is now obtained by + queue_smtp_domains=*. + + * rbl_except_nets has been abolished and replaced by rbl_hosts, which can + contain hosts and nets. This defaults to "*" and defines the set of hosts + for which RBL checking is done. + + * receiver_unqualified_nets is abolished; nets can now appear in + receiver_unqualified_hosts. + + * receiver_verify_except_hosts and receiver_verify_except_nets have been + abolished and replaced by receiver_verify_hosts, which defaults to "*". + This is used, however, only when receiver_verify is set - together with the + other conditions (receiver_verify_addresses, receiver_verify_senders). + + * receiver_verify_senders_except has been abolished; the functionality is now + available by using negation in receiver_verify_senders. + + * rfc1413_except_hosts and rfc1413_except_nets have been abolished, and + replaced by rfc1413_hosts, which defaults to "*". + + * sender_accept, sender_accept_recipients and sender_reject_except have + been abolished; the functionality is now available via sender_reject and + sender_reject_recipients. + + * sender_host_accept, sender_net_accept, sender_host_reject, + sender_net_reject, sender_host_reject_except, sender_net_reject_except, + sender_host_reject_recipients and sender_net_reject_recipients + have all been abolished, and replaced by the options host_reject and + host_reject_recipients. + + * sender_host_accept_relay, sender_net_accept_relay, + sender_host_reject_relay, sender_host_reject_relay_except, + sender_net_reject_relay, and sender_net_reject_relay_except are abolished, + and replaced by host_accept_relay. This defaults unset, and this means that + all relaying is now by default locked out in the Exim binary. Previously, + if no relaying options were set, relaying was permitted. + + * sender_unqualified_nets has been abolished; nets can now appear in + sender_unqualified_hosts. + + * sender_verify_except_hosts and sender_verify_except_nets have been + abolished and replaced by sender_verify_hosts, which defaults to "*". This + is used, however, only when sender_verify is set (to make it similar to + receiver_verify, even though there aren't at present any other conditions.) + + * sender_verify_log_details has been abolished. This was a little-used + debugging option. + + * smtp_etrn_nets has been abolished; nets can now appear in smtp_etrn_hosts. + + * smtp_expn_nets has been abolished; nets can now appear in smtp_expn_hosts. + + * smtp_log_connections, a deprecated synonym for log_smtp_connections, has + been abolished. + + * smtp_reserve_nets is abolished; nets can now appear in smtp_reserve_hosts. + +Generic director and router options +----------------------------------- + + * except_domains, except_local_parts, and except_senders have been abolished. + Use negated items in domains, local_parts, and senders instead, for + example, replace + + except_domains = a.b.c + + with + + domains = !a.b.c + + If you already have a domains setting, add any negative items to the front + of it. + +The aliasfile director +---------------------- + + * The option "directory", an obsolete synonym for home_directory, has been + abolished. + +The forwardfile director +------------------------ + + * The option "directory", an obsolete synonym for file_directory, has been + abolished. + + * The option forbid_filter_log, an obsolete synonym for + forbid_filter_logwrite, has been abolished. + +The localuser director +---------------------- + + * The option "directory", an obsolete synonym for match_directory, has been + abolished. + +The lookuphost router +--------------------- + + * mx_domains_except and its obsolete old name non_mx_domains have been + abolished. Use negated items in mx_domains. + +The pipe transport +------------------ + + * The option "directory", an obsolete synonym for home_directory, has been + abolished. + +The smtp transport +------------------ + + * mx_domains_except and its obsolete old name non_mx_domains have been + abolished. Use negated items in mx_domains. + + * serialize_nets has been abolished; nets may now appear in serialize_hosts. + + +Other items relevant to upgrading from Exim 2.12 +================================================ + +1. RFC 2505 (Anti-Spam Recommendations for SMTP MTAs) recommends that the +checking of addresses for spam blocks should be done entirely caselessly. +Previously, although Exim retained the case of the local part, in accordance +with the RFC 821 rule that local parts are case sensitive, some of the string +comparisons were nevertheless done caselessly, but file lookups used the +unmodified address. + +The way addresses are compared with options whose values are address lists has +been changed. At the start of the comparison, both the local part and the +domain are now forced to lower case, and any comparisons that are done with +in-line strings are done caselessly. For example, + + sender_reject = A@b.c + +rejects both A@b.c and a@b.c. Any lookups that occur use lowercased strings as +their keys. If the @@ lookup facility is used, the lookup is done on the lower +cased domain name, but any subsequent string comparisons on local parts are +done caselessly. + +To retain possibility of caseful matching, the pseudo-item "+caseful" can +appear in an address list. It causes any subsequent items to do caseful matches +on local parts. The domain, however, remains lower cased. + +2. The handling of incoming batched SMTP has been re-worked so as to behave in +a more useful way in cases of error: + + (i) The option sender_verify_batch now defaults false. + (ii) EOF is no longer interpreted as end-of-message; the "." line must be + present. + (iii) Exim stops immediately in cases of error, writing information to stdout + and stderr, and setting the return code to 1 if some messages have been + accepted, and 2 otherwise. + +3. The first message delivered by -R, and all messages delivered by -Rf and -qf +are "forced" in the sense that retry information is over-ridden. Previously, +Exim also forcibly thawed any of these messages that was frozen. This no longer +happens. Additional options -Rff and -qff have been implemented to force +thawing as well as delivery. + +4. When recipients are being rejected because the sending host is in an RBL +list, Exim used just to show the RBL text, if any, as part of the rejection +response. Now, if prohibition_message is set, it expands that string instead, +with the RBL message available in $rbl_text, and $prohibition_reason set to +"rbl_reject". + +5. When a trusted caller passed a message to Exim, it used to check the From: +header against the caller's login (even though the caller was trusted) unless +the -f option had been used to supply a different sender. This has been changed +so that From: is never checked if the caller is trusted. + +Philip Hazel +May 1999 + diff --git a/doc/Exim4.upgrade b/doc/Exim4.upgrade new file mode 100644 index 0000000..528d94d --- /dev/null +++ b/doc/Exim4.upgrade @@ -0,0 +1,1730 @@ +Upgrading Exim from Release 3.33 to 4.xx +---------------------------------------- + +Exim 4.00 represents the largest upheaval in Exim's history. There are a lot of +changes to the way some parts of Exim work, and a lot of incompatible changes +to the run time configuration file. + +This document is in two parts. The first part contains instructions and +suggestions for how you might go about performing the upgrade. The second part +is a brief list of all the changes that have taken place. For full details of +all the new features, please consult the current version of the reference +manual. + + +HOW TO UPGRADE YOUR EXIM +------------------------ + +When you compile Exim 4, a Perl script called convert4r4 is built in the build +directory. It is not installed by the install script, because it is likely that +you will run it only once. + +This script is provided to assist in updating Exim configuration files. It +reads an Exim 3 configuration file on the standard input, and writes a modified +file on the standard output. It also writes comments about what it has done to +the standard error file. It assumes that the input is a valid Exim 3 +configuration file. A typical call to the conversion script might be + + ./convert4r4 </etc/exim/configure >/etc/exim/configure.new + +The output file MUST be checked and tested before trying to use it on a live +system. The conversion script is just an aid which does a lot of the "grunt +work". It does not guarantee to produce an Exim 4 configuration that behaves +exactly the same as the Exim 3 configuration it reads. + +Each option change in the new file is preceded by an identifying comment. In +fact, the conversion script tends to make quite a mess of your configuration, +and you should expect to go through it afterwards and tidy it up by hand. + +Unless you are running a very straightforward configuration, the automatic +conversion is likely to generate a non-optimal configuration. You should not +only check it thoroughly, but also run as many tests as you can, to ensure that +it is working as you expect. In particular, you should test address routing, +using -bt and -bv, and the policy controls, using -bh. If possible, you should +also do some live tests (i.e. send and receive some messages) before putting +Exim 4 into service. + +If you have a very complicated configuration, it is possible that convert4r4 +will break it in some situations, which is why thorough testing is strongly +recommended. + + ********************************* + ***** You Have Been Warned ****** + ********************************* + + +HOW TO MOVE FROM AN EXIM 3 RELEASE TO AN EXIM 4 RELEASE +------------------------------------------------------- + +One way of upgrading to Exim 4 from a version 3 release is as follows: + +1. Suppose your run time configuration file is called /usr/exim/configure, and + you want to continue with this name after upgrading. The first thing to do + is to make another copy of this file called, say, /usr/exim/configure.r3. + +2. Rebuild your existing Exim to use the copy of the run time configuration + file instead of the standard file. Install this version of Exim and HUP your + daemon. You can check on the name of the configuration file by running + + exim -bP configure_file + + Ensure that everything is running smoothly. You now have something you can + fall back to. IMPORTANT: when you do this re-install, you should also + re-install the utilities because four of them (exicyclog, eximon, exinext, + and exiwhat) also refer to the configuration file. + +3. Build the new release, configured to use the standard configuration file. + +4. Use the convert4r4 utility to upgrade your configuration file for the new + release. After running the conversion utility, check the file by hand, and + tidy it up. + +5. Test, test, test! And test some more! + +6. You can run complete tests, including actual deliveries, from an uninstalled + binary, but you have to tell it where it is, so that any re-executions can + be done. You can do this by temporarily inserting a setting such as + + exim_path = /source/exim/exim-4.00/build-SunOS5-5.8-sparc/exim + + into the run time configuration. If you want to, you can also insert + settings for spool_directory and log_file_path to divert those away from + their normal places. Remember to remove these temporary settings when you + eventually install the binary for real. + +7. The new installation script installs the new release as exim-4.00-1, and + set a symbolic link called "exim" to point to it. The old version of Exim + will be renamed to something like exim-3.33-1. + +8. You can now easily change between the new and old releases simply by moving + the symbolic link and HUPping your daemon. The format of message files on + Exim's spool has _not_ changed, so there should be no problem in changing + between releases while there are messages on the queue. + +9. HOWEVER: If you do change back and forth between releases, you must also + change the utilities exicyclog, eximon, exinext, and exiwhat if you are + going to use them. Installing Exim 4 will have left the old versions with a + .O suffix. It might be helpful to rename these so that you don't lose them. + + +WHAT HAS NOT CHANGED IN EXIM 4.00 +--------------------------------- + +The basic overall philosophy, design, and process structure has not changed. +The format of spool files is the same. The transports have had only minor +modifications. The command line options remain the same, with a couple of +additions. + +The general run time configuration approach has not changed, but the actual +details of the configuration file are different. + +The Exim monitor has not changed, and there have been only very minor changes +to other Exim utilities. + + +WHAT HAS CHANGED IN EXIM 4.00 +----------------------------- + +The rest of this document lists the very many changes that have taken place. +I'm going to give only brief details here, because this part of the document is +intended as a way of alerting you to areas of difference. The reference manual +describes how the new features work in detail. + + +Named domain, host, address, and local part lists +------------------------------------------------- + +A new feature makes it possible to give names to lists of domains, hosts, +addresses, and local parts. The syntax used is + + domainlist <name> = <a domain list> + hostlist <name> = <a host list> + addresslist <name> = <an address list> + localpartlist <name> = <a list of local parts> + +For example: + + domainlist local_domains = *.my.domain + addresslist bad_senders = cdb;/etc/badsenders + +These lists are referenced in options by giving the name preceded by a + sign. +For example, in a router you might have + + domains = +local_domains + +At first sight, these lists might seem to be the same as macros, but they are +not. Macros are just textual substitutions. If you write + + ALIST = host1 : host2 + auth_advertise_hosts = !ALIST + +it probably won't do what you want, because that is exactly the same as + + auth_advertise_hosts = !host1 : host2 + +Notice that the second host name is not negated. However, if you use a host +list, and write + + hostlist alist = host1 : host2 + auth_advertise_hosts = ! +alist + +the negation applies to the whole list, and so that is equivalent to + + auth_advertise_hosts = !host1 : !host2 + +These named lists also have a performance advantage. When Exim is routing an +address or checking an incoming message, it caches the result of tests on the +lists. So, if you have a setting such as + + domains = +local_domains + +on several of your routers, the actual test is done only for the first one. +However, this caching works only if there are no expansions within the list +itself or any sublists that it references. In other words, caching happens only +if the list is known to be the same each time it is referenced. + +By default, there may be up to 16 named lists of each type. This limit can be +extended by changing a compile-time variable. + +The use of domain and host lists is recommended for concepts such as local +domains, relay domains, and relay hosts. The default configuration is set up +like this. + + +Processing of domain, host, local part, and address lists +--------------------------------------------------------- + +The handling of these lists is now more uniform. Every list is expanded as a +single string before it is used. (In Exim 3, some options were expanded and +some weren't, and query-style lookup items were then re-expanded.) + +If an expansion is forced to fail, Exim behaves as if the item has not been +found in the list. + +The confusing $key variable has been abolished. When processing a domain list, +$domain contains the relevant domain and can be used in generating database +queries. Other appropriate variables are set when processing other kinds of +list; $sender_host and $sender_host_address for checking incoming hosts and +$host and $host_address for checking outgoing hosts. + +Note that this means that any \ and $ characters in regular expressions must be +escaped if they appear in one of these lists. The new expansion feature to turn +off expansion (\N ... \N) which is described below can be helpful here. + +IMPORTANT: The details of the processing of address lists has been revised. In +particular, the handling of the case of an item that is a single-key lookup has +changed. It no longer looks up the domain on its own before looking up the +complete address. You need to supply an explicit "*@" before the lookup if you +want just the domain to be looked up. Please check the manual for full details. + +If an item in a host list is the empty string, it matches only when no host is +defined. If used when checking an incoming message, it matches only when the +message is arriving by SMTP on the standard input from a local process (using +-bs). This provides a way of distinguishing between SMTP mail from local +processes and from remote hosts. + +The +allow_unknown and +warn_unknown settings for host lists have been replaced +by a single item, +include_unknown. By default, failure to find a host name +when needed causes Exim to behave as if the host does not match the list, but +if +include_unknown is set, the opposite behaviour happens. Whenever ++include_unknown is invoked, the incident is logged. + + +Merge of Directors and Routers +------------------------------ + +There are no longer any directors in Exim 4. There are just routers. All +addresses are passed to a single list of routers which typically makes use of +the "domains" option to choose which way to handle specific groups of domains. + +A consequence of this is that the code no longer contains any concept of "local +domains". However, a typical configuration will probably define a named domain +list (see above) called local_domains, and use it to control routing something +like this: + + route_remote: + driver = dnslookup + domains = ! +local_domains + transport = remote_smtp + no_more + + system_aliases: + .... + +The first router does DNS routing for all domains that are not in the named +list of local domains, and no_more ensures that it is the last router for those +domains. All other domains fall through to the system_aliases and subsequent +routers. For a complete configuration example, look at the default +configuration file in src/configure.default. + + +Router Actions +-------------- + +The concept of how the routers work is as follows: + +A number of pre-conditions are tested (details below). If any of them fails, +control is passed to the next router. We say "the router is skipped". Otherwise +the router is run, and can yield one of several different results: + +. accept: The router accepts the address, and either queues it for a transport, +or generates one or more "child" addresses. Processing the original address +ceases, unless "unseen" is set on the router, in which case the address is +passed to the next router. Processing of any child addresses starts with the +first router by default, or at the router defined by redirect_router if it is +set. This may be any router in the list. + +. decline: The router declines to accept the address because it does not +recognize it at all. The address is passed to the next router, unless no_more +is set, in which case the address fails. + +. pass: The router recognizes the address, but cannot handle it itself. It +requests that the address be passed to another router. This overrides no_more. +By default the address is passed to the next router, but this can be changed by +setting pass_router. However, in this case (unlike redirect_router) the named +router must be below the current router (to avoid loops). + +. fail: The router determines that the address should fail, and queues it for +the generation of a bounce message. There is no further processing of the +original address, unless "unseen" is set. + +. defer: The router cannot handle the address at the present time. (For +example, a database may be offline.) No further processing of the address +happens in this delivery attempt. It is tried again next time. + +. error: There is some error in the router (for example, a syntax error in +its configuration). The action is as for defer. + + +Router pre-conditions +--------------------- + +In Exim 3 there are some strange interactions between the generic options that +test things before running a director or router and the no_more test that +happens afterwards. + +In Exim 4 it is all more straightforward. If any of the pre-condition tests +fail, the router is skipped and control passes to the next router. The no_more +option has an effect only if the router is actually run - that is, if all the +pre-condition tests succeed. The order in which these tests are run is: + + verify status, expn status, domains, local_parts, check_local_user + +If all those match, the debug_print string is output when debugging. Exim then +goes on to test + + senders, require_files, condition + +Note that require_files comes near the end of the list, so you cannot use it to +check for the existence of a file in which to lookup up a domain, local part, +or sender. However, as these options are all expanded, you can use the "exists" +expansion condition to make such tests. The require_files option is intended +for checking files that the router may be going to use internally, or which are +needed by a specific transport (e.g. .procmailrc). + +In Exim 4, local part prefixes and suffixes are recognized and removed before +any of the other pre-condition tests are done (in Exim 3 they were removed +afterwards). Note that this means that the local_parts option now tests the +local part without its prefix or suffix. + +If you want to use local parts that include any affixes in a pre-condition +test, you can do so by using a "condition" option that uses the variables +$local_part, $local_part_prefix, and $local_part_suffix as necessary. + + +A New Set of Routers +-------------------- + +The two sets of routers and directors of Exim 3 have been replaced by a single +set of routers for Exim 4. These are as follows: + +. accept Always accepts an address. It has no private options. + +. dnslookup Routes by DNS lookup (descended from lookuphost). + +. ipliteral Routes IP literal addresses (unchanged). + +. iplookup Special-purpose lookup router (unchanged). + +. manualroute Routes domains from explicit data (descended from domainlist). + +. queryprogram Routes addresses by running a program (detail changed). + +. redirect Redirects addresses; handles all the functions previously + supported by aliasfile, forwardfile, and smartuser without + a transport. + + +Saving duplication of effort while routing +------------------------------------------ + +Early versions of Exim used to copy the routing of one address for all other +addresses in the same domain, thereby possibly saving some repeated DNS +lookups. This feature was removed for release 2.12, after the possibility of +varying the router actions according to the local part (the local_parts option) +was added. (In fact, the use of $local_part could have broken it earlier.) + +For Exim 4, I have added an option called same_domain_copy_routing to the +dnslookup and manualroute routers. When one of these routers routes an address +to a remote transport and this option is set, any other addresses in the +message that have the same domain are automatically given the same routing, but +only if the router does not set headers_add or headers_remove, and does not +`widen' the domain during the routing. + + +Generic Router Options +---------------------- + +. The global locally_caseless option is replaced by a generic router option + called caseful_local_part. By default, routers handle local parts caselessly. + +. check_local_user is now a generic option that is needed to check for a local + account. Typically used on redirect (for user's forward files) and on accept + (for local deliveries). + +. The setting self=local has been removed (since there's no concept of local + domains in the code). The same kind of effect can be achieved by using + self=reroute or self=pass. + +. expn is now a generic router option. + +. local_part_prefix and local_part_suffix are now generic router options, + replacing prefix and suffix on directors. + +. Exim 3 has two logging styles for delivery, depending on whether the domain + is a local domain or not. For local domains, the address is given just as the + local part - this makes these deliveries easier to spot in the log. In Exim 4 + there's no concept of local domains, so this functionality cannot be + automatic. Instead, there's a generic router option called log_as_local which + requests "local-style" logging. This option defaults on for the "accept" + router, and off for all the others. + +. There's an option called retry_use_local_part which is the default for any + router that has check_local_user set, and it applies to routing delays. (The + same option for transports applies to transport delays.) + +. transport_home_directory and transport_current_directory are new generic + options on all routers. They set up default values for home_directory and + current_directory on the transport to which they route an address. Any + settings in the transport override. + +. If transport_home_directory is not set, but check_local_user is set, the + user's home directory is used as a default value. + +. The special fudge that exists in Exim 3 for handling home_directory settings + in forwardfile directors is not needed in Exim 4. It has therefore been + removed. + +. The new_director option in Exim 3 allows the direction of redirected + addresses to start at a given director, instead of the first one. In Exim 4, + this option is now called redirect_router. The option is used when a redirect + router succeeds, and when a queryprogram router returns a "redirect" + response. + +. There is a new option called pass_router, which specifies the router to go to + when a router "passes" on an address. The named router must follow the + current router (to avoid routing loops). Note: if a router declines, control + always passes to the next router, unless no_more is set. + +. There is a new router option called address_data. This is set to a string + which is expanded just before the router is run, that is, after all the + pre-tests have succeeded. If the expansion is forced to fail, the router + declines. Other expansion failures cause delivery of the address to be + deferred. + + When the expansion succeeds, the value is retained with the address, and can + be accessed using the variable $address_data. Even if the router declines or + passes, the value remains with the address, though it can be changed by + another address_data setting on a subsequent router. If a router generates + child addresses, the value of $address_data propagates to them. + + The idea of address_data is that you can use it to look up a lot of data for + the address once, then then pick out parts of the data later. For example, + you could use an LDAP lookup to return a string of the form + + uid=1234 gid=5678 mailbox=/mail/xyz forward=/home/xyz/.forward + + In the transport you could then pick out the mailbox by a setting such as + + file = ${extract{mailbox}{$address_data}} + + This makes the configuration file less messy, and also reduces the number of + lookups. (Exim does cache the most recent lookup, but there may be several + addresses with different lookups.) + +. When a transport is run for several addresses simultaneously, the values of + $address_data, $local_part_data, and $domain_data are taken from the first + address that the transport handles. However, the order in which multiple + addresses are processed is not defined. You therefore need to be careful if + you want to use these variables with multiple addresses. The smtp transport + is the only one which by default handles multiple addresses. + +. When an address is routed by a router with the "unseen" option set, a "clone" + address is created, and it starts being routed at the next router. (This is + what people expect. In Exim 3 it starts at the top - in simple cases that has + the same effect because of the anti-looping rule, but if aliases are involved + it sometimes doesn't do what you want.) + +. The way that require_files works has been changed. Each item in the list is + now separately expanded as the test proceeds. The use of leading ! and + + characters is unchanged. However, user and group checking is done differently. + Previously, seteuid() was used, but seteuid() is no longer used in Exim (see + "Security" below). Instead, Exim now scans along the components of the file + path and checks the access for the given uid and gid. It expects "x" access + on directories and "r" on the final file. This means that file access control + lists (on those operating systems that have them) are ignored. + + +Other Consequences of the Director/Router Merge +----------------------------------------------- + +. The -odqr option is abolished, as there is no inbuilt concept of remote + domains. + +. The -odqs option is equivalent to queue_smtp_domains = *. + +. queue_remote_domains is renamed queue_domains, and applies to any domain. + +. The -ql option now suppresses remote delivery; routing always happens. + +. The "remote" facility of queue_only_file has been removed. + +. The match_directory option for forwardfile and localuser has been entirely + abolished. Its function can be achieved using the "condition" option in + conjunction with check_local_user. + +. When an address is being verified, if it is redirected to a single new + address, verification continues with that address. If it is redirected to + more than one address, verification ceases with a success result. (In Exim 3, + this applied only to aliasing, not to forwarding.) + + +The dnslookup router +-------------------- + +This router replaces the lookuphost router of Exim 3. It is much the same, +except that the "gethostbyname" option has been removed. It now does only DNS +routing - hence the change of name. Routing using gethostbyname() can be done +by the manualroute router. + + +The manualroute router +---------------------- + +This is the new name for the domainlist router, supposedly to make its function +clearer and to avoid confusion with the "domainlist" that is used to set up +named domain lists. Several things have been removed and reorganized. + +. The old search mechanism (route_file, route_query, route_queries, + search_type) have been removed. Instead there is a new option called + route_data, which is an expanded string. It should expand to a single routing + entry. If the expansion ends up empty (or is forced to fail), the router + declines. The route_list option still exists, for convenient listing of a few + inline routes. + +. There is no longer any MX processing function in this router. The keywords + bydns_mx and bydns_a have been removed, leaving just + + bydns => find IP addresses from address records in the DNS + byname => find IP addresses by calling gethostbyname() + + The default lookup type is "byname", and this can be omitted from a route + data line. If an IP address is given, both "byname" and "bydns" are ignored + (so typically you omit this field). + +. The qualify_single and search_parents options have also been removed. + +. A transport is always required to be set, unless verify_only is set. + +. The host_find_failed option can be set to "decline", to cause the router to + decline if it can't find an IP address for a listed host. + +. If manualroute routes to a local transport, there is no need to specify + byname or bydns in the routing data. Any supplied host list is passed as a + string in $host, but $host_address is unset. + + +The queryprogram router +----------------------- + +This router has been re-designed: + +. You must now specify a user and group for the program to be run using + command_user and (if necessary) command_group. It no longer defaults to + "nobody". These options are expanded. + +. The command is now split up and each argument expanded separately, as happens + for the pipe transport. The command name is also expanded. + +. The return value "forcefail" has been renamed "fail", and it causes delivery + to fail. (The original usage of "fail" meaning "decline" has finally been + removed.) + +. The $route_option variable, which queryprogram used to be able to set has + been abolished. A facility to set the new $address_data variable replaces it. + +. The string returned from queryprogram must now be one of: + + DECLINE + FAIL text + DEFER text + PASS + FREEZE text + REDIRECT text + ACCEPT TRANSPORT=transport HOSTS=host list LOOKUP=byname|bydns DATA=text + +The text returned for "redirect" is a list of new addresses. The text for FAIL +is returned in the SMTP dialogue when the router is run as part of address +verification. It is also logged. The text for DEFER and FREEZE is just logged. + +The data items in the "accept" return can be given in any order, and all are +optional. If no transport is included in the "accept" return, the router's +default transport is used. The host list and lookup type are needed only if the +transport is an smtp transport that does not itself have a host list. The +default lookup type is "byname". If the "data" field is set, its value is +placed in the $address_data variable. + + +The redirect router +------------------- + +This router replaces forwardfile, appendfile, and the use of smartuser without +a transport. It has two mutually exclusive options for specifying the data that +it uses. If "file" is set, the data is taken from a file. Otherwise "data" must +be set, and the data is the expanded value of that option. + +The data may be an alias list, possibly including special entries such as +:fail:, or it may be a list of filtering instructions. + +If "file" is set, but the file does not exist or is empty, or its contents have +no effect (entirely comments, or a filter that does nothing), the router +declines. This also happens if the expansion of "file" is forced to fail. Any +other expansion failure causes the router to defer. + +Ownership of the file is checked if check_local_user is set or if owners is +set, unless check_owner is explicitly set false. + +Likewise, the group is checked if owngroups is set, or if check_local_user is +set and a modemask not containing 020 is set, unless check_group is explicitly +set false. + +If "data" is set, a forced expansion causes the router to decline. This also +happens if "data" is an empty string or a string that causes nothing to be +generated and no action to be taken. + +Because "data" is now used for traditional /etc/aliases lookups, an empty alias +no longer gives an error. It behaves in the same way as :unknown: (which is +still recognized, but ignored). + +. If no_repeat_use is set, the router is skipped if _any_ ancestor of the + current address was routed by this router. This pre-test happens before any + of the others. (Contrast the default loop avoidance logic, which skips a + router if an ancestor with the same local part was routed by the router.) + +. If include_directory is set, :include: files are constrained to this + directory. + +. When an address is redirected to a file or a pipe, $address_file or + $address_pipe (as appropriate) is set when expanding the value of + file_transport or directory_transport. + +. There are new options forbid_filter_readfile and forbid_filter_run to lock + out the use of the new ${readfile and ${run expansion items in filters. + +. If one_time is set, forbid_pipe, forbid_file, and forbid_filter_reply are + forced to be true, and headers_add and headers_remove are forbidden. + + +Generic transport options +------------------------- + +. All remote deliveries are now done in subprocesses running with specified + UIDs and GIDs. (Formerly, only remote parallel deliveries were done in + subprocesses.) As a result, user and group are now generic options that can + be used on all transports. The default for both local and remote transports + is to run as the Exim user and group. For remote transports, this should not + normally be changed, but if it is, the user or group should be able to access + the hints databases, though failure to open a hints database is always + ignored. + + If it turns out that a transport user is in the never_users list, Exim now + defers delivery and writes to the panic log. (Previously it just ran the + delivery as "nobody".) Because subprocesses (usually running as "exim") + are now always used for remote deliveries, you should *not* include "exim" in + the never_users list. + +. initgroups is now also a generic transport option. + +. home_directory and current_directory are generic options on all transports, + though some transports (e.g. smtp) make no use of them. If they are unset, + values supplied by the router are used. + +. The message_size_limit option is now expanded, which makes it possible to + have different limits for different hosts, for example. + + +Multiple (batch) deliveries in the appendfile, lmtp, and pipe transports +------------------------------------------------------------------------ + +The options controlling batch deliveries, including BSMTP, were a mess, and +have been reworked. + +. The batch option has been removed from all three transports, and the bsmtp + and bsmtp_helo options have been removed from appendfile and pipe. + +. The batch_max option defaults to 1 in all three transports. + +. A new option called use_bsmtp has been added to appendfile and pipe. When + set, the message is delivered in BSMTP format. If you want to have a HELO + line at the start of the message, you can configure this by making use of the + message_prefix option. You must include the terminating newline. + +. A new option called batch_id has been added to all three transports. + +Batching is now achieved by setting batch_max to a value greater than 1. This +is recommended for lmtp. When multiple addresses are routed to the same +transport that has a batch_max value greater than one, the addresses are +delivered in a batch, subject to certain conditions: + +. If any of the transport's options contain a reference to "$local_part", no + batching is possible. + +. If any of the transport's options contain a reference to "$domain", only + addresses with the same domain are batched. + +. If batch_id is set, it is expanded for each address, and only those addresses + with the same expanded value are batched. + +. Batched addresses must also have the same errors address (where to send + delivery errors), the same header additions and removals, the same user and + group for the transport, and if a host list is present, the first host must + be the same. + + +The appendfile transport +------------------------ + +. The prefix and suffix options have been renamed message_prefix and + message_suffix to avoid confusion with address affixes. The default values, + which are suitable for mbox deliveries, now apply only if "file" is set and + use_bsmtp is not set. Otherwise, the default values for these options are + unset. They can, of course, always be overridden. + +. If "directory" is set (which means that "file" is not set), the check_string + and escape_string options now default unset. + +. The require_lockfile options has been abolished. If use_lockfile is set, a + lock file is always required. + +. The quota_filecount option is now expanded. + +. The create_file option now also applies when delivering into an individual + file in a given directory, as well as when appending to a single file. In the + case of maildir delivery, the restriction applies to the top directory of the + maildir folder. + +. There's a new option called directory_file which is expanded to form the + final leaf name of files when "directory" is set, but neither maildir nor + mailstore is set. The default is "q${base62:$tod_epoch}-$inode", which + reproduces the old fixed value. The variable $inode is available only when + expanding this new option. + + +The pipe transport +------------------ + +. The prefix and suffix options have been renamed message_prefix and + message_suffix to avoid confusion with address affixes. The default values + that are suitable for vacation deliveries now apply only if use_bsmtp is not + set. Otherwise the default values for these options are unset. They can, of + course, always be overridden. + + +The smtp transport +------------------ + +. The badly-named batch_max option is now called connection_max_messages. + +. If hosts_randomize is set, it now affects host lists that come from a router + as well as the contents of the "hosts" option, but only if the hosts were not + obtained from MX records. Typically, such lists come from the manualroute + router. This change means that the router can provide the same host list for + multiple addresses - causing them all to be sent to the transport at once. + Randomizing is then done each time the transport is called. (If you set + hosts_randomize on the router, the randomizing happens for each address.) + +. The way that smtp operates when there are multiple addresses to be sent to + the same host is now different. Previously, the transport was called many + times, with a maximum of max_rcpt addresses per call. Each call made a new + connection to the host. When remote_max_parallel = 1, all the addresses are + now passed to the transport at once. It makes a single TCP/IP call, but may + send multiple copies of the message, each with no more than max_rcpt + recipients. + + When remote_max_parallel is greater than 1, a heuristic is used. The number + of addresses passed to a single call of the transport is limited to + + (the total number of recipients) / (the value of remote_max_parallel) + + so, for example, if there are 100 recipients and remote_max_parallel is 2, no + more than 50 are passed in one call, even if max_rcpt is 100. (The idea is + that the other 50 will be passed to another call running in parallel.) + + There is an option of the smtp transport called connection_max_messages + which limits the number of messages, or copies of a message, that Exim sends + down a single TCP/IP connection. This applies both to this mechanism for + multiple copies of a single message, and the re-use of a TCP/IP connection + for sending other messages destined for the same host, after a delivery + delay. The default value is 500. + +. The "interface" option is now expanded. If the result is a forced failure or + an empty string, it is ignored. Otherwise, the result must be a list of IP + addresses. The first one of the correct type (IPv4 or IPv6) for the outgoing + connection is used. If there isn't one of the correct type, the option is + ignored. + +. At the start of running the transport, the value of $host is taken from the + first host in a multi-host list. However, just before the transport connects + to a host, the value is changed to refer to that particular host. (This + applies to $host_address as well.) This means that options such as helo_data + and the tls_options can be made host-specific. + +. The tls_verify_ciphers option has been renamed tls_require_ciphers, in order + to leave the word "verify" as something that refers to the verification of + certificates. + +. The resolution of hosts and fallback_hosts used to look up MX records. This + was some kind of ancient silliness that I recently noticed. These are + definitely hosts, not mail domains. Exim 4 just looks up address records. + As a consequence of this, the mx_domains option of the smtp transport is + removed. + +. The authenticate_hosts option has been renamed as hosts_try_auth. A new + option called hosts_require_auth has been added; if authentication fails for + one of these hosts, Exim does _not_ try to send unauthenticated. It defers + instead. The deferral error is detectable in the retry rules, so this can be + turned into a hard failure if required. + + +The System Filter +----------------- + +. The system filter options that were called message_filter_xxx have all been + renamed as system_filter_xxx. + +. The value of system_filter is expanded. + +. message_filter_directory_transport and message_filter_file_transport are now + both expanded before use. If the filter set up any file or pipe deliveries, + $address_file and $address_pipe are set as appropriate while doing the + expansions. + +. message_filter_directory2_transport has been removed. The effect of using + different directory-style transports can be achieved by specifying a suitable + expansion string to system_filter_directory_transport. + +. When a system filter added recipients to a message, Exim 3 added an + X-Envelope-To: header, listing the real recipients (up to 100). This has been + abolished because you can do this kind of thing using "headers_add" nowadays. + +. The "fail" command has been extended to allow for two different messages, one + for Exim's log and the other to be returned to the sender. The syntax is + + fail "<<log message>>user message" + + That is, if the first two characters of the message are "<<" the following + text, up to ">>", is written to the log, and the remainder is returned to the + user. If there is no log message, the user message is logged. The motivation + for this feature was to reduce the amount of text logged, while being able to + send quite long (maybe even multi-line) messages back to the sender. + + +Changes to Lookups +------------------ + +. Oracle support is available. It works like the mysql and pgsql support, + except that there is no "database name" involved, and the "host name" field + is used for what is called "service name" in Oracle. This often looks like a + host name. Also, semicolons are not used at the end of an SQL query for + Oracle. + +. There's a new single-key lookup type called dsearch. It searches a directory + for a file whose name matches the key. The result of a successful search is + the key. One possible use of this could be for recognizing virtual domains. + If each domain is represented by a file whose name is the domain name, you + needn't make a separate list of the domains. You could test for them in an + ACL (see below), for example, by a line like this + + accept domains = dsearch;/etc/virtual/domains + +. The format of LDAP output has been changed for cases where multiple + attributes are requested. The data for each attribute is now always quoted. + Within the quotes, the quote character, backslash, and newline are escaped + with backslashes and commas are used to separate multiple values for the + attribute. Thus, the string in quotes takes the same form as the output when + a single attribute is requested. If multiple entries are found, their data is + still separated by a newline. + +. There's a new expansion condition called ldapauth which exists so that the + LDAP authentication mechanism can be used for user authentication. It is + described under "string expansion" below. + +. Exim now supports ldaps:// URLs as well as ldap:// URLs. The former do LDAP + over TLS (i.e. encrypted) connections. + +. There is now support for the "whoson" mechanism for doing "POP-before-SMTP" + authentication. This is provided by new query-style lookup type called + "whoson", with queries that consist of IP addresses. For example, in an ACL + you can write + + require condition = ${lookup whoson {$sender_host_address}{yes}{no}} + + +Special items in domain and host lists +-------------------------------------- + +. In a domain list, the special item @ matches the primary host name, and the + special item @[] matches any local interface address enclosed in square + brackets (as in domain literal email addresses). The special item @mx_any + matches any domain that has an MX record pointing to the local host. The + special items @mx_primary and @mx_secondary are similar, except that the + first matches only when the primary MX is to the local host, and the second + only when the primary MX is not the local host, but a secondary MX is. + +. In a host list, the special item @ matches the primary host name, and the + special item @[] matches any local interface address (not in brackets). + + +Access Control Lists (ACLs) +--------------------------- + +All the policy control options for incoming messages have been replaced by +Access Control Lists (ACLs). These give more flexibility to the sysadmin, and +allow the order of testing to be specified. For example, using an ACL, it is +possible to specify "accept if authenticated, even if from an RBL host, but +otherwise deny if from an RBL host", which is not possible in Exim 3. + +ACLs are defined in a new part of the configuration file, and given names. +Which ones to run are controlled by a new set of options that are placed in the +main part of the configuration. + + acl_smtp_auth specifies the ACL to run when AUTH is received + acl_smtp_data specifies the ACL to run after a message has been received + acl_smtp_etrn specifies the ACL to run when ETRN is received + acl_smtp_expn specifies the ACL to run when EXPN is received + acl_smtp_rcpt specifies the ACL to run when RCPT is received + acl_smtp_vrfy specifies the ACL to run when VRFY is received + +The default actions vary. If acl_smtp_auth is not defined, AUTH is always +accepted (and an attempt is made to authenticate the session). If acl_smtp_data +is not defined, no checks are done after a message has been received, and it is +always accepted at that point. + +However, if any of the others are not defined, the relevant SMTP command is +rejected. In particular, this means that acl_smtp_rcpt must be defined in order +to receive any messages over an SMTP connection. The default configuration file +contains a suitable default for this. + +ACLs can be provided in line, or in files, or looked up from databases. One ACL +can call another in a subroutine-like manner. String expansion is used, and +which ACL to run can be varied according to sender host or any other criterion +that a string expansion can test. + +This is not the place to give a full specification of ACLs, but here is a +typical example for checking RCPT commands, taken from the default +configuration. The tests are performed in order. + +acl_check_rcpt: + # Accept if source is local SMTP (i.e. not over TCP/IP - undefined host) + accept hosts = : + + # Deny if the local part contains @ or % or / + deny local_parts = ^.*[@%/] + + # Accept mail to postmaster in any local domain, regardless of the source, + # and without verifying the sender. + accept domains = +local_domains + local_parts = postmaster + + # Deny unless the sender address can be verified. + require verify = sender + + # Accept if the address is in a local domain, but only if the recipient can + # be verified. Otherwise deny. The "endpass" line is the border between + # passing on to the next ACL statement (if tests above it fail) or denying + # access (if tests below it fail). + accept domains = +local_domains + endpass + message = unknown user + verify = recipient + + # We get here only for non-local domains. Accept if the message arrived over + # an authenticated connection, from any host. These messages are usually from + # MUAs, so recipient verification is omitted. + accept authenticated = * + + # Reaching the end of the ACL causes a "deny", but we might as well give + # an explicit message. + deny message = relay not permitted + +The following options have been abolished as a consequence of the introduction +of ACLs: + +auth_hosts, auth_over_tls_hosts, headers_checks_fail, headers_check_syntax, +headers_sender_verify, headers_sender_verify_errmsg, host_accept_relay, +host_auth_accept_relay, host_reject_recipients, prohibition_message, +rbl_domains, rbl_hosts, rbl_log_headers, rbl_log_rcpt_count, +rbl_reject_recipients, rbl_warn_header, receiver_try_verify, receiver_verify, +receiver_verify_addresses, receiver_verify_hosts, receiver_verify_senders, +recipients_reject_except, recipients_reject_except_senders, relay_domains, +relay_domains_include_local_mx, relay_match_host_or_sender, +sender_address_relay, sender_address_relay_hosts, sender_reject, +sender_reject_recipients, sender_try_verify, sender_verify, +sender_verify_batch, sender_verify_hosts, sender_verify_fixup, +sender_verify_hosts_callback, sender_verify_callback_domains, +sender_verify_callback_timeout, sender_verify_max_retry_rate, +sender_verify_reject, smtp_etrn_hosts, smtp_expn_hosts. smtp_verify, tls_hosts. + +The variable $prohibition_reason has been abolished. + +The host_reject option has been retained, but with its name changed to +host_reject_connection, to emphasize that it causes a rejection at connection +time. I've left it available just in case it is needed - but its use is not +recommended in normal circumstances. + + +Other Incoming SMTP Session Controls +------------------------------------ + +. The option smtp_accept_max_per_connection (default 1000) limits the number of + messages accepted over a single SMTP connection. This is a safety catch in + case some sender goes mad (incidents of this kind have been seen). After the + limit is reached, a 421 response is given to MAIL commands. + +. Some sites find it helpful to be able to limit the rate at which certain + hosts can send them messages, and the rate at which an individual message can + specify recipients. There are now options for controlling these two different + rates. + + Rate limiting applies only to those hosts that match smtp_ratelimit_hosts, + whose value is a host list. When a host matches, one or both of the options + smtp_ratelimit_mail and smtp_ratelimit_rcpt may be set. They apply to the + rate of acceptance of MAIL and RCPT commands in a single SMTP session, + respectively. + + The value of each option is a set of four comma-separated values: + + 1. A threshold, before which there is no rate limiting. + 2. An initial time delay. Unlike other times in Exim, fractions are allowed + here. + 3. A factor by which to increase the delay each time. + 4. A maximum value for the delay. + + For example, these settings have been used successfully at the site which + first suggested this feature, for controlling mail from their customers: + + smtp_ratelimit_mail = 2, 0.5s, 1.05, 4m + smtp_ratelimit_rcpt = 4, 0.25s, 1.015, 4m + +. The default value for smtp_connect_backlog has been increased to 20. + +. The SMTP protocol specification requires the client to wait for a response + from the server at certain points in the dialogue. (Without PIPELINING these + are after every command; with PIPELINING they are fewer, but still exist.) + Some spamming sites send out a complete set of SMTP commands without waiting + for any response. Exim 4 protects against this by rejecting messages if the + client has sent further input when it should not have. The error response + "554 SMTP synchronization error" is sent, and the connection is dropped. + + This check is controlled by smtp_enforce_sync, which is true by default. + +. helo_strict_syntax has been abolished. The default is now to enforce strict + domain syntax for HELO/EHLO arguments. You can use helo_accept_junk_hosts if + you want to avoid this. + +. There's a new option called helo_lookup_domains. If the domain given in a + HELO or EHLO command matches this list, a reverse lookup is done in order to + establish the host's true name. The default setting is + + helo_lookup_domains = @ : @[] + + That is, a lookup is forced if the client host gives the server's name or + [one of its IP addresses] in HELO or EHLO. (In Exim 3 this happened + automatically and was not configurable.) + +. The value of the global message_size_limit option is now expanded. For + locally submitted messages this happens at the start of message reception. + For messages from remote hosts, the expansion is done just after the host + connects, so that the value can depend on the host. + + +Handling of Resent- Fields +-------------------------- + +RFC 2822 makes it clear that Resent- fields are purely informational. Exim used +to make use of Resent-Reply-To: which does not actually exist, and it also used +to use the last set of resent- fields for all the address fields it recognized. + +In Exim 4, resent- headers are dealt with as follows: + +. A Resent-From: header that just contains the login id as the address is + automatically rewritten in the same way as From: is (using qualify domain, + and user name from the passwd data). + +. If there's a rewrite rule for a header, it is also applied to resent- headers + of the same type. For example, a rule that rewrites From: headers also + rewrites Resent-From: headers. + +. For local messages, if Sender: is being removed on input, Resent-Sender: is + also removed. + +. If there are any resent- headers but no Resent-Date: or Resent-From: they are + added. + +. The logic for adding Sender: is now duplicated for Resent-Sender. + +. If there's no Resent-Message-Id: one is created, and it is the + Resent-Message-Id: which is included in the log line. + + +Authentication +-------------- + +. The auth_hosts option has been abolished; this functionality is now + controlled by ACLs. + +. The auth_always_advertise option has been abolished because it depended on + auth_hosts and host_auth_accept_relay, both of which are no more. In its + place there is a new option called auth_advertise_hosts, whose default value + is *, meaning "advertise AUTH to all". + +. The value of server_setid is now used when logging failed authentication + attempts. + +. The -oMaa option allows trusted users to set the value of + $sender_host_authenticated (the authenticator name). This is normally used in + conjunction with -oMa. + + +Encryption +---------- + +. Because tls_hosts is no more, tls_advertise_hosts is now the only means of + controlling the advertisement of STARTTLS (previously, tls_hosts overrode). + +. The global option tls_verify_ciphers has been abolished. There are now + facilities for checking which cipher is in use in ACLs. + +. There's a new option called tls_try_verify_hosts. Like tls_verify_hosts, this + causes the server to request a certificate from a client, and it verifies the + certificate that it receives. However, unlike tls_verify_hosts, Exim + continues with the SMTP connection (encrypted) if a client certificate is not + received, or if the certificate does not verify. This state can be detected + in an ACL, which makes it possible to implement policies such as "accept for + relay only if a verified certificate has been received but accept for local + delivery if encrypted, even without a verified certificate". + + A match in tls_verify_hosts overrides tls_try_verify_hosts. + + +The Daemon +---------- + +. local_interfaces can now specify a port number with each address, thus + allowing a single Exim daemon to listen on multiple ports. The format of each + address is either [aaaa]:ppp or aaaa.ppp where aaaa is an IP address and ppp + is a port number. For example: + + local_interfaces = 192.168.3.4.25 : 192.168.3.4.26 + + If an address is listed without a port, the setting of daemon_smtp_port, or + the value of the -oX option, is the default. + +. The -oX option can now override local_interfaces. That is, it can supply IP + addresses as well as just a port. It is interpreted in this way if its value + contains any of the characters . : or []. For example: + + exim -bd -oX 10.9.8.7:10.11.12.13.2525 + + The format of the string is identical to the format recognized by the + local_interfaces option. + +. The way the daemon wrote PID files was overly complicated and messy. It no + longer tries to be clever. A PID file is written if, and only if, -bd is used + and -oX is _not_ used. In other words, only if the daemon is started with its + standard options. There is only one PID file. If pid_file_path is unset, it + is exim-daemon.pid in Exim's spool directory. Otherwise the value of + pid_file_path is used. For backwards compatibility, "%s" in this value is + replaced by an empty string. + + +Logging +------- + +The log_level option and all the various independent logging control options +have been abolished. In their place there is a single option called +log_selector. It takes a string argument composed of names preceded by + or - +characters. These turn on or off the logging of different things. For example: + + log_selector = +arguments -retry_defer + +The optional logging items (defaults marked *) are: + + address_rewrite address rewriting + all_parents all parents in => lines + arguments exim arguments + *connection_reject connection rejections + *delay_delivery immediate delivery delayed (message queued) + delivery_size add S=nnn to delivery lines + *dnslist_defer defers of DNS list (aka RBL) lookups + incoming_interface incoming interface on <= lines + incoming_port incoming port on <= lines + *lost_incoming_connection as it says (includes timeouts) + *queue_run start and end queue runs + received_sender sender on <= lines + received_recipients recipients on <= lines + *retry_defer "retry time not reached" + sender_on_delivery add sender to => lines + *size_reject rejection because too big + *skip_delivery "message is frozen" + smtp_confirmation SMTP confirmation on <= lines + smtp_connection SMTP connections + smtp_protocol_error SMTP protocol errors + smtp_syntax_error SMTP syntax errors + subject contents of Subject: on <= lines + *tls_cipher TLS cipher on <= lines + tls_peerdn TLS peer DN on <= lines + + all all of the above + +"retry time not reached" is always omitted from individual message logs after +the first delivery attempt. + +The log line "error message sent to" has been abolished, because the R= item on +the incoming message line gives the relationship between the original message +and the bounce. + +The logging options that have been abolished are: log_all_parents, +log_arguments, log_incoming_port, log_interface, log_ip_options, +log_level, log_queue_run_level, log_received_sender, log_received_recipients, +log_rewrites, log_sender_on_delivery, log_smtp_confirmation, +log_smtp_connections, log_smtp_syntax_errors, log_subject, tls_log_cipher, +tls_log_peerdn. + + +Debugging +--------- + +The debug_level option has been removed. The -dm option has been removed. The +-df option has also be removed, along with its related build-time option +STDERR_FILE. (To debug inetd usage, an auxiliary script should be used.) + +The -d option has been reworked. It no longer takes a debug level number +argument, but instead takes a list of debugging names, each preceded by + or - +to turn on or off individual sets of debugging messages. + +. The -v option now shows just the SMTP dialog and any log lines. + +. -d with no argument gives a lot of standard debugging data. This is in effect + the equivalent of the old -d9, the thing you ask people to set for an initial + debugging test. + +. -d+x adds debugging option x to the default set + -d-x removes debugging option x from the default set + -d-all+x leaves only debugging option x + +The available debugging names are: + + acl ACL interpretation + auth authenticators + deliver general delivery logic + dns DNS lookups (see also resolver) + dnsbl DNS black list (aka RBL) code + exec arguments for execv() calls + filter filter handling + hints_lookup hints data lookups + host_lookup all types of name->IP address handling + ident ident lookup + interface lists of local interfaces + lists matching things in lists + load system load checks + lookup general lookup code and all lookups + memory memory handling (replaces the old -dm) + process_info setting info for the process log + queue_run queue runs + receive general message reception logic + resolver turn on the DNS resolver's debugging output; goes to stdout + retry retry handling + rewrite rewriting + route address routing + tls TLS logic + transport transports + uid changes of uid/gid and looking up uid/gid + verify address verification logic + + all all of the above, and also -v + +The default (-d with no argument) includes all of the above, plus -v, with the +exception of filter, interface, load, memory, and resolver. Some debugging +output always happens unconditionally whenever any debugging is selected. This +includes some initial output and every log line. + +-d without any value was previously allowed for non-admin users because it used +to be synonymous with -v. In Exim 4, non-admin users may use -v, but not -d. + +If the debug_print option is set in any driver, it produces output whenever any +debugging is selected, or if -v is used. + + +Local Scan Function +------------------- + +For customized message scanning, you can now supply a C function that is linked +into the Exim binary. The function is called local_scan(), and it is called +when Exim has received a message, but has not yet sent a final +acknowledgement to the sender. This applies to all messages, whether local or +remote, SMTP or not. + +From within your function you can inspect the message, change the recipients, +add or remove headers, and tell Exim whether to accept or reject the message. + +The manual contains the specification of the API for this function. + + +String Expansion +---------------- + +. The lookup feature that allowed for subkeys using the syntax + + ${lookup {key:subkey} type {data... + + has been abolished (a) because the effect can be achieved using ${extract, + and (b) because in non-lsearch lookups, a colon can be a valid character in a + key. + +. When a string key is used in a ${extract expansion item, it is now handled + case-insensitively. + +. A new expansion variable called $tod_epoch gives the time as a single decimal + number representing the number of seconds from the start of the Unix epoch. + +. There's a new expansion operator that can turn numbers into base 62, for + example, ${base62:$tod_epoch}. + +. ${extract{number} now recognizes a negative number as a request to count + fields from the right. + +. There's a new expansion feature for reading files: + + ${readfile{/some/file}{eolstring}} + + The contents of the file replace the item. If {eolstring} is present (it's + optional) any newlines in the file are replaced by that string. + +. There's a new expansion feature for running commands: + + ${run{command args}{yes}{no}} + + Like all the other conditional items, the {yes} and {no} strings are + optional. Omitting both is equivalent to {$value}. The standard output of the + command is put into $value if the command succeeds (returns a zero code). The + value of the code itself is put into $runrc, and this remains set afterwards, + so in a filter file you can do things like + + if "${run{x y z}{}}$runrc" is 1 then ... + elsif $runrc is 2 then ... + + As in other command executions from Exim, a shell is not used by default. + If you want a shell, you must explicitly code it. + +. The redirect router has options for forbidding ${readfile and ${run in + filters. + +. A feature is provided to suppress expansion of part of a string. Any + characters between two occurrences of \N are copied to the output string + verbatim. This is particularly useful for protecting regular expressions from + unwanted expansion effects. For example: + + queue_smtp_domains = ! \N^ten-\d+\.testing\.com$\N + + Without \N the \ and $ characters in the regex would have to be escaped. + +. Radius authentication is supported in a similar way to PAM. You must set + RADIUS_CONFIG_FILE in Local/Makefile to specify the location of the Radius + client configuration file. Then you can use expansions such as + + server_condition = ${if radius{arguments}{yes}{no}} + +. User authentication can now also be done by attempting to bind to an LDAP + server. The syntax is again similar to PAM and Radius. + + server_condition = ${if ldapauth{ldap query}{yes}{no}} + + A user and password are required to be supplied with the query. No actual + data is looked up; Exim just does a bind to the LDAP server and sets the + condition according to the result. Here's an example of an SMTP + authenticator: + + login: + driver = plaintext + public_name = LOGIN + server_prompts = "Username:: : Password::" + server_condition = ${if ldapauth \ + {user="uid=${quote_ldap:$1},ou=people,o=example.org" pass="$2" \ + ldap://ldap.example.org/}{yes}{no}} + server_set_id = uid=$1,ou=people,o=example.org + + + +Security +-------- + +Exim 3 could be run in a variety of ways as far as security was concerned. This +has all been simplified in Exim 4. The security-conscious might like to know +that it no longer makes any use of the seteuid() function. + +. A UID and GID are required to be specified when Exim is compiled. They can be + now specified by name as well as by number, so the relevant options are now + called EXIM_USER and EXIM_GROUP. If you really feel you have to run Exim as + root, you can specify root here, but it is not recommended. + +. The "security" option has been abolished. Exim always releases its root + privilege when it can. In a conventional configuration, that means when it is + receiving a message, when it is delivering a message, when it is running a + queryprogram router, and when it is obeying users' filter files (and system + filters if it has been given a user for that purpose). + +. One important change is that Exim 4 runs as root while routing addresses for + delivery. Exim 3 used seteuid() to give up privilege temporarily while + routing. Apart from the unliked use of seteuid(), this sometimes gave rise to + permissions problems on configuration files. + +. However, Exim still runs as the Exim user while receiving messages, and + therefore while using the routing logic for verifying at SMTP time. + +. There is a new option called deliver_drop_privilege. If this is set, Exim + gives up its privilege right at the start of a delivery process, and runs the + entire delivery as the Exim user. This is the same action that used to be + requested by setting security=unprivileged. + + +Hints Databases +--------------- + +. A single "misc" hints database is now used for ETRN and host serialization. + There have been appropriate consequential changes to the utilities for + managing the hints. + +. The exim_tidydb -f option has been abolished. A full tidy is now always done + (it hasn't proved to be very expensive). + + +The run time Configuration File +------------------------------ + +. The format of the configuration file has changed. Instead of using "end" to + terminate sections, it now uses "begin <name>" to start sections. This means + that the sections, apart from the first, may appear in any order. + +. You can now include other files inside Exim run time configuration files, by + using this syntax: + + .include <file name> + +. Quotes round the file name are optional. Includes may be nested to any depth, + but remember that Exim reads its configuration file often. The processing of + .include happens early, at a physical line level, so, like comment lines, it + can be used in the middle of an options setting, for example: + + hosts_lookup = a.b.c \ + .include /some/file + + Include processing happens _before_ macro processing. Its effect is simply to + process the lines of the file as if they occurred inline where the .include + appears. + +. A macro at the start of a configuration line can now turn the line into an + empty line or a comment line. This applies to _logical_ input lines, that is, + after any concatenations have been done. + + +Format of spool files +--------------------- + +. -local_scan is used in spool files to record the value of $local_scan_data, + the string returned from the locally-provided local_scan() function. + + +Renamed Options +--------------- + +Some options have been renamed, to make their function clearer, or for +consistency. + +. receiver_unqualified_hosts has been renamed as recipient_unqualified_hosts. + I'm going to use "recipient" everywhere in future. + +. helo_verify has become helo_verify_hosts. + +. remote_sort has become remote_sort_domains. + +. In the appendfile and pipe transports, "prefix" and "suffix" have become + "message_prefix" and "message_suffix". In the generic router options, + "prefix" and "suffix" have become "local_part_prefix" and "local_part_suffix". + + +Miscellaneous +------------- + +. ETRN serialization now uses a double fork, so that an Exim process (detached + from the original input process) can wait for the command to finish. This + means that it works whatever command ETRN causes to run. (Previously it + worked only if ETRN ran "exim -Rxxx".) + +. For incoming messages, the server's port number is preserved, and is + available in $interface_port. The privileged option -oMi can be used to + set this value. + +. The -Mmd option (to mark addresses delivered) now operates in a + case-sensitive manner. + +. Checks for duplicate deliveries are now case-sensitive in the local part. + +. The number of situations where Exim panics has been reduced. For example, + expansion failures for the "domains" or "local_parts" options in a router now + cause deferral instead of a panic. + +. EXPN no longer attempts to distinguish local and remote addresses (but you + can cause it to be rejected for certain arguments in the ACL). + +. accept_timeout has been renamed as receive_timeout, to match + smtp_receive_timeout. + +. The ability to check an ident value as part of an item in a host list has + been removed. + +. The reject log shows a message's headers only if the rejection happens after + the SMTP DATA command (because they aren't available for earlier checks). The + sender, and up to five recipients are listed in Envelope-from: and + Envelope-to: header lines. After the headers, a line of separator characters + is output. Separators are no longer used for other reject log entries. + +. Because header checks are now done as part of ACLs, they now apply only to + SMTP input. + +. The port number on SMTP connections is now logged in the format [aaaa]:ppp + where aaaa is an IP address and ppp is a port, instead of in the format + [aaaa.ppp] because the former format causes some software to complain about + bad IP addresses. + +. The -oMa and -oMi options can now use the [aaaa]:ppp notation to set a port + number, but they still also recognize the aaaa.ppp notation. + +. The build-time option HAVE_AUTH is abolished. Exim automatically includes + authentication code if any authenticators are configured. + +. The nobody_user and nobody_group options have been abolished. + +. The $message_precedence variable has been abolished. The value is now + available as $h_precedence:. + +. There's a new utility script called exim_checkaccess which packages up a call + to Exim with the -bh option, for access control checking. The syntax is + + exim_checkaccess <IP address> <email address> [exim options] + + It runs "exim -bh <IP address>", does the SMTP dialogue, tests the result and + outputs either "accepted" or "Rejected" and the SMTP response to the RCPT TO + command. The sender is <> by default, but can be changed by the use of the + -f option. + +. The default state of Exim is now to forbid domain literals. For this reason, + the option that changes this has been renamed as allow_domain_literals. + +. The dns_check_names boolean option has been abolished. Checking is now turned + off by unsetting dns_check_names_pattern. + +. The errors_address and freeze_tell_mailmaster options have been abolished. In + their place there is a new option called freeze_tell, which can be set to a + list of addresses. A message is sent to these addresses whenever a message is + frozen - with the exception of failed bounce messages (this is not changed). + +. The message_size_limit_count_recipients option has been abolished on the + grounds that it was a failed experiment. + +. The very-special-purpose X rewrite flag has been abolished. The facility it + provided can now be done using the features of ACLs. + +. The timestamps_utc option has been abolished. The facility is now provided by + setting timezone = utc. + +. The value of remote_max_parallel now defaults to 2. + +. ignore_errmsg_errors has been abolished. The effect can be achieved by + setting ignore_bounce_errors_after = 0s. This option has been renamed from + ignore_errmsg_errors_after to make its function clearer. The default value + for ignore_bounce_errors_after is now 10w (10 weeks - i.e. likely to be + longer than any other timeouts, thereby disabling the facility). + +. The default for message_size_limit is now 50M as a guard against DoS attacks. + +. The -qi option does only initial (first time) deliveries. This can be helpful + if you are injecting message onto the queue using -odq and want a queue + runner just to process new messages. You can also use -qqi if you want. + +. Rewriting and retry patterns are now anything that can be single address list + items. They are processed by the same code, and are therefore expanded before + the matching takes place. Regular expressions must be suitably quoted. These + patterns may now be enclosed in double quotes so that white space may be + included. Normal quote processing applies. + +. Some scripts were built in the util directory, which was a mistake, because + they might be different for different platforms. Everything that is built is + now built in the build directory. The util directory just contains a couple + of scripts that are not modified at build time. + +. The installation script now installs the Exim binary as exim-v.vv-bb (where + v.vv is the version number and bb is the build number), and points a symbolic + link called "exim" to this binary. It does this in an atomic way so that + there is no time when "exim" is non-existent. The script is clever enough to + cope with an existing non-symbolic-link binary, converting it to the new + scheme automatically (and atomically). + +. When installing utilities, Exim now uses cp instead of mv to add .O to the + old ones, in order to preserve the permissions. + +. If the installation script is installing the default configuration, and + /etc/aliases does not exist, the script installs a default version. This does + not actually contain any aliases, but it does contain comments about ones + that should be created. A warning is output to the user. + +. A delay warning message is not sent if all the addresses in a message get a + "retry time not reached" error. Exim waits until a delivery is actually + attempted, so as to be able to give a more informative message. + +. The existence of the three options deliver_load_max, queue_only_load, and + deliver_queue_load_max was confusing, because their function overlapped. The + first of them has been abolished. We are left with + + queue_only_load no immediate delivery if load is high when + message arrives + deliver_queue_load_max no queued delivery if load is too high + +. The ability to edit message bodies (-Meb and the Eximon menu item) has been + removed, on the grounds that it is bad practice to do this. + +. Eximstats is now Steve Campbell's patched version, which displays sizes in K + and M and G, and can optionally generate HTML. + +. If bounce_sender_authentication is set to an email address, this address is + used in an AUTH option of the MAIL command when sending bounce messages, if + authentication is being used. For example, if you set + + bounce_sender_authentication = mailer-daemon@your.domain + + a bounce message will be sent over an authenticated connection using + + MAIL FROM:<> AUTH=mailer-daemon@your.domain + +. untrusted_set_sender has changed from a boolean to an address pattern. It + permits untrusted users to set sender addresses that match the pattern. Like + all address patterns, it is expanded. The identity of the user is in + $sender_ident, so you can, for example, restrict users to setting senders + that start with their login ids by setting + + untrusted_set_sender = ^$sender_ident- + + The effect of the previous boolean can be achieved by setting the value to *. + This option applies to all forms of local input. + +. The always_bcc option has been abolished. If an incoming message has no To: + or Cc: headers, Exim now always adds an empty Bcc: line. This makes the + message valid for RFC 822 (sic). In time, this can be removed, because RFC + 2822 does not require there to be a recipient header. + +. ACTION_OUTPUT=no is now the default in the Exim monitor. + +. dns_ipv4_lookup has changed from a boolean into a domain list, and it now + applies only to those domains. Setting this option does not stop Exim from + making IPv6 calls: if an MX lookup returns AAAA records, Exim will use them. + What it does is to stop Exim looking for AAAA records explicitly. + +. The -G option is ignored (another Sendmail thing). + +. If no_bounce_return_message is set, the original message is not included in + bounce messages. If you want to include additional information in the bounce + message itself, you can use the existing errmsg_file and errmsg_text + facilities. + +. -bdf runs the daemon in the foreground (i.e. not detached from the terminal), + even when no debugging is requested. + +. Options for changing Exim's behaviour on receiving IPv4 options have been + abolished. Exim now always refuses calls that set these options, and logs the + incident. The abolished options are kill_ip_options, log_ip_options, and + refuse_ip_options. + +. The pattern for each errors_copy entry is now matched as an item in an + address list. + +. A number of options and variables that used the word "errmsg" have been + changed to use "bounce" instead, because it seems that "bounce message" is + now a reasonably well-understood term. I used it in the book and am now using + it in the manual; it's a lot less cumbersome than "delivery error + notification message". The changes are: + + $errmsg_recipient => $bounce_recipient + errmsg_file => bounce_message_file + errmsg_text => bounce_message_text + ignore_errmsg_errors_after => ignore_bounce_errors_after + + For consistency, warnmsg_file has been changed to warn_message_file. However, + the two variables $warnmsg_delay and $warnmsg_recipients are unchanged. + + The hide_child_in_errmsg option has not changed, because it applies to both + bounce and delay warning messages. + +. smtp_accept_max_per_host is now an expanded string, so it can be varied on + a per-host basis. However, because this test happens in the daemon before it + forks, the expansion should be kept as simple as possible (e.g. just inline + tests of $sender_host_address). + +. The retry rules can now recognize the error "auth_failed", which happens when + authentication is required, but cannot be done. + +. There's a new option called local_sender_retain which can be set if + no_local_from_check is set. It causes Sender: headers to be retained in + locally-submitted messages. + +. The -dropcr command line option now turns CRLF into LF, and leaves isolated + CRs alone. Previously it simply dropped _all_ CR characters. There is now + also a drop_cr main option which, if turned on, assumes -dropcr for all + non-SMTP input. + + +Removal of Obsolete Things +-------------------------- + +. The obsolete values "fail_soft" and "fail_hard" for the "self" option have + been removed. + +. The obsolete "log" command has been removed from the filter language. + +. "service" was an obsolete synonym for "port" when specifying IP port numbers. + It has been removed. + +. The obsolete option collapse_source_routes has been removed. It has done + nothing since release 3.10. + +. The obsolete from_hack option in appendfile and pipe transports has been + removed. + +. The obsolete ipv4_address_lookup has been abolished (dns_ipv4_lookup has been + a synonym for some time, but it's changed - see above). + +. The obsolete generic transport options add_headers and remove_headers have + been abolished. The new names, headers_add and headers_remove, have been + available for some time. + +Philip Hazel +February 2002 diff --git a/doc/GnuTLS-FAQ.txt b/doc/GnuTLS-FAQ.txt new file mode 100644 index 0000000..ab4e5aa --- /dev/null +++ b/doc/GnuTLS-FAQ.txt @@ -0,0 +1,414 @@ +Using Exim 4.80+ with GnuTLS +============================ + +(1) I'm having problems building with GnuTLS 1, why? +(2) What changed? Why? +(3) I'm seeing: + "(gnutls_handshake): A TLS packet with unexpected length was received" + Why? +(4) What's the deal with MD5? (And SHA-1?) +(5) What happened to gnutls_require_kx / gnutls_require_mac / + gnutls_require_protocols? +(6) What's the deal with tls_dh_max_bits? What's DH? +(7) What's a Priority String? +(8) How do I use tls_require_ciphers? +(9) How do I test STARTTLS support? + + + +(1): I'm having problems building with GnuTLS 1, why? +----------------------------------------------------- + +GnuTLS's library interface has changed and Exim uses the more current +interface. Since GnuTLS is security critical code, you should probably update +to a supported release. + +If updating GnuTLS is not an option, then build Exim against OpenSSL instead. + +If neither is an option, then you might build Exim with the rule +"SUPPORT_TLS=yes" commented out in "Local/Makefile", so that your Exim build +no longer has TLS support. + +If you need to keep TLS support, and you can't use OpenSSL, then you'll have +to update the GnuTLS you have installed. Sorry. + +We've tested the build of Exim back as far as GnuTLS 2.8.x; most development +work is done with 2.12 and tested on 2.10 and 3.x. + +If you have to pick a version to upgrade to, use GnuTLS 3.x if available. The +GnuTLS developers took advantage of the version bump to add an error code +return value which makes debugging some problems a lot easier. + + + +(2): What changed? Why? +------------------------ + +The GnuTLS provider integration in Exim was overhauled, rewritten but with +some copy/paste, because building Exim against more current releases of GnuTLS +was issuing deprecation warnings from the compiler. + +When a library provider marks up the include files so that some function calls +will cause the compiler/linker to emit deprecation warnings, it's time to pay +serious attention. A future release might not work at all. Using the new +APIs may mean that Exim will *stop* working with older releases of GnuTLS. +The GnuTLS support in Exim was overhauled in Exim 4.80. In prior releases, +Exim hard-coded a lot of algorithms and constrained what could happen. In +Exim 4.79, we added to the hard-coded list just enough to let TLSv1.1 and +TLSv1.2 be negotiated, but not actually support the mandatory algorithms of +those protocol versions. When Exim's GnuTLS integration was originally +written, there was no other choice than to make Exim responsible for a lot of +this. In the meantime, GnuTLS has improved. + +With the rewrite, we started using the current API and leaving a lot more +responsibility for TLS decisions to the library. + +The GnuTLS developers added "priority strings" (see Q7), which provide an +interface exposed to the configuration file for a lot of the tuning. + +The GnuTLS policy is to no longer support MD5 in certificates. Exim had +previously been immune to this policy, but no longer. See Q4. + + + +(3): I'm seeing "A TLS packet with unexpected length was received". Why? +------------------------------------------------------------------------- + +The most likely reason is that the client dropped the connection during +handshake, because their library disliked some aspect of the negotiation. + +In GnuTLS 2, an EOF on the connection is reported with an error code for +packets being too large, and the above is the string returned by the library +for that error code. In GnuTLS 3, there's a specific error code for EOF and +the diagnostic will be less confusing. + +Most likely cause is an MD5 hash used in a certificate. See Q4 below. +Alternatively, the client dislikes the size of the Diffie-Hellman prime +offered by the server; if lowering the value of the "tls_dh_max_bits" Exim +option fixes the problem, this was the cause. See Q6. + + + +(4): What's the deal with MD5? (And SHA-1?) +-------------------------------------------- + +MD5 is a hash algorithm. Hash algorithms are used to reduce a lot of data +down to a fairly short value, which is supposed to be extremely hard to +manipulate to get a value of someone's choosing. Signatures, used to attest +to identity or integrity, rely upon this manipulation being effectively +impossible, because the signature is the result of math upon the hash result. +Without hash algorithms, signatures would be longer than the text being +signed. + +MD5 was once very popular. It still is far too popular. Real world attacks +have been proven possible against MD5. Including an attack against PKI +(Public Key Infrastructure) certificates used for SSL/TLS. In that attack, +the attackers got a certificate for one identity but were able to then publish +a certificate with the same signature but a different identity. This +undermines the whole purpose of having certificates. + +So GnuTLS stopped trusting any certificate with an MD5-based hash used in it. +The world has been hurriedly moving away from MD5 in certificates for a while. +If you still have such a certificate, you should move too. + +If you paid someone for your certificate, they should be willing to reissue +the certificate with a different algorithm, for no extra money. If they try +to charge money to replace their defective product, buy from someone else +instead. Part of the reason for paying money on a recurring basis is to cover +the ongoing costs of proving a trust relationship, such as providing +revocation protocols. This is just another of those ongoing costs you have +already paid for. + +The same has happened to SHA-1: there are real-world collision attacks against +SHA-1, so SHA-1 is mostly defunct in certificates. GnuTLS no longer supports +its use in TLS certificates. + + + +(5): ... gnutls_require_kx / gnutls_require_mac / gnutls_require_protocols? +--------------------------------------------------------------------------- + +These Exim options were used to provide fine-grained control over the TLS +negotiation performed by GnuTLS. They required explicit protocol knowledge +from Exim, which vastly limited what GnuTLS could do and involved the Exim +maintainers in decisions which aren't part of their professional areas of +expertise. The need for Exim to be able to do this went away when GnuTLS +introduced Priority Strings (see Q7). + +If you were using these options before, then you're already an expert user and +should be able to easily craft a priority string to accomplish your goals. +Set the Exim "tls_require_ciphers" value accordingly. There is a main section +option of this name, used for Exim receiving inbound connections, and an SMTP +driver transport option of this name, used for Exim establishing outbound +connections. + + + +(6): What's the deal with tls_dh_max_bits? What's DH? +------------------------------------------------------ + +You can avoid all of the tls_dh_max_bits issues if you leave "tls_dhparam" +unset, so that you get one of the standard built-in primes used for DH. + + +DH, Diffie-Hellman (or Diffie-Hellman-Merkle, or something naming Williamson) +is the common name for a way for two parties to a communication stream to +exchange some private random data so that both end up with a shared secret +which no eavesdropper can get. It does not provide for proof of the identity +of either party, so on its own is subject to man-in-the-middle attacks, but is +often combined with systems which do provide such proof, improving them by +separating the session key (the shared secret) from the long-term identity, +and so protecting past communications from a break of the long-term identity. + +To do this, the server sends to the client a very large prime number; this is +in the clear, an attacker can see it. This is not a problem; it's so not a +problem, that there are standard named primes which applications can use, and +which Exim now supports. + +The size of the prime number affects how difficult it is to break apart the +shared secret and decrypt the data. As time passes, the size required to +provide protection against an adversary climbs: computers get more powerful, +mathematical advances are made, and so on. + +Estimates of the size needed are published as recommendations by various +groups; a good summary of sizes currently recommended, for various +cryptographic primitives, is available at: + + http://www.keylength.com/en/3/ + +The GnuTLS folks think the ECRYPT II advice is good. They know far more of +such matters than the Exim folks, we just say "er, what they said". + +One of the new pieces of the GnuTLS API is a means for an application to ask +it for guidance and advice on how large some numbers should be. This is not +entirely internal to GnuTLS, since generating the numbers is slow, an +application might want to use a standard prime, etc. So, in an attempt to get +away from being involved in cryptographic policy, and to get rid of a +hard-coded "1024" in Exim's source-code, we switched to asking GnuTLS how many +bits should be in the prime number generated for use for Diffie-Hellman. We +then give this number straight back to GnuTLS when generating a DH prime. +We can ask for various sizes, and did not expose this to the administrator but +instead just asked for "NORMAL" protection. +Literally: + + dh_bits = gnutls_sec_param_to_pk_bits(GNUTLS_PK_DH, GNUTLS_SEC_PARAM_NORMAL); + +This API is only available as of GnuTLS 2.12. Prior to that release, we stuck +with the old value, for compatibility, so "1024" is still hard-coded. +Reviewing the page above, you'll see that this is described as "Short-term +protection against medium organizations, medium-term protection against small +organizations." + +So if you are using an old release of GnuTLS, you can either add to +Local/Makefile a different value of "EXIM_SERVER_DH_BITS_PRE2_12" or accept +that your protection might not be adequate to your needs. We advise updating +to a more current GnuTLS release and rebuilding Exim against that. + +Unfortunately, some TLS libraries have the client side bound how large a DH +prime they will accept from the server. The larger the number, the more +computation required to work with it and the slower that things get. So they +pick what they believe to be reasonable upper bounds, and then typically +forget about it for several years. + +Worse, in TLS the DH negotiation happens after a ciphersuite has been chosen, +so if the client dislikes the value then a different ciphersuite avoiding DH +can not be negotiated! The client typically drops the connection, resulting +in errors to the user and errors in the Exim logs. With GnuTLS 3, you'll see +the EOF (End-Of-File) error message in Exim's logs, reported as being part of +"gnutls_handshake", but with GnuTLS 2 you'll see a log message about a packet +with an unexpected size. Unless the client software is written intelligently +enough to be able to adapt and reconnect forbidding DH, the client will never +be able to negotiate TLS. + +This time around, we discovered that the NSS library used by various Mozilla +products, Chrome, etc, and most particularly by the Thunderbird mail client, +has the lowest cap. In fact, prior to recent updates, their upper limit was +lower than the value returned by GnuTLS for "NORMAL". The most recent NSS +library release raises this, but the most recent Thunderbird release still has +the old limit. + +So Exim had to get involved in cryptography policy decisions again. We added +the "tls_dh_max_bits" global option, to set a number used in both OpenSSL and +GnuTLS bindings for Exim. In GnuTLS, it clamps the value returned by +gnutls_sec_param_to_pk_bits(), so that if the returned value is larger than +tls_dh_max_bits then tls_dh_max_bits would be used instead. + +Our policy decision was to default the value of tls_dh_max_bits to the maximum +supported in the most recent Thunderbird release, and to make this an +administrator-available option so that administrators can choose to trade off +security versus compatibility by raising it. + +A future release of Exim may even let the administrator tell GnuTLS to ask for +more or less than "NORMAL". + +To add to the fun, the size of the prime returned by GnuTLS when we call +gnutls_dh_params_generate2() is not limited to be the requested size. GnuTLS +has a tendency to overshoot. 2237 bit primes are common when 2236 is +requested, and higher still have been observed. Further, there is no API to +ask how large the prime bundled up inside the parameter is; the most we can do +is ask how large the DH prime used in an active TLS session is. Since we're +not able to use GnuTLS API calls (and exporting to PKCS3 and then calling +OpenSSL routines would be undiplomatic, plus add a library dependency), we're +left with no way to actually know the size of the freshly generated DH prime. + +Thus we check if the the value returned is at least 10 more than the minimum +we'll accept as a client (EXIM_CLIENT_DH_MIN_BITS, see below, defaults to +1024) and if it is, we subtract 10. Then we reluctantly deploy a strategy +called "hope". This is not guaranteed to be successful; in the first code +pass on this logic, we subtracted 3, asked for 2233 bits and got 2240 in the +first test. + +If you see Thunderbird clients still failing, then as a user who can see into +Exim's spool directory, run: + +$ openssl dhparam -noout -text -in /path/to/spool/gnutls-params-2236 | head + +Ideally, the first line will read "PKCS#3 DH Parameters: (2236 bit)". If the +count is more than 2236, then remove the file and let Exim regenerate it, or +generate one yourself and move it into place. Ideally use "openssl dhparam" +to generate it, and then wait a very long time; at least this way, the size +will be correct. + +The use of "hope" as a strategy was felt to be unacceptable as a default, so +late in the RC series for 4.80, the whole issue was side-stepped. The primes +used for DH are publicly revealed; moreover, there are selection criteria for +what makes a "good" DH prime. As it happens, there are *standard* primes +which can be used, and are specified to be used for certain protocols. So +these primes were built into Exim, and by default exim now uses a 2048 bit +prime from section 2.2 of RFC 5114. + + +A TLS client does not get to choose the DH prime used, but can choose a +minimum acceptable value. For Exim, this is a compile-time constant called +"EXIM_CLIENT_DH_MIN_BITS" of 1024, which can be overruled in "Local/Makefile". + + + +(7): What's a Priority String? +------------------------------ + +A priority string is a way for a user of GnuTLS to tell GnuTLS how it should +make decisions about what to do in TLS; it includes which algorithms to make +available for various roles, what compatibility trade-offs to make, which +features to enable or disable. + +It is exposed to the Mail Administrator in Exim's configuration file as the +"tls_require_ciphers" option, which exists as a main section option for use in +Exim as a server, accepting connections, and as an option on Transports using +the SMTP driver, for use in Exim as a client. The main section option is +*not* the default for the transport option, they are entirely independent. +For both, the default value used by Exim is the string "NORMAL". (This is not +the same NORMAL as for DH prime bit size selection in Q6, but a different +NORMAL.) See Q8. + +The current documentation, for the most recent release of GnuTLS, is available +online at: + + http://www.gnutls.org/manual/html_node/Priority-Strings.html + +Beware that if you are not using the most recent GnuTLS release then this +documentation will be wrong for you! You should find the "info" documentation +which came with GnuTLS to review the available options. It's under "The TLS +Handshake Protocol". + +$ pinfo --node="Priority Strings" gnutls + +(This author is unable to persuade the "info" command-line tool to jump +straight to the required node, but "pinfo" works.) + +To trade off some security for more compatibility, you might set a value of +"NORMAL:%COMPAT". See the documentation for more, including lowering security +even further for more security, forcing clients to use the server's protocol +suite, and ways to force selection of particular algorithms. + + + +(8): How do I use tls_require_ciphers? +-------------------------------------- + +This is the name of two options in Exim. One is a main section option, used +by Exim as a server when a client initiates SSL/TLS negotiation, the other is +an option on transports which use "driver = smtp", used when Exim initiates +SSL/TLS as a client talking to a remote server. + +The option is expanded and so can take advantage of any variables which have +been set. This includes the IP address of the remote side, the port upon +which a connection was accepted (when a server), and more. Currently it does +not have access to $tls_sni, whether as a client or as a server. + +This example, for the main section's option, will let the library defaults be +permitted on the MX port, where there's probably no identity verification +anyway, and lowers security further by increasing compatibility; but this ups +the ante on the submission ports where the administrator might have some +influence on the choice of clients used: + +tls_require_ciphers = ${if =={$received_port}{25}\ + {NORMAL:%COMPAT}\ + {SECURE128}} + +Note that during Exim start-up, when this option is sanity-checked, there will +be no value of $received_port. In the above example, the checked value will +thus be "SECURE128". Be careful to ensure that it always expands safely. + + + +(9): How do I test STARTTLS support? +------------------------------------ + +The best command-line client for debugging specifically SSL/TLS which this +author has encountered is part of the GnuTLS suite, and is called +"gnutls-cli". It's best because it's the only interactive tool which lets the +user start TLS handshake exactly when they wish, so can choose to use the +STARTTLS command. + +$ gnutls-cli --starttls --crlf --port 587 mail.example.org + +After EHLO, to see the capabilities, enter STARTTLS, wait for the response, +then send EOF. Typically that's done by typing Ctrl-D at the start of a line. +The "gnutls-cli" tool will take over, set up TLS (or fail) and by the time it +returns to await more user input, you're using a secure connection and should +type your second EHLO. + +The "--x509cafile" option may be helpful for checking certificates and +"--priority" to pass a priority string to the client tool for configuring it. + +The --crlf is for strict protocol correctness, but Exim doesn't really need +it, so "gnutls-cli -s -p 587 mail.example.org" is shorter. + + +For debugging SMTP as a whole, we recommend swaks, "Swiss Army Knife SMTP", by +John Jetmore (one of the Exim Maintainers). This has some TLS tuning options; +it can be found at: + + http://www.jetmore.org/john/code/swaks/ + + +For OpenSSL, the "openssl s_client" command helps; you can either set up Exim +with a listening port which is SSL-on-connect or tell s_client to use +STARTTLS. + +For the former, use the "tls_on_connect_ports" option and the +"daemon_smtp_ports" option. Most clients for SSL-on-connect use the port +which was briefly registered with IANA for this purpose, 465. So you would +set something like: + + daemon_smtp_ports = 25 : 465 : 587 + tls_on_connect_ports = 465 + +To use s_client with STARTTLS support, use "-starttls smtp" on the +command-line. Beware that older versions of OpenSSL did not wait for the SMTP +banner before sending EHLO, which will fall afoul of the protocol +synchronisation checks in Exim (used to trip up pump-and-dump spammers); also +you will not get control of the session until TLS is established. That said, +this tool provides more tuning hooks for adjusting how TLS will be set up than +most. + +*BEWARE* that by default, s_client will take any line starting with a capital +letter "R" to be a request to initiate TLS renegotiation with the server and +the line will not be sent. This may trip up "RCPT TO:<someone@example.org>" +lines in SMTP. SMTP is not case-sensitive, so type "rcpt to" instead. +Alternatively, invoke s_client with the "-ign_eof" option to disable this +R-filtering and a few other features. + + +# END OF FAQ diff --git a/doc/NewStuff b/doc/NewStuff new file mode 100644 index 0000000..c3c69eb --- /dev/null +++ b/doc/NewStuff @@ -0,0 +1,1278 @@ +New Features in Exim +-------------------- + +This file contains descriptions of new features that have been added to Exim. +Before a formal release, there may be quite a lot of detail so that people can +test from the snapshots or the Git before the documentation is updated. Once +the documentation is updated, this file is reduced to a short list. + +Version 4.92 +-------------- + + 1. ${l_header:<name>} and ${l_h:<name>} expansion items, giving a colon-sep + list when there are multiple headers having a given name. This matters + when individual headers are wrapped onto multiple lines; with previous + facilities hard to parse. + + 2. The ${readsocket } expansion item now takes a "tls" option, doing the + obvious thing. + + 3. EXPERIMENTAL_REQUIRETLS and EXPERIMENTAL_PIPE_CONNECT optional build + features. See the experimental.spec file. + + 4. If built with SUPPORT_I18N a "utf8_downconvert" option on the smtp transport. + + 5. A "pipelining" log_selector. + + 6. Builtin macros for supported log_selector and openssl_options values. + + 7. JSON variants of the ${extract } expansion item. + + 8. A "noutf8" debug option, for disabling the UTF-8 characters in debug output. + + 9. TCP Fast Open support on MacOS. + +Version 4.91 +-------------- + + 1. Dual-certificate stacks on servers now support OCSP stapling, under GnuTLS + version 3.5.6 or later. + + 2. DANE is now supported under GnuTLS version 3.0.0 or later. Both GnuTLS and + OpenSSL versions are moved to mainline support from Experimental. + New SMTP transport option "dane_require_tls_ciphers". + + 3. Feature macros for the compiled-in set of malware scanner interfaces. + + 4. SPF support is promoted from Experimental to mainline status. The template + src/EDITME makefile does not enable its inclusion. + + 5. Logging control for DKIM verification. The existing DKIM log line is + controlled by a "dkim_verbose" selector which is _not_ enabled by default. + A new tag "DKIM=<domain>" is added to <= lines by default, controlled by + a "dkim" log_selector. + + 6. Receive duration on <= lines, under a new log_selector "receive_time". + + 7. Options "ipv4_only" and "ipv4_prefer" on the dnslookup router and on + routing rules in the manualroute router. + + 8. Expansion item ${sha3:<string>} / ${sha3_<N>:<string>} now also supported + under OpenSSL version 1.1.1 or later. + + 9. DKIM operations can now use the Ed25519 algorithm in addition to RSA, under + GnuTLS 3.6.0 or OpenSSL 1.1.1 or later. + +10. Builtin feature-macros _CRYPTO_HASH_SHA3 and _CRYPTO_SIGN_ED25519, library + version dependent. + +11. "exim -bP macro <name>" returns caller-usable status. + +12. Expansion item ${authresults {<machine>}} for creating an + Authentication-Results: header. + +13. EXPERIMENTAL_ARC. See the experimental.spec file. + See also new util/renew-opendmarc-tlds.sh script for use with DMARC/ARC. + +14: A dane:fail event, intended to facilitate reporting. + +15. "Lightweight" support for Redis Cluster. Requires redis_servers list to + contain all the servers in the cluster, all of which must be reachable from + the running exim instance. If the cluster has master/slave replication, the + list must contain all the master and slave servers. + +16. Add an option to the Avast scanner interface: "pass_unscanned". This + allows to treat unscanned files as clean. Files may be unscanned for + several reasons: decompression bombs, broken archives. + + +Version 4.90 +------------ + + 1. PKG_CONFIG_PATH can now be set in Local/Makefile; + wildcards will be expanded, values are collapsed. + + 2. The ${readsocket } expansion now takes an option to not shutdown the + connection after sending the query string. The default remains to do so. + + 3. An smtp transport option "hosts_noproxy_tls" to control whether multiple + deliveries on a single TCP connection can maintain a TLS connection + open. By default disabled for all hosts, doing so saves the cost of + making new TLS sessions, at the cost of having to proxy the data via + another process. Logging is also affected. + + 4. A malware connection type for the FPSCAND protocol. + + 5. An option for recipient verify callouts to hold the connection open for + further recipients and for delivery. + + 6. The reproducible build $SOURCE_DATE_EPOCH environment variable is now + supported. + + 7. Optionally, an alternate format for spool data-files which matches the + wire format - meaning more efficient reception and transmission (at the + cost of difficulty with standard Unix tools). Only used for messages + received using the ESMTP CHUNKING option, and when a new main-section + option "spool_wireformat" (false by default) is set. + + 8. New main configuration option "commandline_checks_require_admin" to + restrict who can use various introspection options. + + 9. New option modifier "no_check" for quota and quota_filecount + appendfile transport. + +10. Variable $smtp_command_history returning a comma-sep list of recent + SMTP commands. + +11. Millisecond timetamps in logs, on log_selector "millisec". Also affects + log elements QT, DT and D, and timstamps in debug output. + +12. TCP Fast Open logging. As a server, logs when the SMTP banner was sent + while still in SYN_RECV state; as a client logs when the connection + is opened with a TFO cookie. + +13. DKIM support for multiple signing, by domain and/or key-selector. + DKIM support for multiple hashes, and for alternate-identity tags. + Builtin macro with default list of signed headers. + Better syntax for specifying oversigning. + The DKIM ACL can override verification status, and status is visible in + the data ACL. + +14. Exipick understands -C|--config for an alternative Exim + configuration file. + +15. TCP Fast Open used, with data-on-SYN, for client SMTP via SOCKS5 proxy, + for ${readsocket } expansions, and for ClamAV. + +16. The "-be" expansion test mode now supports macros. Macros are expanded + in test lines, and new macros can be defined. + +17. Support for server-side dual-certificate-stacks (eg. RSA + ECDSA). + + +Version 4.89 +------------ + + 1. Allow relative config file names for ".include" + + 2. A main-section config option "debug_store" to control the checks on + variable locations during store-reset. Normally false but can be enabled + when a memory corrution issue is suspected on a production system. + + +Version 4.88 +------------ + + 1. The new perl_taintmode option allows to run the embedded perl + interpreter in taint mode. + + 2. New log_selector: dnssec, adds a "DS" tag to acceptance and delivery lines. + + 3. Speculative debugging, via a "kill" option to the "control=debug" ACL + modifier. + + 4. New expansion item ${sha3:<string>} / ${sha3_<N>:<string>}. + N can be 224, 256 (default), 384, 512. + With GnuTLS 3.5.0 or later, only. + + 5. Facility for named queues: A command-line argument can specify + the queue name for a queue operation, and an ACL modifier can set + the queue to be used for a message. A $queue_name variable gives + visibility. + + 6. New expansion operators base32/base32d. + + 7. The CHUNKING ESMTP extension from RFC 3030. May give some slight + performance increase and network load decrease. Main config option + chunking_advertise_hosts, and smtp transport option hosts_try_chunking + for control. + + 8. LMDB lookup support, as Experimental. Patch supplied by Andrew Colin Kissa. + + 9. Expansion operator escape8bit, like escape but not touching newline etc.. + +10. Feature macros, generated from compile options. All start with "_HAVE_" + and go on with some roughly recognisable name. Driver macros, for + router, transport and authentication drivers; names starting with "_DRIVER_". + Option macros, for each configuration-file option; all start with "_OPT_". + Use the "-bP macros" command-line option to see what is present. + +11. Integer values for options can take a "G" multiplier. + +12. defer=pass option for the ACL control cutthrough_delivery, to reflect 4xx + returns from the target back to the initiator, rather than spooling the + message. + +13. New built-in constants available for tls_dhparam and default changed. + +14. If built with EXPERIMENTAL_QUEUEFILE, a queuefile transport, for writing + out copies of the message spool files for use by 3rd-party scanners. + +15. A new option on the smtp transport, hosts_try_fastopen. If the system + supports it (on Linux it must be enabled in the kernel by the sysadmin) + try to use RFC 7413 "TCP Fast Open". No data is sent on the SYN segment + but it permits a peer that also supports the facility to send its SMTP + banner immediately after the SYN,ACK segment rather then waiting for + another ACK - so saving up to one roundtrip time. Because it requires + previous communication with the peer (we save a cookie from it) this + will only become active on frequently-contacted destinations. + +16. A new syslog_pid option to suppress PID duplication in syslog lines. + + +Version 4.87 +------------ + + 1. The ACL conditions regex and mime_regex now capture substrings + into numeric variables $regex1 to 9, like the "match" expansion condition. + + 2. New $callout_address variable records the address used for a spam=, + malware= or verify= callout. + + 3. Transports now take a "max_parallel" option, to limit concurrency. + + 4. Expansion operators ${ipv6norm:<string>} and ${ipv6denorm:<string>}. + The latter expands to a 8-element colon-sep set of hex digits including + leading zeroes. A trailing ipv4-style dotted-decimal set is converted + to hex. Pure ipv4 addresses are converted to IPv4-mapped IPv6. + The former operator strips leading zeroes and collapses the longest + set of 0-groups to a double-colon. + + 5. New "-bP config" support, to dump the effective configuration. + + 6. New $dkim_key_length variable. + + 7. New base64d and base64 expansion items (the existing str2b64 being a + synonym of the latter). Add support in base64 for certificates. + + 8. New main configuration option "bounce_return_linesize_limit" to + avoid oversize bodies in bounces. The default value matches RFC + limits. + + 9. New $initial_cwd expansion variable. + + +Version 4.86 +------------ + + 1. Support for using the system standard CA bundle. + + 2. New expansion items $config_file, $config_dir, containing the file + and directory name of the main configuration file. Also $exim_version. + + 3. New "malware=" support for Avast. + + 4. New "spam=" variant option for Rspamd. + + 5. Assorted options on malware= and spam= scanners. + + 6. A command-line option to write a comment into the logfile. + + 7. If built with EXPERIMENTAL_SOCKS feature enabled, the smtp transport can + be configured to make connections via socks5 proxies. + + 8. If built with EXPERIMENTAL_INTERNATIONAL, support is included for + the transmission of UTF-8 envelope addresses. + + 9. If built with EXPERIMENTAL_INTERNATIONAL, an expansion item for a commonly + used encoding of Maildir folder names. + +10. A logging option for slow DNS lookups. + +11. New ${env {<variable>}} expansion. + +12. A non-SMTP authenticator using information from TLS client certificates. + +13. Main option "tls_eccurve" for selecting an Elliptic Curve for TLS. + Patch originally by Wolfgang Breyha. + +14. Main option "dns_trust_aa" for trusting your local nameserver at the + same level as DNSSEC. + + +Version 4.85 +------------ + + 1. If built with EXPERIMENTAL_DANE feature enabled, Exim will follow the + DANE SMTP draft to assess a secure chain of trust of the certificate + used to establish the TLS connection based on a TLSA record in the + domain of the sender. + + 2. The EXPERIMENTAL_TPDA feature has been renamed to EXPERIMENTAL_EVENT + and several new events have been created. The reason is because it has + been expanded beyond just firing events during the transport phase. Any + existing TPDA transport options will have to be rewritten to use a new + $event_name expansion variable in a condition. Refer to the + experimental-spec.txt for details and examples. + + 3. The EXPERIMENTAL_CERTNAMES features is an enhancement to verify that + server certs used for TLS match the result of the MX lookup. It does + not use the same mechanism as DANE. + + +Version 4.84 +------------ + + +Version 4.83 +------------ + + 1. If built with the EXPERIMENTAL_PROXY feature enabled, Exim can be + configured to expect an initial header from a proxy that will make the + actual external source IP:host be used in exim instead of the IP of the + proxy that is connecting to it. + + 2. New verify option header_names_ascii, which will check to make sure + there are no non-ASCII characters in header names. Exim itself handles + those non-ASCII characters, but downstream apps may not, so Exim can + detect and reject if those characters are present. + + 3. New expansion operator ${utf8clean:string} to replace malformed UTF8 + codepoints with valid ones. + + 4. New malware type "sock". Talks over a Unix or TCP socket, sending one + command line and matching a regex against the return data for trigger + and a second regex to extract malware_name. The mail spoolfile name can + be included in the command line. + + 5. The smtp transport now supports options "tls_verify_hosts" and + "tls_try_verify_hosts". If either is set the certificate verification + is split from the encryption operation. The default remains that a failed + verification cancels the encryption. + + 6. New SERVERS override of default ldap server list. In the ACLs, an ldap + lookup can now set a list of servers to use that is different from the + default list. + + 7. New command-line option -C for exiqgrep to specify alternate exim.conf + file when searching the queue. + + 8. OCSP now supports GnuTLS also, if you have version 3.1.3 or later of that. + + 9. Support for DNSSEC on outbound connections. + +10. New variables "tls_(in,out)_(our,peer)cert" and expansion item + "certextract" to extract fields from them. Hash operators md5 and sha1 + work over them for generating fingerprints, and a new sha256 operator + for them added. + +11. PRDR is now supported dy default. + +12. OCSP stapling is now supported by default. + +13. If built with the EXPERIMENTAL_DSN feature enabled, Exim will output + Delivery Status Notification messages in MIME format, and negotiate + DSN features per RFC 3461. + + +Version 4.82 +------------ + + 1. New command-line option -bI:sieve will list all supported sieve extensions + of this Exim build on standard output, one per line. + ManageSieve (RFC 5804) providers managing scripts for use by Exim should + query this to establish the correct list to include in the protocol's + SIEVE capability line. + + 2. If the -n option is combined with the -bP option, then the name of an + emitted option is not output, only the value (if visible to you). + For instance, "exim -n -bP pid_file_path" should just emit a pathname + followed by a newline, and no other text. + + 3. When built with SUPPORT_TLS and USE_GNUTLS, the SMTP transport driver now + has a "tls_dh_min_bits" option, to set the minimum acceptable number of + bits in the Diffie-Hellman prime offered by a server (in DH ciphersuites) + acceptable for security. (Option accepted but ignored if using OpenSSL). + Defaults to 1024, the old value. May be lowered only to 512, or raised as + far as you like. Raising this may hinder TLS interoperability with other + sites and is not currently recommended. Lowering this will permit you to + establish a TLS session which is not as secure as you might like. + + Unless you really know what you are doing, leave it alone. + + 4. If not built with DISABLE_DNSSEC, Exim now has the main option + dns_dnssec_ok; if set to 1 then Exim will initialise the resolver library + to send the DO flag to your recursive resolver. If you have a recursive + resolver, which can set the Authenticated Data (AD) flag in results, Exim + can now detect this. Exim does not perform validation itself, instead + relying upon a trusted path to the resolver. + + Current status: work-in-progress; $sender_host_dnssec variable added. + + 5. DSCP support for outbound connections: on a transport using the smtp driver, + set "dscp = ef", for instance, to cause the connections to have the relevant + DSCP (IPv4 TOS or IPv6 TCLASS) value in the header. + + Similarly for inbound connections, there is a new control modifier, dscp, + so "warn control = dscp/ef" in the connect ACL, or after authentication. + + Supported values depend upon system libraries. "exim -bI:dscp" to list the + ones Exim knows of. You can also set a raw number 0..0x3F. + + 6. The -G command-line flag is no longer ignored; it is now equivalent to an + ACL setting "control = suppress_local_fixups". The -L command-line flag + is now accepted and forces use of syslog, with the provided tag as the + process name. A few other flags used by Sendmail are now accepted and + ignored. + + 7. New cutthrough routing feature. Requested by a "control = cutthrough_delivery" + ACL modifier; works for single-recipient mails which are received on and + deliverable via SMTP. Using the connection made for a recipient verify, + if requested before the verify, or a new one made for the purpose while + the inbound connection is still active. The bulk of the mail item is copied + direct from the inbound socket to the outbound (as well as the spool file). + When the source notifies the end of data, the data acceptance by the destination + is negotiated before the acceptance is sent to the source. If the destination + does not accept the mail item, for example due to content-scanning, the item + is not accepted from the source and therefore there is no need to generate + a bounce mail. This is of benefit when providing a secondary-MX service. + The downside is that delays are under the control of the ultimate destination + system not your own. + + The Received-by: header on items delivered by cutthrough is generated + early in reception rather than at the end; this will affect any timestamp + included. The log line showing delivery is recorded before that showing + reception; it uses a new ">>" tag instead of "=>". + + To support the feature, verify-callout connections can now use ESMTP and TLS. + The usual smtp transport options are honoured, plus a (new, default everything) + hosts_verify_avoid_tls. + + New variable families named tls_in_cipher, tls_out_cipher etc. are introduced + for specific access to the information for each connection. The old names + are present for now but deprecated. + + Not yet supported: IGNOREQUOTA, SIZE, PIPELINING. + + 8. New expansion operators ${listnamed:name} to get the content of a named list + and ${listcount:string} to count the items in a list. + + 9. New global option "gnutls_allow_auto_pkcs11", defaults false. The GnuTLS + rewrite in 4.80 combines with GnuTLS 2.12.0 or later, to autoload PKCS11 + modules. For some situations this is desirable, but we expect admin in + those situations to know they want the feature. More commonly, it means + that GUI user modules get loaded and are broken by the setuid Exim being + unable to access files specified in environment variables and passed + through, thus breakage. So we explicitly inhibit the PKCS11 initialisation + unless this new option is set. + + Some older OS's with earlier versions of GnuTLS might not have pkcs11 ability, + so have also added a build option which can be used to build Exim with GnuTLS + but without trying to use any kind of PKCS11 support. Uncomment this in the + Local/Makefile: + + AVOID_GNUTLS_PKCS11=yes + +10. The "acl = name" condition on an ACL now supports optional arguments. + New expansion item "${acl {name}{arg}...}" and expansion condition + "acl {{name}{arg}...}" are added. In all cases up to nine arguments + can be used, appearing in $acl_arg1 to $acl_arg9 for the called ACL. + Variable $acl_narg contains the number of arguments. If the ACL sets + a "message =" value this becomes the result of the expansion item, + or the value of $value for the expansion condition. If the ACL returns + accept the expansion condition is true; if reject, false. A defer + return results in a forced fail. + +11. Routers and transports can now have multiple headers_add and headers_remove + option lines. The concatenated list is used. + +12. New ACL modifier "remove_header" can remove headers before message gets + handled by routers/transports. + +13. New dnsdb lookup pseudo-type "a+". A sequence of "a6" (if configured), + "aaaa" and "a" lookups is done and the full set of results returned. + +14. New expansion variable $headers_added with content from ACL add_header + modifier (but not yet added to message). + +15. New 8bitmime status logging option for received messages. Log field "M8S". + +16. New authenticated_sender logging option, adding to log field "A". + +17. New expansion variables $router_name and $transport_name. Useful + particularly for debug_print as -bt command-line option does not + require privilege whereas -d does. + +18. If built with EXPERIMENTAL_PRDR, per-recipient data responses per a + proposed extension to SMTP from Eric Hall. + +19. The pipe transport has gained the force_command option, to allow + decorating commands from user .forward pipe aliases with prefix + wrappers, for instance. + +20. Callout connections can now AUTH; the same controls as normal delivery + connections apply. + +21. Support for DMARC, using opendmarc libs, can be enabled. It adds new + options: dmarc_forensic_sender, dmarc_history_file, and dmarc_tld_file. + It adds new expansion variables $dmarc_ar_header, $dmarc_status, + $dmarc_status_text, and $dmarc_used_domain. It adds a new acl modifier + dmarc_status. It adds new control flags dmarc_disable_verify and + dmarc_enable_forensic. The default for the dmarc_tld_file option is + "/etc/exim/opendmarc.tlds" and can be changed via EDITME. + +22. Add expansion variable $authenticated_fail_id, which is the username + provided to the authentication method which failed. It is available + for use in subsequent ACL processing (typically quit or notquit ACLs). + +23. New ACL modifier "udpsend" can construct a UDP packet to send to a given + UDP host and port. + +24. New ${hexquote:..string..} expansion operator converts non-printable + characters in the string to \xNN form. + +25. Experimental TPDA (Transport Post Delivery Action) function added. + Patch provided by Axel Rau. + +26. Experimental Redis lookup added. Patch provided by Warren Baker. + + +Version 4.80 +------------ + + 1. New authenticator driver, "gsasl". Server-only (at present). + This is a SASL interface, licensed under GPL, which can be found at + http://www.gnu.org/software/gsasl/. + This system does not provide sources of data for authentication, so + careful use needs to be made of the conditions in Exim. + + 2. New authenticator driver, "heimdal_gssapi". Server-only. + A replacement for using cyrus_sasl with Heimdal, now that $KRB5_KTNAME + is no longer honoured for setuid programs by Heimdal. Use the + "server_keytab" option to point to the keytab. + + 3. The "pkg-config" system can now be used when building Exim to reference + cflags and library information for lookups and authenticators, rather + than having to update "CFLAGS", "AUTH_LIBS", "LOOKUP_INCLUDE" and + "LOOKUP_LIBS" directly. Similarly for handling the TLS library support + without adjusting "TLS_INCLUDE" and "TLS_LIBS". + + In addition, setting PCRE_CONFIG=yes will query the pcre-config tool to + find the headers and libraries for PCRE. + + 4. New expansion variable $tls_bits. + + 5. New lookup type, "dbmjz". Key is an Exim list, the elements of which will + be joined together with ASCII NUL characters to construct the key to pass + into the DBM library. Can be used with gsasl to access sasldb2 files as + used by Cyrus SASL. + + 6. OpenSSL now supports TLS1.1 and TLS1.2 with OpenSSL 1.0.1. + + Avoid release 1.0.1a if you can. Note that the default value of + "openssl_options" is no longer "+dont_insert_empty_fragments", as that + increased susceptibility to attack. This may still have interoperability + implications for very old clients (see version 4.31 change 37) but + administrators can choose to make the trade-off themselves and restore + compatibility at the cost of session security. + + 7. Use of the new expansion variable $tls_sni in the main configuration option + tls_certificate will cause Exim to re-expand the option, if the client + sends the TLS Server Name Indication extension, to permit choosing a + different certificate; tls_privatekey will also be re-expanded. You must + still set these options to expand to valid files when $tls_sni is not set. + + The SMTP Transport has gained the option tls_sni, which will set a hostname + for outbound TLS sessions, and set $tls_sni too. + + A new log_selector, +tls_sni, has been added, to log received SNI values + for Exim as a server. + + 8. The existing "accept_8bitmime" option now defaults to true. This means + that Exim is deliberately not strictly RFC compliant. We're following + Dan Bernstein's advice in http://cr.yp.to/smtp/8bitmime.html by default. + Those who disagree, or know that they are talking to mail servers that, + even today, are not 8-bit clean, need to turn off this option. + + 9. Exim can now be started with -bw (with an optional timeout, given as + -bw<timespec>). With this, stdin at startup is a socket that is + already listening for connections. This has a more modern name of + "socket activation", but forcing the activated socket to fd 0. We're + interested in adding more support for modern variants. + +10. ${eval } now uses 64-bit values on supporting platforms. A new "G" suffix + for numbers indicates multiplication by 1024^3. + +11. The GnuTLS support has been revamped; the three options gnutls_require_kx, + gnutls_require_mac & gnutls_require_protocols are no longer supported. + tls_require_ciphers is now parsed by gnutls_priority_init(3) as a priority + string, documentation for which is at: + http://www.gnutls.org/manual/html_node/Priority-Strings.html + + SNI support has been added to Exim's GnuTLS integration too. + + For sufficiently recent GnuTLS libraries, ${randint:..} will now use + gnutls_rnd(), asking for GNUTLS_RND_NONCE level randomness. + +12. With OpenSSL, if built with EXPERIMENTAL_OCSP, a new option tls_ocsp_file + is now available. If the contents of the file are valid, then Exim will + send that back in response to a TLS status request; this is OCSP Stapling. + Exim will not maintain the contents of the file in any way: administrators + are responsible for ensuring that it is up-to-date. + + See "experimental-spec.txt" for more details. + +13. ${lookup dnsdb{ }} supports now SPF record types. They are handled + identically to TXT record lookups. + +14. New expansion variable $tod_epoch_l for higher-precision time. + +15. New global option tls_dh_max_bits, defaulting to current value of NSS + hard-coded limit of DH ephemeral bits, to fix interop problems caused by + GnuTLS 2.12 library recommending a bit count higher than NSS supports. + +16. tls_dhparam now used by both OpenSSL and GnuTLS, can be path or identifier. + Option can now be a path or an identifier for a standard prime. + If unset, we use the DH prime from section 2.2 of RFC 5114, "ike23". + Set to "historic" to get the old GnuTLS behaviour of auto-generated DH + primes. + +17. SSLv2 now disabled by default in OpenSSL. (Never supported by GnuTLS). + Use "openssl_options -no_sslv2" to re-enable support, if your OpenSSL + install was not built with OPENSSL_NO_SSL2 ("no-ssl2"). + + +Version 4.77 +------------ + + 1. New options for the ratelimit ACL condition: /count= and /unique=. + The /noupdate option has been replaced by a /readonly option. + + 2. The SMTP transport's protocol option may now be set to "smtps", to + use SSL-on-connect outbound. + + 3. New variable $av_failed, set true if the AV scanner deferred; ie, when + there is a problem talking to the AV scanner, or the AV scanner running. + + 4. New expansion conditions, "inlist" and "inlisti", which take simple lists + and check if the search item is a member of the list. This does not + support named lists, but does subject the list part to string expansion. + + 5. Unless the new EXPAND_LISTMATCH_RHS build option is set when Exim was + built, Exim no longer performs string expansion on the second string of + the match_* expansion conditions: "match_address", "match_domain", + "match_ip" & "match_local_part". Named lists can still be used. + + +Version 4.76 +------------ + + 1. The global option "dns_use_edns0" may be set to coerce EDNS0 usage on + or off in the resolver library. + + +Version 4.75 +------------ + + 1. In addition to the existing LDAP and LDAP/SSL ("ldaps") support, there + is now LDAP/TLS support, given sufficiently modern OpenLDAP client + libraries. The following global options have been added in support of + this: ldap_ca_cert_dir, ldap_ca_cert_file, ldap_cert_file, ldap_cert_key, + ldap_cipher_suite, ldap_require_cert, ldap_start_tls. + + 2. The pipe transport now takes a boolean option, "freeze_signal", default + false. When true, if the external delivery command exits on a signal then + Exim will freeze the message in the queue, instead of generating a bounce. + + 3. Log filenames may now use %M as an escape, instead of %D (still available). + The %M pattern expands to yyyymm, providing month-level resolution. + + 4. The $message_linecount variable is now updated for the maildir_tag option, + in the same way as $message_size, to reflect the real number of lines, + including any header additions or removals from transport. + + 5. When contacting a pool of SpamAssassin servers configured in spamd_address, + Exim now selects entries randomly, to better scale in a cluster setup. + + +Version 4.74 +------------ + + 1. SECURITY FIX: privilege escalation flaw fixed. On Linux (and only Linux) + the flaw permitted the Exim run-time user to cause root to append to + arbitrary files of the attacker's choosing, with the content based + on content supplied by the attacker. + + 2. Exim now supports loading some lookup types at run-time, using your + platform's dlopen() functionality. This has limited platform support + and the intention is not to support every variant, it's limited to + dlopen(). This permits the main Exim binary to not be linked against + all the libraries needed for all the lookup types. + + +Version 4.73 +------------ + + NOTE: this version is not guaranteed backwards-compatible, please read the + items below carefully + + 1. A new main configuration option, "openssl_options", is available if Exim + is built with SSL support provided by OpenSSL. The option allows + administrators to specify OpenSSL options to be used on connections; + typically this is to set bug compatibility features which the OpenSSL + developers have not enabled by default. There may be security + consequences for certain options, so these should not be changed + frivolously. + + 2. A new pipe transport option, "permit_coredumps", may help with problem + diagnosis in some scenarios. Note that Exim is typically installed as + a setuid binary, which on most OSes will inhibit coredumps by default, + so that safety mechanism would have to be overridden for this option to + be able to take effect. + + 3. ClamAV 0.95 is now required for ClamAV support in Exim, unless + Local/Makefile sets: WITH_OLD_CLAMAV_STREAM=yes + Note that this switches Exim to use a new API ("INSTREAM") and a future + release of ClamAV will remove support for the old API ("STREAM"). + + The av_scanner option, when set to "clamd", now takes an optional third + part, "local", which causes Exim to pass a filename to ClamAV instead of + the file content. This is the same behaviour as when clamd is pointed at + a Unix-domain socket. For example: + + av_scanner = clamd:192.0.2.3 1234:local + + ClamAV's ExtendedDetectionInfo response format is now handled. + + 4. There is now a -bmalware option, restricted to admin users. This option + takes one parameter, a filename, and scans that file with Exim's + malware-scanning framework. This is intended purely as a debugging aid + to ensure that Exim's scanning is working, not to replace other tools. + Note that the ACL framework is not invoked, so if av_scanner references + ACL variables without a fallback then this will fail. + + 5. There is a new expansion operator, "reverse_ip", which will reverse IP + addresses; IPv4 into dotted quad, IPv6 into dotted nibble. Examples: + + ${reverse_ip:192.0.2.4} + -> 4.2.0.192 + ${reverse_ip:2001:0db8:c42:9:1:abcd:192.0.2.3} + -> 3.0.2.0.0.0.0.c.d.c.b.a.1.0.0.0.9.0.0.0.2.4.c.0.8.b.d.0.1.0.0.2 + + 6. There is a new ACL control called "debug", to enable debug logging. + This allows selective logging of certain incoming transactions within + production environments, with some care. It takes two options, "tag" + and "opts"; "tag" is included in the filename of the log and "opts" + is used as per the -d<options> command-line option. Examples, which + don't all make sense in all contexts: + + control = debug + control = debug/tag=.$sender_host_address + control = debug/opts=+expand+acl + control = debug/tag=.$message_exim_id/opts=+expand + + 7. It has always been implicit in the design and the documentation that + "the Exim user" is not root. src/EDITME said that using root was + "very strongly discouraged". This is not enough to keep people from + shooting themselves in the foot in days when many don't configure Exim + themselves but via package build managers. The security consequences of + running various bits of network code are severe if there should be bugs in + them. As such, the Exim user may no longer be root. If configured + statically, Exim will refuse to build. If configured as ref:user then Exim + will exit shortly after start-up. If you must shoot yourself in the foot, + then henceforth you will have to maintain your own local patches to strip + the safeties off. + + 8. There is a new expansion condition, bool_lax{}. Where bool{} uses the ACL + condition logic to determine truth/failure and will fail to expand many + strings, bool_lax{} uses the router condition logic, where most strings + do evaluate true. + Note: bool{00} is false, bool_lax{00} is true. + + 9. Routers now support multiple "condition" tests. + +10. There is now a runtime configuration option "tcp_wrappers_daemon_name". + Setting this allows an admin to define which entry in the tcpwrappers + config file will be used to control access to the daemon. This option + is only available when Exim is built with USE_TCP_WRAPPERS. The + default value is set at build time using the TCP_WRAPPERS_DAEMON_NAME + build option. + +11. [POSSIBLE CONFIG BREAKAGE] The default value for system_filter_user is now + the Exim run-time user, instead of root. + +12. [POSSIBLE CONFIG BREAKAGE] ALT_CONFIG_ROOT_ONLY is no longer optional and + is forced on. This is mitigated by the new build option + TRUSTED_CONFIG_LIST which defines a list of configuration files which + are trusted; one per line. If a config file is owned by root and matches + a pathname in the list, then it may be invoked by the Exim build-time + user without Exim relinquishing root privileges. + +13. [POSSIBLE CONFIG BREAKAGE] The Exim user is no longer automatically + trusted to supply -D<Macro[=Value]> overrides on the command-line. Going + forward, we recommend using TRUSTED_CONFIG_LIST with shim configs that + include the main config. As a transition mechanism, we are temporarily + providing a work-around: the new build option WHITELIST_D_MACROS provides + a colon-separated list of macro names which may be overridden by the Exim + run-time user. The values of these macros are constrained to the regex + ^[A-Za-z0-9_/.-]*$ (which explicitly does allow for empty values). + + +Version 4.72 +------------ + + 1. TWO SECURITY FIXES: one relating to mail-spools which are globally + writable, the other to locking of MBX folders (not mbox). + + 2. MySQL stored procedures are now supported. + + 3. The dkim_domain transport option is now a list, not a single string, and + messages will be signed for each element in the list (discarding + duplicates). + + 4. The 4.70 release unexpectedly changed the behaviour of dnsdb TXT lookups + in the presence of multiple character strings within the RR. Prior to 4.70, + only the first string would be returned. The dnsdb lookup now, by default, + preserves the pre-4.70 semantics, but also now takes an extended output + separator specification. The separator can be followed by a semicolon, to + concatenate the individual text strings together with no join character, + or by a comma and a second separator character, in which case the text + strings within a TXT record are joined on that second character. + Administrators are reminded that DNS provides no ordering guarantees + between multiple records in an RRset. For example: + + foo.example. IN TXT "a" "b" "c" + foo.example. IN TXT "d" "e" "f" + + ${lookup dnsdb{>/ txt=foo.example}} -> "a/d" + ${lookup dnsdb{>/; txt=foo.example}} -> "def/abc" + ${lookup dnsdb{>/,+ txt=foo.example}} -> "a+b+c/d+e+f" + + +Version 4.70 / 4.71 +------------------- + + 1. Native DKIM support without an external library. + (Note that if no action to prevent it is taken, a straight upgrade will + result in DKIM verification of all signed incoming emails. See spec + for details on conditionally disabling) + + 2. Experimental DCC support via dccifd (contributed by Wolfgang Breyha). + + 3. There is now a bool{} expansion condition which maps certain strings to + true/false condition values (most likely of use in conjunction with the + and{} expansion operator). + + 4. The $spam_score, $spam_bar and $spam_report variables are now available + at delivery time. + + 5. exim -bP now supports "macros", "macro_list" or "macro MACRO_NAME" as + options, provided that Exim is invoked by an admin_user. + + 6. There is a new option gnutls_compat_mode, when linked against GnuTLS, + which increases compatibility with older clients at the cost of decreased + security. Don't set this unless you need to support such clients. + + 7. There is a new expansion operator, ${randint:...} which will produce a + "random" number less than the supplied integer. This randomness is + not guaranteed to be cryptographically strong, but depending upon how + Exim was built may be better than the most naive schemes. + + 8. Exim now explicitly ensures that SHA256 is available when linked against + OpenSSL. + + 9. The transport_filter_timeout option now applies to SMTP transports too. + + +Version 4.69 +------------ + + 1. Preliminary DKIM support in Experimental. + + +Version 4.68 +------------ + + 1. The body_linecount and body_zerocount C variables are now exported in the + local_scan API. + + 2. When a dnslists lookup succeeds, the key that was looked up is now placed + in $dnslist_matched. When the key is an IP address, it is not reversed in + this variable (though it is, of course, in the actual lookup). In simple + cases, for example: + + deny dnslists = spamhaus.example + + the key is also available in another variable (in this case, + $sender_host_address). In more complicated cases, however, this is not + true. For example, using a data lookup might generate a dnslists lookup + like this: + + deny dnslists = spamhaus.example/<|192.168.1.2|192.168.6.7|... + + If this condition succeeds, the value in $dnslist_matched might be + 192.168.6.7 (for example). + + 3. Authenticators now have a client_condition option. When Exim is running as + a client, it skips an authenticator whose client_condition expansion yields + "0", "no", or "false". This can be used, for example, to skip plain text + authenticators when the connection is not encrypted by a setting such as: + + client_condition = ${if !eq{$tls_cipher}{}} + + Note that the 4.67 documentation states that $tls_cipher contains the + cipher used for incoming messages. In fact, during SMTP delivery, it + contains the cipher used for the delivery. The same is true for + $tls_peerdn. + + 4. There is now a -Mvc <message-id> option, which outputs a copy of the + message to the standard output, in RFC 2822 format. The option can be used + only by an admin user. + + 5. There is now a /noupdate option for the ratelimit ACL condition. It + computes the rate and checks the limit as normal, but it does not update + the saved data. This means that, in relevant ACLs, it is possible to lookup + the existence of a specified (or auto-generated) ratelimit key without + incrementing the ratelimit counter for that key. + + In order for this to be useful, another ACL entry must set the rate + for the same key somewhere (otherwise it will always be zero). + + Example: + + acl_check_connect: + # Read the rate; if it doesn't exist or is below the maximum + # we update it below + deny ratelimit = 100 / 5m / strict / noupdate + log_message = RATE: $sender_rate / $sender_rate_period \ + (max $sender_rate_limit) + + [... some other logic and tests...] + + warn ratelimit = 100 / 5m / strict / per_cmd + log_message = RATE UPDATE: $sender_rate / $sender_rate_period \ + (max $sender_rate_limit) + condition = ${if le{$sender_rate}{$sender_rate_limit}} + + accept + + 6. The variable $max_received_linelength contains the number of bytes in the + longest line that was received as part of the message, not counting the + line termination character(s). + + 7. Host lists can now include +ignore_defer and +include_defer, analogous to + +ignore_unknown and +include_unknown. These options should be used with + care, probably only in non-critical host lists such as whitelists. + + 8. There's a new option called queue_only_load_latch, which defaults true. + If set false when queue_only_load is greater than zero, Exim re-evaluates + the load for each incoming message in an SMTP session. Otherwise, once one + message is queued, the remainder are also. + + 9. There is a new ACL, specified by acl_smtp_notquit, which is run in most + cases when an SMTP session ends without sending QUIT. However, when Exim + itself is is bad trouble, such as being unable to write to its log files, + this ACL is not run, because it might try to do things (such as write to + log files) that make the situation even worse. + + Like the QUIT ACL, this new ACL is provided to make it possible to gather + statistics. Whatever it returns (accept or deny) is immaterial. The "delay" + modifier is forbidden in this ACL. + + When the NOTQUIT ACL is running, the variable $smtp_notquit_reason is set + to a string that indicates the reason for the termination of the SMTP + connection. The possible values are: + + acl-drop Another ACL issued a "drop" command + bad-commands Too many unknown or non-mail commands + command-timeout Timeout while reading SMTP commands + connection-lost The SMTP connection has been lost + data-timeout Timeout while reading message data + local-scan-error The local_scan() function crashed + local-scan-timeout The local_scan() function timed out + signal-exit SIGTERM or SIGINT + synchronization-error SMTP synchronization error + tls-failed TLS failed to start + + In most cases when an SMTP connection is closed without having received + QUIT, Exim sends an SMTP response message before actually closing the + connection. With the exception of acl-drop, the default message can be + overridden by the "message" modifier in the NOTQUIT ACL. In the case of a + "drop" verb in another ACL, it is the message from the other ACL that is + used. + +10. For MySQL and PostgreSQL lookups, it is now possible to specify a list of + servers with individual queries. This is done by starting the query with + "servers=x:y:z;", where each item in the list may take one of two forms: + + (1) If it is just a host name, the appropriate global option (mysql_servers + or pgsql_servers) is searched for a host of the same name, and the + remaining parameters (database, user, password) are taken from there. + + (2) If it contains any slashes, it is taken as a complete parameter set. + + The list of servers is used in exactly the same was as the global list. + Once a connection to a server has happened and a query has been + successfully executed, processing of the lookup ceases. + + This feature is intended for use in master/slave situations where updates + are occurring, and one wants to update a master rather than a slave. If the + masters are in the list for reading, you might have: + + mysql_servers = slave1/db/name/pw:slave2/db/name/pw:master/db/name/pw + + In an updating lookup, you could then write + + ${lookup mysql{servers=master; UPDATE ...} + + If, on the other hand, the master is not to be used for reading lookups: + + pgsql_servers = slave1/db/name/pw:slave2/db/name/pw + + you can still update the master by + + ${lookup pgsql{servers=master/db/name/pw; UPDATE ...} + +11. The message_body_newlines option (default FALSE, for backwards + compatibility) can be used to control whether newlines are present in + $message_body and $message_body_end. If it is FALSE, they are replaced by + spaces. + + +Version 4.67 +------------ + + 1. There is a new log selector called smtp_no_mail, which is not included in + the default setting. When it is set, a line is written to the main log + whenever an accepted SMTP connection terminates without having issued a + MAIL command. + + 2. When an item in a dnslists list is followed by = and & and a list of IP + addresses, the behaviour was not clear when the lookup returned more than + one IP address. This has been solved by the addition of == and =& for "all" + rather than the default "any" matching. + + 3. Up till now, the only control over which cipher suites GnuTLS uses has been + for the cipher algorithms. New options have been added to allow some of the + other parameters to be varied. + + 4. There is a new compile-time option called ENABLE_DISABLE_FSYNC. When it is + set, Exim compiles a runtime option called disable_fsync. + + 5. There is a new variable called $smtp_count_at_connection_start. + + 6. There's a new control called no_pipelining. + + 7. There are two new variables called $sending_ip_address and $sending_port. + These are set whenever an SMTP connection to another host has been set up. + + 8. The expansion of the helo_data option in the smtp transport now happens + after the connection to the server has been made. + + 9. There is a new expansion operator ${rfc2047d: that decodes strings that + are encoded as per RFC 2047. + +10. There is a new log selector called "pid", which causes the current process + id to be added to every log line, in square brackets, immediately after the + time and date. + +11. Exim has been modified so that it flushes SMTP output before implementing + a delay in an ACL. It also flushes the output before performing a callout, + as this can take a substantial time. These behaviours can be disabled by + obeying control = no_delay_flush or control = no_callout_flush, + respectively, at some earlier stage of the connection. + +12. There are two new expansion conditions that iterate over a list. They are + called forany and forall. + +13. There's a new global option called dsn_from that can be used to vary the + contents of From: lines in bounces and other automatically generated + messages ("delivery status notifications" - hence the name of the option). + +14. The smtp transport has a new option called hosts_avoid_pipelining. + +15. By default, exigrep does case-insensitive matches. There is now a -I option + that makes it case-sensitive. + +16. A number of new features ("addresses", "map", "filter", and "reduce") have + been added to string expansions to make it easier to process lists of + items, typically addresses. + +17. There's a new ACL modifier called "continue". It does nothing of itself, + and processing of the ACL always continues with the next condition or + modifier. It is provided so that the side effects of expanding its argument + can be used. + +18. It is now possible to use newline and other control characters (those with + values less than 32, plus DEL) as separators in lists. + +19. The exigrep utility now has a -v option, which inverts the matching + condition. + +20. The host_find_failed option in the manualroute router can now be set to + "ignore". + + +Version 4.66 +------------ + +No new features were added to 4.66. + + +Version 4.65 +------------ + +No new features were added to 4.65. + + +Version 4.64 +------------ + + 1. ACL variables can now be given arbitrary names, as long as they start with + "acl_c" or "acl_m" (for connection variables and message variables), are at + least six characters long, with the sixth character being either a digit or + an underscore. + + 2. There is a new ACL modifier called log_reject_target. It makes it possible + to specify which logs are used for messages about ACL rejections. + + 3. There is a new authenticator called "dovecot". This is an interface to the + authentication facility of the Dovecot POP/IMAP server, which can support a + number of authentication methods. + + 4. The variable $message_headers_raw provides a concatenation of all the + messages's headers without any decoding. This is in contrast to + $message_headers, which does RFC2047 decoding on the header contents. + + 5. In a DNS black list, if two domain names, comma-separated, are given, the + second is used first to do an initial check, making use of any IP value + restrictions that are set. If there is a match, the first domain is used, + without any IP value restrictions, to get the TXT record. + + 6. All authenticators now have a server_condition option. + + 7. There is a new command-line option called -Mset. It is useful only in + conjunction with -be (that is, when testing string expansions). It must be + followed by a message id; Exim loads the given message from its spool + before doing the expansions. + + 8. Another similar new command-line option is called -bem. It operates like + -be except that it must be followed by the name of a file that contains a + message. + + 9. When an address is delayed because of a 4xx response to a RCPT command, it + is now the combination of sender and recipient that is delayed in + subsequent queue runs until its retry time is reached. + +10. Unary negation and the bitwise logical operators and, or, xor, not, and + shift, have been added to the eval: and eval10: expansion items. + +11. The variables $interface_address and $interface_port have been renamed + as $received_ip_address and $received_port, to make it clear that they + relate to message reception rather than delivery. (The old names remain + available for compatibility.) + +12. The "message" modifier can now be used on "accept" and "discard" acl verbs + to vary the message that is sent when an SMTP command is accepted. + + +Version 4.63 +------------ + +1. There is a new Boolean option called filter_prepend_home for the redirect + router. + +2. There is a new acl, set by acl_not_smtp_start, which is run right at the + start of receiving a non-SMTP message, before any of the message has been + read. + +3. When an SMTP error message is specified in a "message" modifier in an ACL, + or in a :fail: or :defer: message in a redirect router, Exim now checks the + start of the message for an SMTP error code. + +4. There is a new parameter for LDAP lookups called "referrals", which takes + one of the settings "follow" (the default) or "nofollow". + +5. Version 20070721.2 of exipick now included, offering these new options: + --reverse + After all other sorting options have bee processed, reverse order + before displaying messages (-R is synonym). + --random + Randomize order of matching messages before displaying. + --size + Instead of displaying the matching messages, display the sum + of their sizes. + --sort <variable>[,<variable>...] + Before displaying matching messages, sort the messages according to + each messages value for each variable. + --not + Negate the value for every test (returns inverse output from the + same criteria without --not). + + +Version 4.62 +------------ + +1. The ${readsocket expansion item now supports Internet domain sockets as well + as Unix domain sockets. If the first argument begins "inet:", it must be of + the form "inet:host:port". The port is mandatory; it may be a number or the + name of a TCP port in /etc/services. The host may be a name, or it may be an + IP address. An ip address may optionally be enclosed in square brackets. + This is best for IPv6 addresses. For example: + + ${readsocket{inet:[::1]:1234}{<request data>}... + + Only a single host name may be given, but if looking it up yield more than + one IP address, they are each tried in turn until a connection is made. Once + a connection has been made, the behaviour is as for ${readsocket with a Unix + domain socket. + +2. If a redirect router sets up file or pipe deliveries for more than one + incoming address, and the relevant transport has batch_max set greater than + one, a batch delivery now occurs. + +3. The appendfile transport has a new option called maildirfolder_create_regex. + Its value is a regular expression. For a maildir delivery, this is matched + against the maildir directory; if it matches, Exim ensures that a + maildirfolder file is created alongside the new, cur, and tmp directories. + + +Version 4.61 +------------ + +The documentation is up-to-date for the 4.61 release. Major new features since +the 4.60 release are: + +. An option called disable_ipv6, to disable the use of IPv6 completely. + +. An increase in the number of ACL variables to 20 of each type. + +. A change to use $auth1, $auth2, and $auth3 in authenticators instead of $1, + $2, $3, (though those are still set) because the numeric variables get used + for other things in complicated expansions. + +. The default for rfc1413_query_timeout has been changed from 30s to 5s. + +. It is possible to use setclassresources() on some BSD OS to control the + resources used in pipe deliveries. + +. A new ACL modifier called add_header, which can be used with any verb. + +. More errors are detectable in retry rules. + +There are a number of other additions too. + + +Version 4.60 +------------ + +The documentation is up-to-date for the 4.60 release. Major new features since +the 4.50 release are: + +. Support for SQLite. + +. Support for IGNOREQUOTA in LMTP. + +. Extensions to the "submission mode" features. + +. Support for Client SMTP Authorization (CSA). + +. Support for ratelimiting hosts and users. + +. New expansion items to help with the BATV "prvs" scheme. + +. A "match_ip" condition, that matches an IP address against a list. + +There are many more minor changes. + +**** diff --git a/doc/OptionLists.txt b/doc/OptionLists.txt new file mode 100644 index 0000000..0ef35f5 --- /dev/null +++ b/doc/OptionLists.txt @@ -0,0 +1,1062 @@ +LISTS OF EXIM OPTIONS +--------------------- + +This file contains complete lists of four kinds of Exim option: + + 1. Those that can appear in the run time configuration file; + 2. Those that can be used on the command line; + 3. Those that can appear in the build time configuration (Local/Makefile); + 4. Those that can appear in the build time configuration for the Exim monitor + (Local/eximon.conf). + +This file was last updated for Exim release 4.72. + + +1. RUN TIME OPTIONS +------------------- + +As Exim has developed, new options have been added at each major release. For +the most part, backwards compatibility has been maintained, and obsolete +options continue to be recognized. However, incompatible changes took place at +releases 3.00, and 4.00. In both cases, several groups of options were +amalgamated into new, extended options, and obsolete options were removed. + +The table below contains a complete list of all Exim's current options, along +with their types, default values, and where they can be used. String options +that are expanded before use are marked with *. Host lists, domain lists, and +address lists are always expanded. In some cases the defaults are not fixed +values, or not short enough to fit in the table. These are indicated by +. Some +other default values are determined when the Exim binary is compiled; these are +indicated by ++. + +For options that are specific to a particular driver, the fourth column +contains the driver name, for example, appendfile. Otherwise, it contains + + . `main' for options that appear in the main section of Exim's configuration + file; + + . `authenticators' for generic options that apply to any authenticator; + + . `routers' for generic options that apply to any router; + + . `transports' for generic options that apply to any transport. + +The fifth column contains the version of Exim in which the option was added, or +substantially changed. Where no number is given, the option has been in Exim +since the very early releases. The routers were completely reorganised for +release 4.00, and so no router options are shown as earlier than 4.00, though +in fact some of them were inherited from earlier versions. + +----------------------------------------------------------------------------------------- +accept_8bitmime boolean true main 1.60 changed to true in 4.80 +acl_not_smtp string* unset main 4.11 +acl_not_smtp_mime string* unset main 4.51 with content scan +acl_smtp_auth string* unset main 4.00 +acl_smtp_connect string* unset main 4.11 +acl_smtp_data string* unset main 4.00 +acl_smtp_data_prdr string* unset main 4.82 with experimental_prdr, 4.83 unless disable_prdr +acl_smtp_dkim string* unset main 4.70 unless disable_dkim +acl_smtp_etrn string* unset main 4.00 +acl_smtp_expn string* unset main 4.00 +acl_smtp_helo string* unset main 4.20 +acl_smtp_mail string* unset main 4.11 +acl_smtp_mailauth string* unset main 4.21 +acl_smtp_mime string* unset main 4.50 with content scan +acl_smtp_predata string* unset main 4.43 +acl_smtp_quit string* unset main 4.43 +acl_smtp_rcpt string* unset main 4.00 +acl_smtp_starttls string* unset main 4.11 +acl_smtp_vrfy string* unset main 4.00 +address_data string* unset routers 4.00 +address_retry_include_sender boolean true smtp 4.64 +address_test boolean true routers 4.14 +admin_groups string list unset main 3.02 +allow_domain_literals boolean false main 4.00 replacing forbid_domain_literals +allow_commands string list* unset pipe 1.89 +allow_defer boolean false redirect 4.00 +allow_fail boolean false redirect 4.00 +allow_filter boolean false redirect 4.00 +allow_freeze boolean false redirect 4.00 +allow_fifo boolean false appendfile 3.13 +allow_localhost boolean false smtp 1.73 +allow_mx_to_ip boolean false main 3.14 +allow_symlink boolean false appendfile +allow_utf8_domains boolean false main 4.14 +arc_sign string* unset smtp 4.91 with Experimental_ARC +auth_advertise_hosts host list "*" main 4.00 +authenticated_sender string* unset smtp 4.14 +authenticated_sender_force boolean false smtp 4.61 +authenticate_hosts host list unset smtp 3.13 +auto_thaw time 0s main +av_scanner string* + main 4.50 with content scan +batch_id string unset appendfile 4.00 + unset lmtp 4.00 + unset pipe 4.00 +batch_max integer 100 appendfile + 100 lmtp 3.20 + 100 pipe +bcc string* unset autoreply +bi_command string unset main +body_only boolean false transports 2.05 +bounce_message_file string unset main 4.00 +bounce_message_text string unset main 4.00 +bounce_return_body boolean true main 4.23 +bounce_return_message boolean true main 4.00 +bounce_return_size_limit int 100K main 4.23 better name for return_size_limit +bounce_sender_authentication string unset main 4.00 +callout_domain_negative_expire time 3h main 4.11 +callout_domain_positive_expire time 7d main 4.11 +callout_negative_expire time 2h main 4.11 +callout_positive_expire time 24h main 4.11 +callout_random_local_part string* + main 4.11 +cannot_route_message string* unset routers 4.11 +caseful_local_part boolean false routers 4.00 +cc string* unset autoreply +check_ancestor boolean false redirect 4.00 +check_group boolean false appendfile + + redirect 4.00 +check_local_user boolean false routers 4.00 +check_log_inodes integer 0 main +check_log_space integer 0 main +check_owner boolean true appendfile 3.14 + + redirect 4.00 +check_rfc2047_length boolean true main 4.60 +check_secondary_mx boolean false dnslookup 4.00 +check_spool_inodes integer 0 main +check_spool_space integer 0 main +check_string string "From " appendfile 3.03 + unset pipe 3.03 +check_srv string* unset dnslookup 4.31 +client_condition string* unset authenticators 4.68 +client_ignore_invalid_base64 boolean false plaintext 4.61 +client_name string* + cram_md5 3.10 +client_secret string* unset cram_md5 3.10 +client_send string* unset plaintext 3.10 +command string* unset lmtp 3.20 + unset pipe + unset queryprogram 4.00 +command_group string unset queryprogram 4.00 +command_timeout time 5m smtp +command_user string unset queryprogram 4.00 +commandline_checks_require_admin boolean false main 4.90 +condition string* unset routers 4.00 +connect_timeout time 0s smtp 1.60 +connection_max_messages integer 500 smtp 4.00 replaces batch_max +create_directory boolean true appendfile +create_file string "anywhere" appendfile +current_directory string unset transports 4.00 + unset queryprogram 4.00 +daemon_smtp_ports string unset main 1.75 pluralised in 4.21 +daemon_startup_retries int 9 main 4.52 +daemon_startup_sleep time 30s main 4.52 +dane_require_tls_ciphers string* unset smtp 4.91 +data string unset redirect 4.00 +data_timeout time 5m smtp +debug_print string* unset authenticators 4.00 + unset routers 4.00 + unset transports 2.00 +debug_store boolean false main 4.90 +delay_after_cutoff boolean true smtp +delay_warning time list 24h main +delay_warning_condition string* + main 1.73 +deliver_drop_privilege boolean false main 4.00 +deliver_queue_load_max fixed-point unset main 1.70 +delivery_date_add boolean false transports +delivery_date_remove boolean true main +dkim_canon string* unset smtp 4.70 +dkim_domain string list* unset smtp 4.72 +dkim_private_key string* unset smtp 4.70 +dkim_selector string* unset smtp 4.70 +dkim_sign_headers string* (RFC4871) smtp 4.70 +dkim_strict string* unset smtp 4.70 +dkim_timestamps integer* unset smtp 4.92 +dkim_verify_signers string* $dkim_signers main 4.70 +directory string* unset appendfile +directory_file string* + appendfile +directory_mode octal-integer 0700 appendfile +directory_transport string* unset redirect 4.00 +disable_ipv6 boolean false main 4.61 +disable_logging boolean false routers 4.11 + false transports 4.11 +dmarc_forensic_sender string unset main 4.82 if experimental_dmarc +dmarc_history_file string unset main 4.82 if experimental_dmarc +dmarc_tld_file string unset main 4.82 if experimental_dmarc +dns_again_means_nonexist domain list unset main 1.89 +dns_check_names_pattern string + main 2.11 +dns_cname_loops integer 0 main 4.92 Set to 9 for older behaviour +dns_csa_search_limit integer 5 main 4.60 +dns_csa_use_reverse boolean true main 4.60 +dns_dnssec_ok integer -1 main 4.82 +dns_dane_ok integer -1 main 4.83 +dns_ipv4_lookup boolean false main 3.20 +dns_qualify_single boolean true smtp +dns_retrans time 0s main 1.60 +dns_retry integer 0 main 1.60 +dns_search_parents boolean false smtp +dns_use_edns0 integer -1 main 4.76 +domains domain list unset routers 4.00 +driver string unset authenticators + unset routers 4.00 + unset transports +drop_cr boolean false main 4.00 became a no-op in 4.21 +dscp string unset smtp 4.82 +dsn_from string* + main 4.67 +envelope_to_add boolean false transports +envelope_to_remove boolean true main +environment string* unset pipe 2.95 +errors_copy string list* unset main +errors_reply_to string unset main +errors_to string* unset routers 4.00 +escape_string string ">From " appendfile 3.03 + unset pipe 3.03 +exim_group string ++ main +exim_path string ++ main +exim_user string ++ main +expn boolean true routers +extra_local_interfaces string unset main 4.21 +extract_addresses_remove_arguments boolean true main 1.92 +fail_verify boolean false routers +fail_verify_recipient boolean false routers 4.00 +fail_verify_sender boolean false routers 4.00 +fallback_hosts string list unset routers 4.00 + unset smtp +file string* unset appendfile + unset autoreply + unset redirect 4.00 +file_expand boolean false autoreply +file_format string unset appendfile 3.03 +file_must_exist boolean false appendfile +file_optional boolean false autoreply +file_transport string* unset redirect 4.00 +filter_prepend_home boolean true redirect 4.63 +final_timeout time 10m smtp +finduser_retries integer 0 main +forbid_blackhole boolean false redirect 4.00 +forbid_exim_filter boolean false redirect 4.44 +forbid_fail boolean false redirect 4.00 +forbid_file boolean false redirect 4.00 +forbid_filter_existstest boolean false redirect 4.00 +forbid_filter_logwrite boolean false redirect 4.00 +forbid_filter_lookup boolean false redirect 4.00 +forbid_filter_perl boolean false redirect 4.00 +forbid_filter_readfile boolean false redirect 4.00 +forbid_filter_readsocket boolean false redirect 4.11 +forbid_filter_reply boolean false redirect 4.00 +forbid_filter_run boolean false redirect 4.00 +forbid_include boolean false redirect 4.00 +forbid_pipe boolean false redirect 4.00 +forbid_sieve_filter boolean false redirect 4.44 +forbid_smtp_code boolean false redirect 4.63 +force_command boolean false pipe 4.82 +freeze_exec_fail boolean false pipe 1.89 +freeze_signal boolean false pipe 4.75 +freeze_tell boolean false main 4.00 replaces freeze_tell_mailmaster +from string* unset autoreply +gecos_name string* unset main +gecos_pattern string unset main +gethostbyname boolean false smtp +gnutls_allow_auto_pkcs11 boolean false main 4.82 +gnutls_compat_mode boolean unset main 4.70 +gnutls_require_kx string* unset main 4.67 deprecated, warns + string* unset smtp 4.67 deprecated, warns +gnutls_require_mac string* unset main 4.67 deprecated, warns + string* unset smtp 4.67 deprecated, warns +gnutls_require_protocols string* unset main 4.67 deprecated, warns + string* unset smtp 4.67 deprecated, warns +group string + routers 4.00 + unset transports 4.00 replaces local option in some transports +header_line_maxsize integer 0 (unset) main 4.14 +header_maxsize integer 1M main 4.14 +headers string* unset autoreply +headers_add string* unset routers 4.00 + unset transports +headers_charset string ++ main 4.21 +headers_only boolean false transports 2.05 +headers_remove string* unset routers 4.00 + unset transports +headers_rewrite string unset transports 3.20 +helo_accept_junk_hosts host list unset main 3.00 +helo_allow_chars string "" main 4.02 +helo_lookup_domains domain list unset main 4.00 +helo_data string* "$primary_hostname" smtp 3.21 +helo_try_verify_hosts host list unset main 4.00 +helo_verify_hosts host list unset main 1.73 +hide_child_in_errmsg false redirect 4.00 +hold_domains domain list unset main 1.70 +home_directory string* unset transports 4.00 replaces individual options +host_all_ignored string "defer" manualroute 4.67 +host_find_failed string "freeze" manualroute 4.00 +host_lookup host list unset main 3.00 +host_lookup_order string list "bydns:byaddr" main 4.30 +host_reject_connection host list unset main 4.00 +hosts string unset iplookup 4.00 + string list* unset smtp +hosts_avoid_esmtp host list unset smtp 4.21 +hosts_avoid_pipelining host list unset smtp 4.67 +hosts_avoid_tls host list unset smtp 3.20 +hosts_connection_nolog host list unset main 4.43 +hosts_max_try integer 5 smtp 3.20 +hosts_max_try_hardlimit integer 50 smtp 4.50 +hosts_nopass_tls host list unset smtp 4.00 +hosts_noproxy_tls host list "*" smtp 4.90 +hosts_override boolean false smtp 2.11 +hosts_pipe_connect host_list unset smtp 4.93 if experimental_pipe_connect +hosts_randomize boolean false manualroute 4.00 + false smtp 3.14 +hosts_require_auth host list unset smtp 4.00 +hosts_require_dane host list unset smtp 4.91 (4.85 experimental) +hosts_require_ocsp host list unset smtp 4.82 if experimental_ocsp +hosts_require_tls host list unset smtp 3.20 +hosts_treat_as_local domain list unset main 1.95 +hosts_try_auth host list unset smtp 4.00 +hosts_try_dane host list unset smtp 4.91 (4.85 experimental) +hosts_try_fastopen host list unset smtp 4.88 +hosts_try_prdr host list unset smtp 4.82 if experimental_prdr +ibase_servers string unset main 4.23 +ignore_bounce_errors_after time 0s main 4.00 +ignore_eacces boolean false redirect 4.00 +ignore_enotdir boolean false redirect 4.00 +ignore_fromline_hosts host list unset main +ignore_fromline_local boolean false main 2.05 +ignore_status boolean false pipe +ignore_target_hosts host list unset routers 4.00 +include_directory string unset redirect 4.00 +initgroups false routers 4.00 +interface string list unset smtp 1.70 +keep_malformed time 4d main +keepalive boolean true smtp 2.05 +ldap_default_servers string list unset main 3.02 +ldap_version int 2 or 3 main 4.14 +local_from_check boolean true main 3.14 +local_from_prefix string unset main 3.14 +local_from_suffix string unset main 3.14 +local_interfaces string list unset main 1.60 +local_part_prefix string unset routers 4.00 replaces prefix +local_part_prefix_optional boolean unset routers 4.00 replaces prefix_optional +local_part_suffix string unset routers 4.00 replaces suffix +local_part_suffix_optional boolean unset routers 4.00 replaces suffix_optional +local_parts string list* unset routers 4.00 +local_scan_timeout time 5m main 4.03 +local_sender_retain boolean false main 4.00 +localhost_number string unset main +lock_fcntl_timeout time 0s appendfile 3.14 +lock_flock_timeout time 0s appendfile 4.11 +lock_interval time 3s appendfile +lock_retries integer 10 appendfile +lockfile_mode octal-integer 0600 appendfile +lockfile_timeout time 30m appendfile +log string* unset autoreply +log_as_local boolean + routers 4.00 +log_file_path string list ++ main +log_defer_output boolean false pipe 1.89 +log_fail_output boolean false pipe 1.60 +log_output boolean false pipe 1.60 +log_selector string unset main 4.00 +log_timezone boolean false main 4.11 +lookup_open_max integer 25 main 2.05 +mailbox_filecount string* unset appendfile 4.43 +mailbox_size string* unset appendfile 4.43 +maildir_format boolean false appendfile 1.70 +maildir_retries integer 10 appendfile 1.70 +maildir_tag string* unset appendfile 1.92 +maildir_use_size_file boolean* false appendfile 4.30 expanded in 4.77 +maildirfolder_create_regex string unset appendfile 4.62 +mailstore_format boolean false appendfile 2.00 +mailstore_prefix string* unset appendfile 2.00 +mailstore_suffix string* unset appendfile 2.00 +match_directory string* unset localuser +max_output integer 20K pipe +max_rcpt integer 100 smtp 1.60 +max_user_name_length integer 0 main +mbx_format boolean false appendfile 2.10 +message_body_newlines boolean false main 4.68 +message_body_visible integer 500 main +message_id_header_domain string* unset main 4.11 +message_id_header_text string* unset main +message_logs boolean true main 4.10 +message_prefix string* + appendfile 4.00 replaces prefix + string* unset pipe 4.00 replaces prefix +message_size_limit integer 50M main + 0 transports 2.05 +message_suffix string* + appendfile 4.00 replaces suffix + string* unset pipe 4.00 replaces suffix +mode octal-integer 0600 appendfile + 0600 autoreply +mode_fail_narrower boolean true appendfile 1.70 +modemask octal-integer 022 redirect 4.00 +more boolean true routers 4.00 +move_frozen_messages boolean false main 3.09 +multi_domain boolean true smtp +mx_domains domain list unset dnslookup 4.00 +mx_fail_domains domain list unset dnslookup 4.43 +mysql_servers string list unset main 3.03 +never_users string list unset main +notify_comsat boolean false appendfile +once string* unset autoreply +once_file_size integer 0 autoreply 3.20 +once_repeat time 0s autoreply 2.95 +one_time boolean false redirect 4.00 +openssl_options string +no_sslv2 main 4.73 default changed in 4.80 +optional boolean false iplookup 4.00 +oracle_servers string unset main 4.00 +owners string list unset redirect 4.00 +owngroups string list unset redirect 4.00 +pass_on_timeout boolean false routers 4.00 +pass_router string unset routers 4.00 +path string "/usr/bin" pipe +percent_hack_domains domain list unset main +perl_at_start boolean false main 2.10 +perl_startup string unset main 2.10 +permit_coredump boolean false pipe 4.73 +pgsql_servers string list unset main 3.14 +pid_file_path string ++ main +pipe_as_creator boolean false pipe +pipe_transport string* unset redirect 4.00 +pipelining_advertise_hosts host list "*" main 4.14 +pipelining__connect_advertise_hosts host list "*" main 4.92 if experimental_pipe_connect +port integer 0 iplookup 4.00 + string "smtp" smtp +preserve_message_logs boolean false main +prdr_enable boolean false main 4.82 if experimental_prdr +primary_hostname string + main +print_topbitchars boolean false main 1.89 +process_log_path string unset main 4.21 +prod_requires_admin boolean true main 1.70 +protocol string "udp" iplookup 4.00 + string "smtp" smtp 3.20 +public_name string unset authenticators 3.10 +qualify_domain string + main + string* unset redirect 4.31 +qualify_preserve_domain boolean false redirect 4.00 +qualify_recipient string + main +qualify_single boolean true dnslookup 4.00 +query string* + iplookup 4.00 +queue_domains domain list unset main 4.00 +queue_list_requires_admin boolean true main 1.95 +queue_only boolean false main +queue_only_file string unset main 2.05 +queue_only_load fixed-point unset main +queue_only_load_latch boolean true main 4.68 +queue_only_override boolean true main 4.21 +queue_run_in_order boolean false main 1.70 +queue_run_max integer 5 main +queue_smtp_domains domain list unset main +quota string* unset appendfile 1.60 +quota_directory string* unset appendfile 4.11 +quota_filecount integer 0 appendfile 2.05 +quota_is_inclusive boolean true appendfile 3.20 +quota_size_regex string unset appendfile 3.14 +quota_warn_message string* + appendfile 2.10 +quota_warn_threshold string* 0 appendfile 2.10 +rcpt_include_affixes boolean false transports 4.21 +receive_timeout time 0s main 4.00 replacing accept_timeout +received_header_text string* + main +received_headers_max integer 30 main +recipient_unqualified_hosts host list unset main 4.00 replacing receiver_unqualified_hosts +recipients_max integer 0 main 1.60 +recipients_max_reject boolean false main 1.70 +redirect_router string unset routers 4.00 +remote_max_parallel integer 1 main +remote_sort_domains domain list unset main 4.00 replacing remote_sort +repeat_use boolean true redirect 4.00 +reply_to string* unset autoreply 2.05 +reply_transport string* unset redirect 4.00 +require_files string list* unset routers 4.00 +reroute string* unset iplookup 4.00 +response_pattern string unset iplookup 4.00 +restrict_to_path boolean false pipe +retry_data_expire time 7d main 3.03 +retry_include_ip_address boolean true smtp 1.92 +retry_interval_max time 24h main +retry_use_local_part boolean + routers 4.00 + + transports 4.00 replacing individual options +return_fail_output boolean false pipe 1.60 +return_message boolean false autoreply +return_output boolean false pipe +return_path string* unset transports 2.05 +return_path_add boolean false transports +return_path_remove boolean true main +return_size_limit integer 100K main renamed bounce_return_size_limit in 4.23 +rewrite boolean true redirect 4.00 +rewrite_headers boolean true dnslookup 4.00 +rfc1413_hosts host list * main +rfc1413_query_timeout time 5s main +router_home_directory string* unset routers 4.11 +route_data string* unset manualroute 4.00 +route_list string list unset manualroute 4.00 +same_domain_copy_routing boolean false dnslookup 4.00 +search_parents boolean false dnslookup 4.00 +self string "freeze" routers 4.00 +sender_unqualified_hosts host list unset main +senders address list unset routers 4.00 +serialize_hosts host list unset smtp 1.60 +server_advertise_condition string* unset authenticators 4.14 +server_channelbinding bool false gsasl 4.80 +server_condition string* unset authenticators 3.10 (plaintext) 4.64 (others) +server_hostname string* "$primary_hostname" cyrus_sasl,gsasl,heimdal_gssapi (cyrus-only) 4.80 (others) +server_keytab string* unset heimdal_gssapi 4.80 +server_mail_auth_condition string* unset authenticators 3.22 +server_mech string public_name cyrus_sasl,gsasl 4.43 (cyrus-only) 4.80 (others) +server_password string unset gsasl 4.80 +server_param1 string* unset tls (auth) 4.86 +server_param2 string* unset tls (auth) 4.86 +server_param3 string* unset tls (auth) 4.86 +server_prompts string* unset plaintext 3.10 +server_realm string unset cyrus_sasl,gsasl 4.43 (cyrus-only) 4.80 (others) +server_scram_iter string* unset gsasl 4.80 +server_scram_salt string* unset gsasl 4.80 +server_secret string* unset cram_md5 3.10 +server_service string "smtp" cyrus_sasl,gsasl,heimdal_gssapi (cyrus-only) 4.80 (others) +server_set_id string* unset authenticators 3.10 +shadow_condition string* unset transports +shadow_transport string unset transports +size_addition integer 1024 smtp 1.91 +skip_syntax_errors boolean false redirect 4.00 +smtp_accept_keepalive boolean true main +smtp_accept_max integer 20 main +smtp_accept_max_nonmail integer 10 main 4.11 +smtp_accept_max_nonmail_hosts host list * main 4.14 +smtp_accept_max_per_connection integer 1000 main 4.00 +smtp_accept_max_per_host integer 0 main 2.05 +smtp_accept_queue integer 0 main +smtp_accept_queue_per_connection integer 10 main 2.03 +smtp_accept_reserve integer 0 main +smtp_active_hostname string* unset main 4.33 +smtp_banner string* + main +smtp_check_spool_space boolean true main 2.10 +smtp_connect_backlog integer 5 main +smtp_enforce_sync boolean true main 4.00 +smtp_etrn_command string* unset main 1.92 +smtp_etrn_serialize boolean true main 1.89 +smtp_load_reserve fixed-point unset main +smtp_max_synprot_errors integer 3 main 4.30 +smtp_max_unknown_commands integer 3 main 4.14 +smtp_ratelimit_hosts host list unset main 4.00 +smtp_ratelimit_mail string unset main 4.00 +smtp_ratelimit_rcpt string unset main 4.00 +smtp_receive_timeout time 5m main +smtp_reserve_hosts host list unset main +smtp_return_error_details boolean false main 4.11 +socket string* unset lmtp 4.11 +spamd_address string* + main 4.50 with content scan +split_spool_directory boolean false main 1.70 +spool_directory string ++ main +spool_wireformat boolean false main 4.90 +sqlite_lock_timeout time 5s main 4.53 +strict_acl_vars boolean false main 4.64 +srv_fail_domains domain list unset dnslookup 4.43 +strip_excess_angle_brackets boolean false main +strip_trailing_dot boolean false main +subject string* unset autoreply +syntax_errors_text string* unset redirect 4.00 +syntax_errors_to string unset redirect 4.00 +syslog_duplication boolean true main 4.21 +syslog_facility string unset main 4.20 +syslog_processname string "exim" main 4.20 +syslog_timestamp boolean true main 4.00 +system_filter string unset main 4.00 replacing message_filter +system_filter_directory_transport string unset main 4.00 replacing message_filter +system_filter_file_transport string unset main 4.00 replacing message_filter +system_filter_group string unset main 4.00 replacing message_filter +system_filter_pipe_transport string unset main 4.00 replacing message_filter +system_filter_reply_transport string unset main 4.00 replacing message_filter +system_filter_user string unset main 4.00 replacing message_filter +tcp_nodelay boolean true main 4.23 + true smtp 4.23 +tcp_wrappers_daemon_name string* ++ main 4.73 +temp_errors string list + pipe 1.95 +text string* unset autoreply +timeout time 5m lmtp 3.20 + 1h pipe + 1h queryprogram 4.00 + 5s iplookup 4.00 +timeout_defer boolean false pipe 4.51 +timeout_frozen_after time 0s main 3.20 +timezone string + main 3.15 +tls_advertise_hosts host list * main 3.20 +tls_advertise_requiretls host list * main 4.92 if experimental_requiretls +tls_certificate string* unset main 3.20 + unset smtp 3.20 +tls_dh_max_bits integer 2236 main 4.80 +tls_dh_min_bits integer 1024 smtp 4.82 +tls_dhparam string* unset main 3.20 +tls_ocsp_file string* unset main 4.80 if experimental_ocsp +tls_on_connect_ports string unset main 4.43 +tls_privatekey string* unset main 3.20 + unset smtp 3.20 +tls_remember_emstp boolean false main 4.21 +tls_require_ciphers string* unset smtp 4.00 replaces tls_verify_ciphers + string* unset main 4.33 +tls_sni string* unset main 4.80 +tls_tempfail_tryclear boolean true smtp 4.05 +tls_try_verify_hosts host list unset main 4.00 +tls_verify_certificates string* unset main 3.20 + unset smtp 3.20 +tls_verify_hosts host list unset main 3.20 +to string* unset autoreply +translate_ip_address string unset routers 4.00 +transport string* unset routers 4.00 +transport_current_directory string unset routers 4.00 +transport_home_directory string unset routers 4.00 +transport_filter string unset transports +transport_filter_timeout time 5m transports 4.30 +trusted_groups string list unset main +trusted_users string list unset main +umask octal-integer 022 pipe +unknown_login string unset main +unknown_username string unset main +unseen boolean false routers 4.00 +untrusted_set_sender boolean false main 3.20 +use_bsmtp boolean false appendfile 4.00 + false pipe 4.00 +use_crlf boolean false appendfile 1.89 + false pipe 1.89 +use_fcntl_lock boolean + appendfile 1.70 +use_flock_lock boolean + appendfile 4.11 +use_lockfile boolean + appendfile +use_mbx_lock boolean + appendfile 2.10 +use_shell boolean false pipe 1.70 +user string + routers 4.00 + unset transports 4.00 replaces individual options +utf8_downconvert integer unset smtp 4.92 if SUPPORT_I18N +uucp_from_pattern string + main 1.75 +uucp_from_sender string* "$1" main 1.75 +verify boolean true routers 4.00 +verify_only boolean false routers 4.00 +verify_recipient boolean true routers 4.00 +verify_sender boolean true routers 4.00 +warn_message_file string unset main 4.00 +widen_domains string list unset dnslookup 4.00 +write_rejectlog boolean true main 4.31 + + + +2. COMMAND LINE OPTIONS +----------------------- + +The table below contains a complete list of all Exim's command line options. +Those marked with # are available only to trusted users, those marked with + +are available only to admin users, and those marked with * exist only to +provide compatibility with Sendmail. + +-- Terminate options +--help Give a little help (not a lot) +--version Give version information (alias for -bV) +-B * Ignored +-bd + Start daemon +-bdf + Start daemon and run it in the foreground +-be Test string expansion +-bem Test string expansion, read test message first +-bF Test system filter file +-bf Test user filter file +-bfd Set domain for filter testing +-bfl Set local part for filter testing +-bfp Set local part prefix for filter testing +-bfs Set local part suffix for filter testing +-bh Test incoming SMTP call, omitting callouts +-bhc Test incoming SMTP call, with callouts +-bi * Run <command>bi_command</command> +-bI:help Show list of accepted -bI:<tag> options +-bm Accept message on standard input +-bmalware + Invoke configured malware scanning against supplied filename +-bnq Don't qualify addresses in locally submitted messages +-bP Show configuration option settings +-bp + List the queue +-bpa + ... with generated addresses as well +-bpc + ... but just show a count of messages +-bpr + ... do not sort +-bpra + ... with generated addresses, unsorted +-bpru + ... only undelivered addresses, unsorted +-bpu + ... only undelivered addresses +-brt Test retry rules +-brw Test rewriting rules +-bS Read batch SMTP on standard input +-bs Run SMTP on standard input and output +-bt Test address directing and routing +-bV Verify version number +-bv Test recipient address verification +-bvs Test sender address verification +-bw + Inetd wait mode +-C + Use alternate configuration file +-D + Define macro for configuration file +-d + Turn on debugging output +-dd + Ditto, but if a daemon, not for subprocesses +-dropcr Remove CR character in input: became a no-op in 4.21 +-E Internal use only +-ex * Synonym for -oex (for several different x) +-F Set calling user name +-f # Set calling user address +-G * Ignored +-h * Ignored +-i Dot does not terminate message +-M + Force deliver specific message +-Mar + Add recipient to message +-MC Internal use only +-MCA Internal use only +-MCP Internal use only +-MCQ Internal use only +-MCS Internal use only +-MCT Internal use only +-Mc + Deliver specific message +-Mes + Edit message sender +-Mf + Freeze message(s) +-Mg + Give up (bounce) message(s) +-Mmad + Mark all recipients delivered +-Mmd + Mark one recipient delivered +-Mrm + Remove message(s) (no bounce) +-Mset + Load message's variables when testing with -be +-Mt + Thaw message(s) +-Mvb + View message body +-Mvc + View entire message in RFC 2822 format +-Mvh + View message header +-Mvl + View message log +-m * Ignored +-N + Deliver without transporting +-n * Ignored +-O * Ignored +-oA * Supply argument for <option>-bi</option> +-oB Set max messages down one connection +-odb Background delivery +-odf Foreground delivery +-odi Foreground delivery +-odq Queue message; do not deliver +-odqs ... do not do SMTP deliveries +-oee Error sent by mail; zero return code +-oem Error sent by mail; non-zero return code +-oep Error written to standard error stream +-oeq * Error written to standard error stream +-oew * Error sent by mail; non-zero return code +-oi Dot does not terminate message +-oitrue * Dot does not terminate message +-oMa # Supply host address +-oMaa # Supply authenticator name +-oMai # Supply authenticated id +-oMas # Supply authenticated sender +-oMi # Supply interface address +-oMm # Supply message reference +-oMr # Supply protocol name +-oMs # Supply host name +-oMt # Supply ident string +-om * Ignored +-oo * Ignored +-oP * Specify path for daemon's pid file +-or Timeout non-SMTP messages +-os Timeout for SMTP messages +-ov * Verbose; same as -v +-oX Alternative port for daemon +-pd Delay Perl interpreter start +-ps Do not delay Perl interpreter start +-p<r>:<s> * Same as -oMr <r> -oMs <s> +-q + Run the queue ) +-qf + ... force delivery ) Other combinations are +-qff + ... and include frozen messages ) possible. The syntax is +-qi + ... initial deliveries only ) +-ql + ... local deliveries only ) -q[q][f][f][i|l][time] +-qq + Two-stage queue run ) +-qR * Same as -R +-qS * Same as -S +-R Select by recipient in queue run +-Rf ... with forcing +-Rff ... and frozen messages +-Rr ... using regular expression +-Rrf ... with forcing +-Rrff ... and frozen messages +-r * Synonym for -f +-S Select by sender in queue run +-Sf ... with forcing +-Sff ... and frozen messages +-Sr ... using regular expression +-Srf ... with forcing +-Srff ... and frozen messages +-Tqt * Used by Exim test suite; not recognized in normal use +-t Take recipients from header lines +-ti * Same as -t -i +-tls-on-connect Do TLS on startup (for legacy clients) +-U * Ignored +-v Verbose - shows SMTP dialogue and other delivery info +-x Ignored (AIX compatibility) + + +3. BUILD TIME OPTIONS FOR EXIM +------------------------------ + +The table below contains a "mostly" complete list of options that can be +set in Local/Makefile when building Exim. The only items not included are +those whose names can be trivially derived from rules stated below. + +More information about individual options can be found in src/EDITME and +OS/Makefile-Default. + +The second column below gives the type of option: + + . `system' means the option is concerned with the operating system; + + . `driver' means the option selects a driver to be included in the binary; + + . `lookup' means the option selects a lookuptype to be included in the binary; + + . `mandatory' means the option is required to be supplied; + + . `recommended' means the option is recommended to be supplied; + + . `optional' means what it says; + +Those marked with * are specialized and are unlikely to be required in most +installations. Those that are marked with ** are commonly set in OS-specific +Makefiles. If you use any of these in your Local/Makefile, you may need to +reproduce some of the OS-specific settings. For example, in the Makefile for +Solaris (which is actually called OS/Makefile-SunOS5), there is + + LIBS=-lsocket -lnsl -lkstat + +If you use LIBS to add extra libraries, you must also include the OS ones in +your setting. It is better, in this particular case, to use EXTRALIBS, which is +empty by default, and is provided for just this reason. Of course, if you do +actually want to modify a setting from the OS-specific file, there is nothing +to stop you overriding it in your Local/Makefile. + +When building Exim with dynamically loaded lookup support, for "LOOKUP_FOO", +you can define "LOOKUP_FOO_INCLUDE" and "LOOKUP_FOO_LIBS", for includes and +libraries specific only to that module. These rules are only used where the +relevant lookup is a module. These options are not explicitly listed below. + +Variables with names endined `_PC' are used for pkg-config integration; setting +the value to the name of a pkg-config package will cause Exim's build system to +query the --cflags and --libs for the given name, when building anything +dependent upon the component associated with the `_PC' variable. For lookups, +if the lookup is dynamically loaded, then this *replaces* the use of the +corresponding _INCLUDE and _LIBS options, which will be ignored. If the lookup +is statically loaded into Exim, the results will be inserted into the +"LOOKUP_INCLUDE" and "LOOKUP_LIBS" options. For authenticator, the results +will be inserted into the "CFLAGS" and "AUTH_LIBS" options. These options are +only listed below for the TLS implementation cases. + + +Option Type Description +------------------------------------------------------------------------------ + +ALT_CONFIG_PREFIX optional restricts location of -C files +APPENDFILE_MODE optional* +APPENDFILE_DIRECTORY_MODE optional* +APPENDFILE_LOCKFILE_MODE optional* +AR system command to build a library +AUTH_CRAM_MD5 driver include cram_md5 authenticator +AUTH_CYRUS_SASL driver include Cyrus SASL authenticator +AUTH_GSASL driver include GNU SASL authenticator +AUTH_HEIMDAL_GSSAPI driver include Heimdal GSSAPI authenticator +AUTH_LIBS system library linkage for authenticators +AUTH_PLAINTEXT driver include plaintext authenticator +AUTH_SPA driver include SPA (NTLM) authenticator +AUTH_VARS=3 optional* number of $auth variables +BASENAME_COMMAND system** path to basename +BASE_62=62 optional* not normally changed for Unix +BIN_DIRECTORY mandatory Exim binary directory +CC system** C compiler +CFLAGS system** flags for C compiler +CFLAGS_DYNAMIC system** extra flags needed for .so modules +CHGRP_COMMAND system** path to chgrp +CHOWN_COMMAND system** path to chown +COMPRESS_COMMAND system path to a compress command +COMPRESS_SUFFIX system suffix added to compressed files +CONFIGURE_FILE mandatory Exim runtime configuration file +CONFIGURE_FILE_USE_EUID optional* +CONFIGURE_FILE_USE_NODE optional* +CONFIGURE_GROUP optional* alternate group for configuration file +CONFIGURE_OWNER optional* alternate owner for configuration file +CYRUS_PWCHECK_SOCKET optional socket for pwcheck daemon +DBMLIB optional** location of DBM library +DB_DIRECTORY_MODE optional* mode for hints directory +DB_LOCKFILE_MODE optional* mode for hints lock files +DB_LOCK_TIMEOUT optional* timeout for hints lock files +DB_MODE optional* mode for hints files +DEFAULT_CRYPT optional default crypt() function +DELIVER_IN_BUFFER_SIZE optional* +DELIVER_OUT_BUFFER_SIZE optional* +DISABLE_DKIM optional disables DKIM support +DISABLE_DNSSEC optional disables attempts to use DNSSEC +DISABLE_D_OPTION optional disables -D option +ERRNO_QUOTA optional* error code for system quota failures +EXICYCLOG_MAX optional number of old log files to keep +EXIMDB_DIRECTORY_MODE optional* for hints database directory +EXIMDB_LOCKFILE_MODE optional* for hints lock files +EXIMDB_MODE optional* mode for hints files +EXIMON_TEXTPOP system** +EXIM_CHMOD optional* +EXIM_GROUP mandatory group to use for Exim +EXIM_MONITOR optional set to eximon.bin to compile +EXIM_PERL optional +EXIM_USER mandatory user to use for Exim +EXIWHAT_EGREP_ARG system** to find Exim processes from ps +EXIWHAT_KILL_SIGNAL system** -SIGUSR1 or numerical equivalent +EXIWHAT_MULTIKILL_CMD system** +EXIWHAT_MULTIKILL_ARG system** +EXIWHAT_PS_ARG system** to list all processes +EXIWHAT_PS_CMD system** path to ps command +EXPAND_LISTMATCH_RHS optional* restore pre-4.77 match_*{}{} behaviour +EXTRALIBS system additional libraries +EXTRALIBS_EXIM system additional libraries for Exim only +EXTRALIBS_EXIMON system additional libraries for the monitor +FIXED_NEVER_USERS optional can't override at runtime +HAVE_ICONV system the iconv() function is available +HAVE_IPV6 system include IPv6 support +HEADERS_CHARSET optional charset for decoded header lines +HEADER_ADD_BUFFER_SIZE optional* buffer for header_add() +HEADER_MAXSIZE optional* max memory for message header +HOSTNAME_COMMAND system** path to hostname command +INCLUDE system path to include files +INFO_DIRECTORY optional directory for Info documentation +INPUT_DIRECTORY_MODE optional mode for input directory +IPV6_INCLUDE system additional includes for IPv6 +IPV6_LIBS system additional libraries for IPv6 +LDAP_LIB_TYPE optional type of LDAP library +LFLAGS system** link editor flags +LIBIDENTCFLAGS system C flags when compiling libident +LIBIDENTNAME system name for libident library +LIBRESOLV system** library for DNS resolver +LIBS system** additional libraries +LIBS_EXIM system** additional libraries for Exim ony +LIBS_EXIMON system** additional libraries for monitor +LOCAL_SCAN_SOURCE optional location of local_scan() source +LOG_DIRECTORY_MODE optional mode for log directory +LOG_FILE_PATH optional path to log files +LOG_MODE optional mode for log files +LOOKUP_CDB lookup include cdb lookup +LOOKUP_DBM lookup include dbm lookup +LOOKUP_DNSDB lookup include dnsdb lookup +LOOKUP_DSEARCH lookup include dsearch lookup +LOOKUP_INCLUDE lookup include files for lookups +LOOKUP_LDAP lookup include ldap lookup +LOOKUP_LIBS lookup include libraries for lookups +LOOKUP_LSEARCH lookup include all lsearch lookups +LOOKUP_MODULE_DIR optional* where dynamic lookup modules live +LOOKUP_MYSQL lookup include mysql lookup +LOOKUP_NIS lookup include nis lookup +LOOKUP_NISPLUS lookup include nisplus lookup +LOOKUP_ORACLE lookup include oracle lookup +LOOKUP_PGSQL lookup include pgsql lookup +LOOKUP_TESTDB lookup* +LOOKUP_WHOSON lookup include whoson lookup +LOOKUP_*_INCLUDE optional* include files for dynamic module +LOOKUP_*_LIBS optional* libraries for dynamic module +MAKE_SHELL optional* shell to use for make +MAX_FILTER_SIZE optional* max file size for filter files +MAX_INCLUDE_SIZE optional* max file size for :include: files +MAX_LOCALHOST_NUMBER=256 optional* for when localhost_number is set +MAX_NAMED_LIST optional* max named lists of a given type +MAX_INTERFACES system maximum network interfaces +MSGLOG_DIRECTORY_MODE optional* mode for message log directory +MV_COMMAND system path to mv command +NO_SYMLINK optional install doesn't make 'exim" symlink +PCRE_CONFIG system* use pcre-config for PCRE support +PCRE_LIBS system* library for using PCRE +PERL_CC system* compiler for Perl interface code +PERL_CCOPTS system* flags for same +PERL_COMMAND system path to Perl +PERL_LIBS system* library for compiling Perl interface +PID_FILE_PATH optional path to daemon's pid file +RADIUS_CONFIG_FILE optional path to Radius config file +RADIUS_LIB_TYPE optional type of RADIUS library +RANLIB system** path to ranlib command +RM_COMMAND system path to rm command +ROUTER_ACCEPT driver include accept router +ROUTER_DNSLOOKUP driver include dnslookup router +ROUTER_MANUALROUTE driver include manualroute router +ROUTER_IPLITERAL driver include ipliteral router +ROUTER_IPLOOKUP driver include iplookup router +ROUTER_REDIRECT driver include redirect router +ROUTER_QUERYPROGRAM driver include queryprogram router +SPOOL_DIRECTORY recommended path to spool directory +SPOOL_DIRECTORY_MODE optional mode of spool directory +SPOOL_MODE optional mode of spool files +STRING_SPRINTF_BUFFER_SIZE optional* buffer for string_sprintf() +STRIP_COMMAND optional* can be used to strp binaries +SUPPORT_A6 optional* support A6 DNS records +SUPPORT_CRYPTEQ optional support crypteq (if no auths) +SUPPORT_MAILDIR optional support for maildir delivery +SUPPORT_MAILSTORE optional support for mailstore delivery +SUPPORT_MBX optional support for MBX delivery +SUPPORT_MOVE_FROZEN_MESSAGES optional* support for frozen message moving +SUPPORT_PAM optional support for PAM authentication +SUPPORT_TLS optional support for TLS encryption over SMTP +SUPPORT_TRANSLATE_IP_ADDRESS optional* support for address translation +SYSLOG_LOG_PID optional add pid to syslog lines +SYSLOG_LONG_LINES optional do not split long syslog lines +SYSTEM_ALIASES_FILE optional defaults to /etc/aliases +TCP_WRAPPERS_DAEMON_NAME system* daemon name used by tcpwrappers library +TIMEZONE_DEFAULT optional default for timezone option +TLS_INCLUDE optional path to include files for TLS +TLS_LIBS optional additional libraries for TLS +EXIM_TMPDIR system value for TMPDIR environment variable +TRANSPORT_APPENDFILE driver include appendfile transport +TRANSPORT_AUTOREPLY driver include autoreply transport +TRANSPORT_LMTP driver include lmtp transport +TRANSPORT_PIPE driver include pipe transport +TRANSPORT_SMTP driver include smtp transport +TRUSTED_CONFIG_LIST optional config files safe to retain privileges +USE_DB system** use native DB interface +USE_GNUTLS optional use GnuTLS instead of OpenSSL +USE_GNUTLS_PC optional probably "gnutls" +USE_OPENSSL_PC optional probably "openssl" +USE_READLINE optional try to load libreadline for -be +USE_TCP_WRAPPERS system link with tcpwrappers +USE_TDB optional use the tdb DB interface +WHITELIST_D_MACROS optional -Dmacros safe to retain privileges with +WITH_OLD_CLAMAV_STREAM optional* use ClamAV API from before ClamAV 0.95 +X11 system** X11 base directory +X11_LD_LIB system** X11 link library +XINCLUDE system** X11 include directory +XLFLAGS system** X11 link time flags +ZCAT_COMMAND system path to zcat command + + +4. BUILD TIME OPTIONS FOR EXIMON +-------------------------------- + +The table below contains a complete list of options that can be set in +Local/eximon.conf when building the Exim monitor. Where the default is shown as +** it means that the text string is too long to fit in the table and is instead +given below. A blank default means that there is no default value. + +ACTION_OUTPUT=no show output for every action +ACTION_QUEUE_UPDATE=yes update queue display after actions +BODY_MAX=20000 maximum body display +DOMAIN= domain to strip from window title +LOG_BUFFER=20K buffer for log tail +LOG_DEPTH=300 depth of log subwindow +LOG_FONT=** font for log display +LOG_STRIPCHARTS=** patterns for stripcharts +LOG_WIDTH=950 width of log subwindow +MENU_EVENT='Shift<Btn1Down>' keypress for menu +MIN_HEIGHT=162 minimum window height +MIN_WIDTH=103 minimum window width +QUALIFY_DOMAIN= local domain to strip from addresses +QUEUE_DEPTH=200 depth of queue subwindow +QUEUE_FONT=$LOG_FONT font for queue display +QUEUE_INTERVAL=300 queue refresh interval +QUEUE_MAX_ADDRESSES=10 max addresses to show in queue +QUEUE_STRIPCHART_NAME=queue name for queue stripchart +QUEUE_WIDTH=950 width of queue subwindow +SIZE_STRIPCHART= request partition size stripchart +SIZE_STRIPCHART_NAME=space name for size stripchart +START_SMALL=no if yes, start with small window +STRIPCHART_INTERVAL=60 stripchart refresh interval +TEXT_DEPTH=200 depth of text windows +WINDOW_TITLE="${hostname} eximon" window title + +The default for LOG_FONT is + + LOG_FONT=-misc-fixed-medium-r-normal-*-14-140-*-*-*-*-iso8859-1 + +and the default for LOG_STRIPCHARTS is + + LOG_STRIPCHARTS='/ <= /in/ + / => /out/ + / => .+ R=local/local/ + / => .+ T=[^ ]*smtp/smtp/' + +That is, there are four stripcharts, named in, out, local, and smtp. The first +counts message arrivals, the second counts all deliveries, the third counts +deliveries where the router's name starts with "local", and the fourth counts +deliveries where the transport name contains "smtp". + +**** End of OptionLists **** diff --git a/doc/README b/doc/README new file mode 100644 index 0000000..a019ab8 --- /dev/null +++ b/doc/README @@ -0,0 +1,65 @@ +Exim Documentation +------------------ + +This directory should contain the following files: + + ChangeLog most recent log of all changes to Exim + NewStuff features that haven't made it to the manual yet, + and/or a list of newly-added functionality + OptionLists.txt lists of all Exim's options + README this document + README.SIEVE notes on the Sieve support + Exim3.upgrade information about upgrading from release 2.12 to 3.00 + Exim4.upgrade information about upgrading from release 3.33 to 4.00 + dbm.discuss.txt discussion of DBM libraries + filter.txt specification of filter file contents + spec.txt main specification of Exim + experimental-spec.txt specification of experimental features + + +PostScript +---------- + +The Exim specifications are also available in PostScript. This is not included +in the main distribution because not everyone wants it. Wherever you got this +distribution from should also have carried another file called +exim-postscript-<version>.tar.gz which contains the PostScript documentation. +When de-tarred it creates a directory called exim-postscript-<version> into +which it places the files doc/filter.ps and doc/spec.ps. + + +HTML +---- + +A conversion from the original sources into HTML is done to create the online +documentation at http://www.exim.org. This set of files is also available for +installation on other servers. Wherever you got this distribution from should +also have carried another file called exim-html-<version>.tar.gz which contains +the HTML documentation. When de-tarred it creates a directory called +exim-html-<version> into which it places a directory called doc/html containing +the set of HTML files. The kick off point is the traditional index.html. + + +PDF +--- + +The Exim specifications are available in Portable Document Format. Wherever you +got this distribution from should also have carried another file called +exim-pdf-<version>.tar.gz which contains the PDF documentation. When de-tarred +it creates a directory called exim-pdf-<version> into which it places the files +doc/filter.pdf and doc/spec.pdf. + + +TeXinfo +------- + +A version of the documentation that has been converted to TeXinfo format is +available in the distribution file exim-texinfo-<version>.gz. When de-tarred it +creates a directory called exim-texinfo-<version> into which it places the +files doc/filter.texinfo and doc/spec.texinfo. + +The conversion process is automatic, so the result isn't as nice as +hand-maintained TeXinfo files would be, and some information is lost; for +example, TeXinfo does not support the use of change bars. + +-- End -- diff --git a/doc/README.SIEVE b/doc/README.SIEVE new file mode 100644 index 0000000..d36998f --- /dev/null +++ b/doc/README.SIEVE @@ -0,0 +1,343 @@ + Notes on the Sieve implementation for Exim + +Exim Filter Versus Sieve Filter + +Exim supports two incompatible filters: The traditional Exim filter and +the Sieve filter. Since Sieve is a extensible language, it is important +to understand "Sieve" in this context as "the specific implementation +of Sieve for Exim". + +The Exim filter contains more features, such as variable expansion, and +better integration with the host environment, like external processes +and pipes. + +Sieve is a standard for interoperable filters, defined in RFC 5228, +with multiple implementations around. If interoperability is important, +then there is no way around it. + + +Exim Implementation + +The Exim Sieve implementation offers the core as defined by RFC 5228, +the "encoded-character" extension (RFC 5228), the "envelope" test (RFC +5228), the "fileinto" action (5228), the "copy" parameter (RFC 3894), the +"vacation" action (5230), the "notify" action (draft-ietf-sieve-notify-12) +with mailto URIs (draft-ietf-sieve-notify-mailto-05), the +"i;ascii-numeric" comparator (RFC 2244) and the subaddress parameter +(RFC 5233). + +The Sieve filter is integrated in Exim and works very similar to the +Exim filter: Sieve scripts are recognized by the first line containing +"# sieve filter". When using "keep" or "fileinto" to save a mail into a +folder, the resulting string is available as the variable $address_file +in the transport that stores it. The following routers and transport +show a typical use of Sieve: + +begin routers + +localuser_verify: + driver = accept + domains = +localdomains + local_part_suffix = "-*" + local_part_suffix_optional + check_local_user + require_files = $home/.forward + verify_only = true + +localuser_deliver: + driver = redirect + domains = +localdomains + local_part_suffix = "-*" + local_part_suffix_optional + sieve_subaddress = "${sg{$local_part_suffix}{^-}{}}" + sieve_useraddress = "$local_part" + check_local_user + require_files = $home/.forward + file = $home/.forward + check_ancestor + allow_filter + file_transport = localuser + reply_transport = vacation + sieve_vacation_directory = $home/mail/vacation + verify = false + +begin transports + +localuser: + driver = appendfile + file = ${if eq{$address_file}{inbox} \ + {/var/mail/$local_part} \ + {${if eq{${substr_0_1:$address_file}}{/} \ + {$address_file} \ + {$home/mail/$address_file} \ + }} \ + } + delivery_date_add + envelope_to_add + return_path_add + mode = 0600 + +vacation: + driver = autoreply + +Absolute files are stored where specified, relative files are stored +relative to $home/mail and "inbox" goes to the standard mailbox location. +To enable "vacation", sieve_vacation_directory is set to the directory +where vacation databases are held (don't put anything else in that +directory) and point reply_transport to an autoreply transport. +Setting the Sieve useraddress and subaddress allows to use the subaddress +extension. + + +RFC Compliance + +Exim requires the first line to be "# sieve filter". Of course the RFC +does not enforce that line. Don't expect examples to work without adding +it, though. + +RFC 5228 requires using CRLF to terminate the end of a line. +The rationale was that CRLF is universally used in network protocols +to mark the end of the line. This implementation does not embed Sieve +in a network protocol, but uses Sieve scripts as part of the Exim MTA. +Since all parts of Exim use \n as newline character, this implementation +does, too. You can change this by defining the macro RFC_EOL at compile +time to enforce CRLF being used. + +The folder specified by "fileinto" must not contain the character +sequence ".." to avoid security problems. RFC 5228 does not specify the +syntax of folders apart from keep being equivalent to fileinto "INBOX". +This implementation uses "inbox" instead. + +Sieve script errors currently cause that messages are silently filed into +"inbox". RFC 5228 requires that the user is notified of that condition. +This may be implemented in future by adding a header line to mails that +are filed into "inbox" due to an error in the filter. + +The automatic replies generated by "vacation" do not contain an updated +"references" header field. + + +Semantics Of Keep + +The keep command is equivalent to fileinto "inbox": It saves the +message and resets the implicit keep flag. It does not set the +implicit keep flag; there is no command to set it once it has +been reset. + + +Semantics Of Fileinto + +RFC 5228 does not specify if "fileinto" tries to create a mail folder, +in case it does not exist. This implementation allows to configure +that aspect using the appendfile transport options "create_directory", +"create_file" and "file_must_exist". See the appendfile transport in +the Exim specification for details. + + +Allof And Anyof Test + +RFC 5228 does not specify if these tests use shortcut/lazy evaluation. +Exim uses shortcut evaluation. + + +Action Reordering + +RFC 5228 does not specify if actions may be executed out of order. +Exim may execute them out of order, e.g. messages may be filed to +folders or forwarded in a different order than specified, because +those actions only setup delivery, but do not execute it themselves. + + +Sieve Syntax And Semantics + +RFC 5228 uses a generic grammar as syntax for commands and tests and +performs many checks during semantic analysis. Syntax is specified +by grammar rules, semantics by natural language. The intention is to +provide a framework for the syntax that describes current commands as +well as future extensions, and describing commands by semantics. + +The following replacement for section 8.2 gives a grammar for specific +commands of this implementation, thus removing most of the semantic +analysis. Since the parser can not parse unsupported extensions, the +result is strict error checking of any executed and not executed code +until "stop" is executed or the end of the script is reached. + +8.2. Grammar + +The grammar is specified in ABNF with two extensions to describe tagged +arguments that can be reordered and grammar extensions: { } denotes a +sequence of symbols that may appear in any order. Example: + + options = a b c + start = { options } + +is equivalent to: + + start = ( a b c ) / ( a c b ) / ( b a c ) / ( b c a ) / ( c a b ) / ( c b a ) + +The symbol =) is used to append to a rule: + + start = a + start =) b + +is equivalent to + + start = a b + +The basic Sieve commands are specified using the following grammar, which +language is a subset of the generic grammar above. The start symbol is +"start". + + address-part = ":localpart" / ":domain" / ":all" + comparator = ":comparator" string + match-type = ":is" / ":contains" / ":matches" + string = quoted-string / multi-line + string-list = "[" string *("," string) "]" / string + address-test = "address" { [address-part] [comparator] [match-type] } + string-list string-list + test-list = "(" test *("," test) ")" + allof-test = "allof" test-list + anyof-test = "anyof" test-list + exists-test = "exists" string-list + false-test = "false" + true=test = "true" + header-test = "header" { [comparator] [match-type] } + string-list string-list + not-test = "not" test + relop = ":over" / ":under" + size-test = "size" relop number + block = "{" commands "}" + if-command = "if" test block *( "elsif" test block ) [ "else" block ] + stop-command = "stop" { stop-options } ";" + stop-options = + keep-command = "keep" { keep-options } ";" + keep-options = + discard-command = "discard" { discard-options } ";" + discard-options = + redirect-command = "redirect" { redirect-options } string ";" + redirect-options = + require-command = "require" { require-options } string-list ";" + require-options = + test = address-test / allof-test / anyof-test / exists-test + / false-test / true-test / header-test / not-test + / size-test + command = if-command / stop-command / keep-command + / discard-command / redirect-command + commands = *command + start = *require-command commands + +The extensions "envelope" and "fileinto" are specified using the following +grammar extension. + + envelope-test = "envelope" { [comparator] [address-part] [match-type] } + string-list string-list + test =/ envelope-test + + fileinto-command = "fileinto" { fileinto-options } string ";" + fileinto-options = + command =/ fileinto-command + +The extension "copy" is specified as: + + fileinto-options =) ":copy" + redirect-options =) ":copy" + + +The i;ascii-numeric Comparator + +RFC 2244 describes this comparator and specifies that non-numeric strings +are considered equal with an ordinal value higher than any numeric string. +Although not stated explicitly, this includes the empty string. A range +of at least 2^31 is required. This implementation does not limit the +range, because it does not convert numbers to binary representation +before comparing them. + + +The vacation extension + +The extension "vacation" is specified using the following grammar +extension. + + vacation-command = "vacation" { vacation-options } <reason: string> + vacation-options = [":days" number] + [":subject" string] + [":from" string] + [":addresses" string-list] + [":mime"] + [":handle" string] + command =/ vacation-command + + +Semantics Of ":mime" + +The draft does not specify how strings using MIME entities are used +to compose messages. As a result, different implementations generate +different mails. The Exim Sieve implementation splits the reason into +header and body. It adds the header to the mail header and uses the body +as mail body. Be aware, that other implementations compose a multipart +structure with the reason as only part. Both conform to the specification +(or lack thereof). + + +Semantics Of Not Using ":mime" + +Sieve scripts are written in UTF-8, so is the reason string in this +case. This implementation adds MIME headers to indicate that. This +is not required by the vacation draft, which does not specify how +the UTF-8 reason is processed to compose the resulting message. + + +Default Subject + +RFC 5230 specifies that the default message subject is "Auto: " plus +the old subject. Using this subject is dangerous, because many mailing +lists verify addresses by sending a secret key in the subject of a +message, asking to reply to the message for confirmation. Using the +default vacation subject confirms any subscription request of this kind, +allowing to subscribe a third party to any mailing list, either to annoy +the user or to declare spam as legitimate mail by proving to use opt-in. + + +Rate Limiting Responses + +In absence of a handle, this implementation hashes the reason, +":subject" option, ":mime" option and ":from" option and uses the hex +string representation as filename within the "sieve_vacation_directory" +to store the recipient addresses for this vacation parameter set. + +The draft specifies that sites may define a minimum ":days" value than 1. +This implementation uses 1. The maximum value MUST greater than 7, +and SHOULD be greater than 30. This implementation uses a maximum of 31. + +Vacation recipient address databases older than 31 days are automatically +removed. Users do not have to remove them manually when modifying their +scripts. Don't put anything but vacation databases in that directory +or you risk that it will be removed, too! + + +Global Reply Address Blacklist + +The draft requires that each implementation offers a global black list +of addresses that will never be replied to. Exim offers this as option +"never_mail" in the autoreply transport. + + +The enotify extension + +The extension "enotify" is specified using the following grammar +extension. + + notify-command = "notify" { notify-options } <method: string> + notify-options = [":from" string] + [":importance" <"1" / "2" / "3">] + [":options" 1*(string-list / number)] + [":message" string] + + command =/ notify-command + + valid_notify_method = "valid_notify_method" + <notification-uris: string-list> + + test =/ valid_notify_method + +Only the mailto URI scheme is implemented. diff --git a/doc/cve-2016-9663 b/doc/cve-2016-9663 new file mode 100644 index 0000000..ffff3db --- /dev/null +++ b/doc/cve-2016-9663 @@ -0,0 +1,95 @@ +CVE ID: CVE-2016-9963 +Date: 2016-12-15 +Credits: Bjoern Jacke <bjoern@j3e.de> +Version(s): 4.69 -> 4.87 +Issue: If several conditions are met, Exim leaks private information + to a remote attacker. + +Conditions +========== + +If *all* of the following conditions are met + + Build options + ------------- + + * Exim is built with DKIM enabled (default for newer versions) + exim -bV | grep 'Support.*DKIM' + + Runtime options + --------------- + + * Exim uses DKIM signing (transport options dkim_private_key, + dkim_domain, and other) + + * The dkim_private_key option names a file containing the key. + + exim -bP transports | grep 'dkim_private_key = .' + + * Exim uses PRDR (transport option hosts_try_prdr) (default + since 4.86) + + exim -bP transports | grep 'hosts_try_prdr = .' + + *OR* + + Exim uses the LMTP protocol variant for SMTP transport. + + exim -bP transports | grep 'protocol = lmtp' + + Operation + --------- + + * Exim transports a multi-recipient message + + * The destination host supports PRDR + OR + the message transport uses LMTP + + * One or more recipients are rejected after the DATA phase + +Impact +====== + +Exim leaks the private DKIM signing key to the log files. Additionally, +if the build option EXPERIMENTAL_DSN_INFO=yes is used, the key material +is included in the bounce message. + +Fix +=== + +Install a fixed Exim version: + + 4.88 + 4.87.1 + +If you can't install one of the above versions, ask your package +maintainer for a version containing the backported fix. On request and +depending on our resources we will support you in backporting the fix. +(Please note, that Exim project officially doesn't support versions +prior the current stable version.) + +If you think that you MIGHT be affected, we HIGHLY recommend to create +a new set of DKIM keys and fade out the previous DKIM key soon to make +sure that a possibly leaked DKIM key can not be misused in the future. + + +Workaround +========== + +Disable PRDR in your outgoing transport(s): set hosts_try_prdr to an +empty string. + +AND do not use the LMTP protocol variant of the SMTP driver. + +Indication +========== + +You can check if you where affected already. The mainlog entries look like this: + +2016-12-17 09:44:33 10HmaX-0005vi-00 ** baduser@test.ex R=client T=send_to_server H=ip4.ip4.ip4.ip4 [ip4.ip4.ip4.ip4]: PRDR error after -----BEGIN RSA PRIVATE KEY-----\nMIICXQIBAAKBgQDXRFf+VhT+lCgFhhSkinZKcFNeRzjYdW8vT29Rbb3NadvTFwAd\n+cVLPFwZL8H5tUD/7JbUPqNTCPxmpgIL+V5T4tEZMorHatvvUM2qfcpQ45IfsZ+Y\ndhbIiAslHCpy4xNxIR3zylgqRUF4+Dtsaqy3a5LhwMiKCLrnzhXk1F1hxwIDAQAB\nAoGAZPokJKQQmRK6a0zn5f8lWemy0airG66KhzDF0Pafb/nWKgDCB02gpJgdw5rJ\nbO7/HI3IeqsfRdYTP7tjfmZtPiPo1mnF7D1rSRspZjOF2yXY/ky7t7c5xChRcSxf\n+69CknwjrfteY9Aj0j6o7N+2w2uvHO+AAq8BHDgXKmPo0SECQQDzQ/glyhNH9tlO\nx+3TTMwwyZUf2mYYosN3Q9NIl3Umz/3+13K5b6Ed6fZvS/XwU55Qf5IBUVj2Fujk\nRv2lbGPpAkEA4okpnzYz5nm1X5WjpJPQPyo8nGEU1A5QfoDbkAvWYvVoYrpWPOx5\nHFpOAHkvSk1Y1vhCUa+zHwiQRBC8OMp6LwJBAOAUK/AjQ792UpWO9DM++pe2F/dP\nZdwrkYG6qFSlrvQhgwXLz5GgkfjMGoRKpDDL1XixCfzMwfVtBPnBqsNGJIECQGYX\nSIGu7L7edMXJ60C9OKluwHf9LGTQuqf4LHsDSq+4Rz3PGhREwePsMqD1/EDxEKt4\noHKtyvyeYF28aQbzARMCQQCRtJlR6vlKhxYL8+xoPrCu3MijKgVruRUcNstXkDZK\nfKQax6vhiMq+0qIiEwLA1wavyLVKZ7Mfag+/4NTcDUVC\n-----END RSA PRIVATE KEY-----\n: 550 PRDR R=<baduser@test.ex> refusal + +Even if there is no evidence in the existing log files, that a DKIM key +leakage happened this might have happened in the past, log files might +have been deleted already but a key leak could have ended up via mail +bounce in a user mail box diff --git a/doc/dbm.discuss.txt b/doc/dbm.discuss.txt new file mode 100644 index 0000000..7df044e --- /dev/null +++ b/doc/dbm.discuss.txt @@ -0,0 +1,320 @@ +DBM Libraries for use with Exim +------------------------------- + +Background +---------- + +Exim uses direct-access (so-called "dbm") files for a number of different +purposes. These are files arranged so that the data they contain is indexed and +can quickly be looked up by quoting an appropriate key. They are used as +follows: + +1. Exim keeps its "hints" databases in dbm files. + +2. The configuration can specify that certain things (e.g. aliases) be looked + up in dbm files. + +3. The configuration can contain expansion strings that involve lookups in dbm + files. + +4. The filter commands "mail" and "vacation" have a facility for replying only + once to each incoming address. The record of which addresses have already + received replies may be kept in a dbm file, depending on the configuration + option once_file_size. + +The runtime configuration can be set up without specifying 2 or 3, but Exim +always requires the availability of a dbm library, for 1 (and 4 if configured +that way). + + +DBM Libraries +------------- + +The original library that provided the dbm facility in Unix was called "dbm". +This seems to have been superseded quite some time ago by a new version called +"ndbm" which permits several dbm files to be open at once. Several operating +systems, including those from Sun, contain ndbm as standard. + +A number of alternative libraries also exist, the most common of which seems to +be Berkeley DB (just called DB hereinafter). Release 1.85 was around for +some time, and various releases 2.x began to appear towards the end of 1997. In +November 1999, version 3.0 was released, and the ending of support for 2.7.7, +the last 2.x release, was announced for November 2000. (Support for 1.85 has +already ceased.) There were further 3.x releases, but by the end of 2001, the +current release was 4.0.14. + +There are major differences in implementation and interface between the DB 1.x +and 2.x/3.x/4.x releases, and they are best considered as two independent dbm +libraries. Changes to the API were made for 3.0 and again for 3.1. + +Another DBM library is the GNU library, gdbm, though this does not seem to be +very widespread. + +Yet another dbm library is tdb (Trivial Data Base) which has come out of the +Samba project. The first releases seem to have been in mid-2000. + +Some older Linux releases contain gdbm as standard, while others contain no dbm +library. More recent releases contain DB 1.85 or 2.x or later, and presumably +will track the development of the DB library. Some BSD versions of Unix include +DB 1.85 or later. All of the non-ndbm libraries except tdb contain +compatibility interfaces so that programs written to call the ndbm functions +should, in theory, work with them, but there are some potential pitfalls which +have caught out Exim users in the past. + +Exim has been tested with ndbm, gdbm, DB 1.85, DB 2.x, DB 3.1, DB 4.0.14, and +tdb 1.0.2, in various different modes in some cases, and is believed to work +with all of them if it and they are properly configured. + +I have considered the possibility of calling different dbm libraries for +different functions from a single Exim binary. However, because all bar one of +the libraries provide ndbm compatibility interfaces (and therefore the same +function names) it would require a lot of complicated, error-prone trickery to +achieve this. Exim therefore uses a single library for all its dbm activities. + +However, Exim does also support cdb (Constant Data Base), an efficient file +arrangement for indexed data that does not change incrementally (for example, +alias files). This is independent of any dbm library and can be used alongside +any of them. + + +Locking +------- + +The configuration option EXIMDB_LOCK_TIMEOUT controls how long Exim waits to +get a lock on a hints database. From version 1.80 onwards, Exim does not +attempt to take out a lock on an actual database file (this caused problems in +the past). Instead, it takes out an fcntl() lock on a separate file whose name +ends in ".lockfile". This ensures that Exim has exclusive access to the +database before even attempting to open it. Exim creates the lock file the +first time it needs it. It should never be removed. + + +Main Pitfall +------------ + +The OS-specific configuration files that are used to build Exim specify the use +of Berkeley DB on those systems where it is known to be standard. In the +absence of any special configuration options, Exim uses the ndbm set of +functions to control its dbm databases. This should work with any of the dbm +libraries because those that are not ndbm have compatibility interfaces. +However, there is one awful pitfall: + +Exim #includes a header file called ndbm.h which defines the functions and the +interface data block; gdbm and DB 1.x provide their own versions of this header +file, later DB versions do not. If it should happen that the wrong version of +nbdm.h is seen by Exim, it may compile without error, but fail to operate +correctly at runtime. + +This situation can easily arise when more than one dbm library is installed on +a single host. For example, if you decide to use DB 1.x on a system where gdbm +is the standard library, unless you are careful in setting up the include +directories for Exim, it may see gdbm's ndbm.h file instead of DB's. The +situation is even worse with later versions of DB, which do not provide an +ndbm.h file at all. + +One way out of this for gdbm and any of the versions of DB is to configure Exim +to call the DBM library in its native mode instead of via the ndbm +compatibility interface, thus avoiding the use of ndbm.h. This is done by +setting the USE_DB configuration option if you are using Berkeley DB, or +USE_GDBM if you are using gdbm. This is the recommended approach. + + +NDBM +---- + +The ndbm library holds its data in two files, with extensions .dir and .pag. +This makes atomic updating of, for example, alias files, difficult, because +simple renaming cannot be used without some risk. However, if your system has +ndbm installed, Exim should compile and run without any problems. + + +GDBM +---- + +The gdbm library, when called via the ndbm compatibility interface, makes two +hard links to a single file, with extensions .dir and .pag. As mentioned above, +gdbm provides its own version of the ndbm.h header, and you must ensure that +this is seen by Exim rather than any other version. This is not likely to be a +problem if gdbm is the only dbm library on your system. + +If gdbm is called via the native interface (by setting USE_GDBM in your +Local/Makefile), it uses a single file, with no extension on the name, and the +ndbm.h header is not required. + +The gdbm library does its own locking of the single file that it uses. From +version 1.80 onwards, Exim locks on an entirely separate file before accessing +a hints database, so gdbm's locking should always succeed. + + +Berkeley DB 1.8x +---------------- + +1.85 was the most widespread DB 1.x release; there is also a 1.86 bug-fix +release, but the belief is that the bugs it fixes will not affect Exim. +However, maintenance for 1.x releases has been phased out. + +This dbm library can be called by Exim in one of two ways: via the ndbm +compatibility interface, or via its own native interface. There are two +advantages to doing the latter: (1) you don't run the risk of Exim's seeing the +"wrong" version of the ndbm.h header, as described above, and (2) the +performance is better. It is therefore recommended that you set USE_DB=yes in an +appropriate Local/Makefile-xxx file. (If you are compiling for just one OS, it +can go in Local/Makefile itself.) + +When called via the compatibility interface, DB 1.x creates a single file with +a .db extension. When called via its native interface, no extension is added to +the file name handed to it. + +DB 1.x does not do any locking of its own. + + +Berkeley DB 2.x +--------------- + +DB 2.x was released in 1997. It is a major re-implementation and its native +interface is incompatible with DB 1.x, though a compatibility interface was +introduced in DB 2.1.0, and there is also an ndbm.h compatibility interface. + +Like 1.x, it can be called from Exim via the ndbm compatibility interface or +via its native interface, and once again setting USE_DB in order to get the +native interface is recommended. If USE_DB is *not* set, then you will have to +provide a suitable version of ndbm.h, because one does not come with the DB 2.x +distribution. A suitable version is: + + /************************************************* + * ndbm.h header for DB 2.x * + *************************************************/ + + /* This header should replace any other version of ndbm.h when Berkeley DB + version 2.x is in use via the ndbm compatibility interface. Otherwise, any + extant version of ndbm.h may cause programs to misbehave. There doesn't seem + to be a version of ndbm.h supplied with DB 2.x, so I made this for myself. + + Philip Hazel 12/Jun/97 + */ + + #define DB_DBM_HSEARCH + #include <db.h> + + /* End */ + +When called via the compatibility interface, DB 2.x creates a single file with +a .db extension. When called via its native interface, no extension is added to +the file name handed to it. + +DB 2.x does not do any automatic locking of its own; it does have a set of +functions for various forms of locking, but Exim does not use them. + + +Berkeley DB 3.x +--------------- + +DB 3.0 was released in November 1999 and 3.1 in June 2000. The 3.x series is a +development of the 2.x series and the above comments apply. Exim can +automatically distinguish between the different versions, so it copes with the +changes to the API without needing any special configuration. + +When Exim creates a DBM file using DB 3.x (e.g. when creating one of its hints +databases), it specified the "hash" format. However, when it opens a DB 3 file +for reading only, it specifies "unknown". This means that it can read DB 3 +files in other formats that are created by other programs. + + +Berkeley DB 4.x +--------------- + +The 4.x series is a development of the 2.x and 3.x series, and the above +comments apply. + + +tdb +--- + +tdb 1.0.2 was released in September 2000. Its origin is the database functions +that are used by the Samba project. + + + +Testing Exim's dbm handling +--------------------------- + +Because there have been problems with dbm file locking in the past, I built +some testing code for Exim's dbm functions. This is very much a lash-up, but it +is documented here so that anybody who wants to check that their configuration +is locking properly can do so. Now that Exim does the locking on an entirely +separate file, locking problems are much less likely, but this code still +exists, just in case. Proceed as follows: + +. Build Exim in the normal way. This ensures that all the makesfiles etc. get + set up. + +. From within the build directory, obey "make test_dbfn". This makes a binary + file called test_dbfn. If you are experimenting with different configurations + you *must* do "make makefile" after changing anything, before obeying "make + test_dbfn" again, because the make target for test_dbfn isn't integrated + with the making of the makefile. + +. Identify a scratch directory where you have write access. Create a sub- + directory called "db" in the scratch directory. + +. Type the command "test_dbfn <scratch-directory>". This will output some + general information such as + + Exim's db functions tester: interface type is db (v2) + DBM library: Berkeley DB: Sleepycat Software: DB 2.1.0: (6/13/97) + USE_DB is defined + + It then says + + Test the functions + > + +. At this point you can type commands to open a dbm file and read and write + data in it. First type the command "open <name>", e.g. "open junk". The + response should look like this + + opened DB file <scratch-directory>/db/junk: flags=102 + Locked + opened 0 + > + + The tester will have created a dbm file within the db directory of the + scratch directory. It will also have created a file with the extension + ".lockfile" in the same directory. Unlike Exim itself, it will not create + the db directory for itself if it does not exist. + +. To test the locking, don't type anything more for the moment. You now need to + set up another process running the same test_dbfn command, e.g. from a + different logon to the same host. This time, when you attempt to open the + file it should fail after a minute with a timeout error because it is + already in use. + +. If the second process doesn't produce any error message, but gets back to the + > prompt, then the locking is not working properly. + +. You can check that the second process gets the lock when the first process + releases it by exiting from the first process with ^D, q, or quit; or by + typing the command "close". + +. There are some other commands available that are not related to locking: + + write <key> <data> + e.g. + write abcde the quick brown fox + + writes a record to the database, + + read <key> + delete <key> + + read and delete a record, respectively, and + + scan + + scans the entire database. Note that the database is purely for testing the + dbm functions. It is *not* one of Exim's regular databases, and you should + not try running this testing program on any of Exim's real database + files. + +Philip Hazel +Last update: June 2002 diff --git a/doc/exim.8 b/doc/exim.8 new file mode 100644 index 0000000..566fe23 --- /dev/null +++ b/doc/exim.8 @@ -0,0 +1,1709 @@ +.TH EXIM 8 +.SH NAME +exim \- a Mail Transfer Agent +.SH SYNOPSIS +.nf +.B exim [options] arguments ... +.B mailq [options] arguments ... +.B rsmtp [options] arguments ... +.B rmail [options] arguments ... +.B runq [options] arguments ... +.B newaliases [options] arguments ... +.fi +. +.SH DESCRIPTION +.rs +.sp +Exim is a mail transfer agent (MTA) developed at the University of Cambridge. +It is a large program with very many facilities. For a full specification, see +the reference manual. This man page contains only a description of the command +line options. It has been automatically generated from the reference manual +source, hopefully without too much mangling. +.P +Like other MTAs, Exim replaces Sendmail, and is normally called by user agents +(MUAs) using the path \fI/usr/sbin/sendmail\fP when they submit messages for +delivery (some operating systems use \fI/usr/lib/sendmail\fP). This path is +normally set up as a symbolic link to the Exim binary. It may also be used by +boot scripts to start the Exim daemon. Many of Exim's command line options are +compatible with Sendmail so that it can act as a drop-in replacement. +. +.SH "DEFAULT ACTION" +.rs +.sp +If no options are present that require a specific action (such as starting the +daemon or a queue runner, testing an address, receiving a message in a specific +format, or listing the queue), and there are no arguments on the command line, +Exim outputs a brief message about itself and exits. +.sp +However, if there is at least one command line argument, \fB-bm\fR (accept a +local message on the standard input, with the arguments specifying the +recipients) is assumed. Thus, for example, if Exim is installed in +\fI/usr/sbin\fP, you can send a message from the command line like this: +.sp + /usr/sbin/exim -i <recipient-address(es)> + <message content, including all the header lines> + CTRL-D +.sp +The \fB-i\fP option prevents a line containing just a dot from terminating +the message. Only an end-of-file (generated by typing CTRL-D if the input is +from a terminal) does so. +. +.SH "SETTING OPTIONS BY PROGRAM NAME" +.rs +.sp +If an Exim binary is called using one of the names listed in this section +(typically via a symbolic link), certain options are assumed. +.TP +\fBmailq\fR +Behave as if the option \fB\-bp\fP were present before any other options. +The \fB\-bp\fP option requests a listing of the contents of the mail queue +on the standard output. +.TP +\fBrsmtp\fR +Behaves as if the option \fB\-bS\fP were present before any other options, +for compatibility with Smail. The \fB\-bS\fP option is used for reading in a +number of messages in batched SMTP format. +.TP +\fBrmail\fR +Behave as if the \fB\-i\fP and \fB\-oee\fP options were present before +any other options, for compatibility with Smail. The name \fBrmail\fR is used +as an interface by some UUCP systems. The \fB\-i\fP option specifies that a +dot on a line by itself does not terminate a non\-SMTP message; \fB\-oee\fP +requests that errors detected in non\-SMTP messages be reported by emailing +the sender. +.TP +\fBrunq\fR +Behave as if the option \fB\-q\fP were present before any other options, for +compatibility with Smail. The \fB\-q\fP option causes a single queue runner +process to be started. It processes the queue once, then exits. +.TP +\fBnewaliases\fR +Behave as if the option \fB\-bi\fP were present before any other options, +for compatibility with Sendmail. This option is used for rebuilding Sendmail's +alias file. Exim does not have the concept of a single alias file, but can be +configured to run a specified command if called with the \fB\-bi\fP option. +. +.SH "OPTIONS" +.rs +.TP 10 +\fB\-\-\fP +This is a pseudo\-option whose only purpose is to terminate the options and +therefore to cause subsequent command line items to be treated as arguments +rather than options, even if they begin with hyphens. +.TP 10 +\fB\-\-help\fP +This option causes Exim to output a few sentences stating what it is. +The same output is generated if the Exim binary is called with no options and +no arguments. +.TP 10 +\fB\-\-version\fP +This option is an alias for \fB\-bV\fP and causes version information to be +displayed. +.TP 10 +\fB\-Ac\fP +\fB\-Am\fP +These options are used by Sendmail for selecting configuration files and are +ignored by Exim. +.TP 10 +\fB\-B\fP<\fItype\fP> +This is a Sendmail option for selecting 7 or 8 bit processing. Exim is 8\-bit +clean; it ignores this option. +.TP 10 +\fB\-bd\fP +This option runs Exim as a daemon, awaiting incoming SMTP connections. Usually +the \fB\-bd\fP option is combined with the \fB\-q\fP<\fItime\fP> option, to specify +that the daemon should also initiate periodic queue runs. +.sp +The \fB\-bd\fP option can be used only by an admin user. If either of the \fB\-d\fP +(debugging) or \fB\-v\fP (verifying) options are set, the daemon does not +disconnect from the controlling terminal. When running this way, it can be +stopped by pressing ctrl\-C. +.sp +By default, Exim listens for incoming connections to the standard SMTP port on +all the host's running interfaces. However, it is possible to listen on other +ports, on multiple ports, and only on specific interfaces. +.sp +When a listening daemon +is started without the use of \fB\-oX\fP (that is, without overriding the normal +configuration), it writes its process id to a file called exim\-daemon.pid +in Exim's spool directory. This location can be overridden by setting +PID_FILE_PATH in Local/Makefile. The file is written while Exim is still +running as root. +.sp +When \fB\-oX\fP is used on the command line to start a listening daemon, the +process id is not written to the normal pid file path. However, \fB\-oP\fP can be +used to specify a path on the command line if a pid file is required. +.sp +The SIGHUP signal +can be used to cause the daemon to re\-execute itself. This should be done +whenever Exim's configuration file, or any file that is incorporated into it by +means of the \fB.include\fP facility, is changed, and also whenever a new version +of Exim is installed. It is not necessary to do this when other files that are +referenced from the configuration (for example, alias files) are changed, +because these are reread each time they are used. +.TP 10 +\fB\-bdf\fP +This option has the same effect as \fB\-bd\fP except that it never disconnects +from the controlling terminal, even when no debugging is specified. +.TP 10 +\fB\-be\fP +Run Exim in expansion testing mode. Exim discards its root privilege, to +prevent ordinary users from using this mode to read otherwise inaccessible +files. If no arguments are given, Exim runs interactively, prompting for lines +of data. Otherwise, it processes each argument in turn. +.sp +If Exim was built with USE_READLINE=yes in Local/Makefile, it tries +to load the \fBlibreadline\fP library dynamically whenever the \fB\-be\fP option is +used without command line arguments. If successful, it uses the readline() +function, which provides extensive line\-editing facilities, for reading the +test data. A line history is supported. +.sp +Long expansion expressions can be split over several lines by using backslash +continuations. As in Exim's runtime configuration, white space at the start of +continuation lines is ignored. Each argument or data line is passed through the +string expansion mechanism, and the result is output. Variable values from the +configuration file (for example, \fI$qualify_domain\fP) are available, but no +message\-specific values (such as \fI$message_exim_id\fP) are set, because no message +is being processed (but see \fB\-bem\fP and \fB\-Mset\fP). +.sp +\fBNote\fP: If you use this mechanism to test lookups, and you change the data +files or databases you are using, you must exit and restart Exim before trying +the same lookup again. Otherwise, because each Exim process caches the results +of lookups, you will just get the same result as before. +.sp +Macro processing is done on lines before string\-expansion: new macros can be +defined and macros will be expanded. +Because macros in the config file are often used for secrets, those are only +available to admin users. +.TP 10 +\fB\-bem\fP <\fIfilename\fP> +This option operates like \fB\-be\fP except that it must be followed by the name +of a file. For example: +.sp + exim \-bem /tmp/testmessage +.sp +The file is read as a message (as if receiving a locally\-submitted non\-SMTP +message) before any of the test expansions are done. Thus, message\-specific +variables such as \fI$message_size\fP and \fI$header_from:\fP are available. However, +no \fIReceived:\fP header is added to the message. If the \fB\-t\fP option is set, +recipients are read from the headers in the normal way, and are shown in the +\fI$recipients\fP variable. Note that recipients cannot be given on the command +line, because further arguments are taken as strings to expand (just like +\fB\-be\fP). +.TP 10 +\fB\-bF\fP <\fIfilename\fP> +This option is the same as \fB\-bf\fP except that it assumes that the filter being +tested is a system filter. The additional commands that are available only in +system filters are recognized. +.TP 10 +\fB\-bf\fP <\fIfilename\fP> +This option runs Exim in user filter testing mode; the file is the filter file +to be tested, and a test message must be supplied on the standard input. If +there are no message\-dependent tests in the filter, an empty file can be +supplied. +.sp +If you want to test a system filter file, use \fB\-bF\fP instead of \fB\-bf\fP. You +can use both \fB\-bF\fP and \fB\-bf\fP on the same command, in order to test a system +filter and a user filter in the same run. For example: +.sp + exim \-bF /system/filter \-bf /user/filter </test/message +.sp +This is helpful when the system filter adds header lines or sets filter +variables that are used by the user filter. +.sp +If the test filter file does not begin with one of the special lines +.sp + # Exim filter + # Sieve filter +.sp +it is taken to be a normal .forward file, and is tested for validity under +that interpretation. +.sp +The result of an Exim command that uses \fB\-bf\fP, provided no errors are +detected, is a list of the actions that Exim would try to take if presented +with the message for real. More details of filter testing are given in the +separate document entitled \fIExim's interfaces to mail filtering\fP. +.sp +When testing a filter file, +the envelope sender can be set by the \fB\-f\fP option, +or by a "From " line at the start of the test message. Various parameters +that would normally be taken from the envelope recipient address of the message +can be set by means of additional command line options (see the next four +options). +.TP 10 +\fB\-bfd\fP <\fIdomain\fP> +This sets the domain of the recipient address when a filter file is being +tested by means of the \fB\-bf\fP option. The default is the value of +\fI$qualify_domain\fP. +.TP 10 +\fB\-bfl\fP <\fIlocal part\fP> +This sets the local part of the recipient address when a filter file is being +tested by means of the \fB\-bf\fP option. The default is the username of the +process that calls Exim. A local part should be specified with any prefix or +suffix stripped, because that is how it appears to the filter when a message is +actually being delivered. +.TP 10 +\fB\-bfp\fP <\fIprefix\fP> +This sets the prefix of the local part of the recipient address when a filter +file is being tested by means of the \fB\-bf\fP option. The default is an empty +prefix. +.TP 10 +\fB\-bfs\fP <\fIsuffix\fP> +This sets the suffix of the local part of the recipient address when a filter +file is being tested by means of the \fB\-bf\fP option. The default is an empty +suffix. +.TP 10 +\fB\-bh\fP <\fIIP address\fP> +This option runs a fake SMTP session as if from the given IP address, using the +standard input and output. The IP address may include a port number at the end, +after a full stop. For example: +.sp + exim \-bh 10.9.8.7.1234 + exim \-bh fe80::a00:20ff:fe86:a061.5678 +.sp +When an IPv6 address is given, it is converted into canonical form. In the case +of the second example above, the value of \fI$sender_host_address\fP after +conversion to the canonical form is +fe80:0000:0000:0a00:20ff:fe86:a061.5678. +.sp +Comments as to what is going on are written to the standard error file. These +include lines beginning with "LOG" for anything that would have been logged. +This facility is provided for testing configuration options for incoming +messages, to make sure they implement the required policy. For example, you can +test your relay controls using \fB\-bh\fP. +.sp +\fBWarning 1\fP: +You can test features of the configuration that rely on ident (RFC 1413) +information by using the \fB\-oMt\fP option. However, Exim cannot actually perform +an ident callout when testing using \fB\-bh\fP because there is no incoming SMTP +connection. +.sp +\fBWarning 2\fP: Address verification callouts +are also skipped when testing using \fB\-bh\fP. If you want these callouts to +occur, use \fB\-bhc\fP instead. +.sp +Messages supplied during the testing session are discarded, and nothing is +written to any of the real log files. There may be pauses when DNS (and other) +lookups are taking place, and of course these may time out. The \fB\-oMi\fP option +can be used to specify a specific IP interface and port if this is important, +and \fB\-oMaa\fP and \fB\-oMai\fP can be used to set parameters as if the SMTP +session were authenticated. +.sp +The \fIexim_checkaccess\fP utility is a "packaged" version of \fB\-bh\fP whose +output just states whether a given recipient address from a given host is +acceptable or not. +.sp +Features such as authentication and encryption, where the client input is not +plain text, cannot easily be tested with \fB\-bh\fP. Instead, you should use a +specialized SMTP test program such as +\fBswaks\fP. +.TP 10 +\fB\-bhc\fP <\fIIP address\fP> +This option operates in the same way as \fB\-bh\fP, except that address +verification callouts are performed if required. This includes consulting and +updating the callout cache database. +.TP 10 +\fB\-bi\fP +Sendmail interprets the \fB\-bi\fP option as a request to rebuild its alias file. +Exim does not have the concept of a single alias file, and so it cannot mimic +this behaviour. However, calls to /usr/lib/sendmail with the \fB\-bi\fP option +tend to appear in various scripts such as NIS make files, so the option must be +recognized. +.sp +If \fB\-bi\fP is encountered, the command specified by the \fBbi_command\fP +configuration option is run, under the uid and gid of the caller of Exim. If +the \fB\-oA\fP option is used, its value is passed to the command as an argument. +The command set by \fBbi_command\fP may not contain arguments. The command can +use the \fIexim_dbmbuild\fP utility, or some other means, to rebuild alias files +if this is required. If the \fBbi_command\fP option is not set, calling Exim with +\fB\-bi\fP is a no\-op. +.TP 10 +\fB\-bI:help\fP +We shall provide various options starting \-bI: for querying Exim for +information. The output of many of these will be intended for machine +consumption. This one is not. The \fB\-bI:help\fP option asks Exim for a +synopsis of supported options beginning \-bI:. Use of any of these +options shall cause Exim to exit after producing the requested output. +.TP 10 +\fB\-bI:dscp\fP +This option causes Exim to emit an alphabetically sorted list of all +recognised DSCP names. +.TP 10 +\fB\-bI:sieve\fP +This option causes Exim to emit an alphabetically sorted list of all supported +Sieve protocol extensions on stdout, one per line. This is anticipated to be +useful for ManageSieve (RFC 5804) implementations, in providing that protocol's +SIEVE capability response line. As the precise list may depend upon +compile\-time build options, which this option will adapt to, this is the only +way to guarantee a correct response. +.TP 10 +\fB\-bm\fP +This option runs an Exim receiving process that accepts an incoming, +locally\-generated message on the standard input. The recipients are given as the +command arguments (except when \fB\-t\fP is also present \- see below). Each +argument can be a comma\-separated list of RFC 2822 addresses. This is the +default option for selecting the overall action of an Exim call; it is assumed +if no other conflicting option is present. +.sp +If any addresses in the message are unqualified (have no domain), they are +qualified by the values of the \fBqualify_domain\fP or \fBqualify_recipient\fP +options, as appropriate. The \fB\-bnq\fP option (see below) provides a way of +suppressing this for special cases. +.sp +Policy checks on the contents of local messages can be enforced by means of +the non\-SMTP ACL. +.sp +The return code is zero if the message is successfully accepted. Otherwise, the +action is controlled by the \fB\-oe\fP\fIx\fP option setting \- see below. +.sp +The format +of the message must be as defined in RFC 2822, except that, for +compatibility with Sendmail and Smail, a line in one of the forms +.sp + From sender Fri Jan 5 12:55 GMT 1997 + From sender Fri, 5 Jan 97 12:55:01 +.sp +(with the weekday optional, and possibly with additional text after the date) +is permitted to appear at the start of the message. There appears to be no +authoritative specification of the format of this line. Exim recognizes it by +matching against the regular expression defined by the \fBuucp_from_pattern\fP +option, which can be changed if necessary. +.sp +The specified sender is treated as if it were given as the argument to the +\fB\-f\fP option, but if a \fB\-f\fP option is also present, its argument is used in +preference to the address taken from the message. The caller of Exim must be a +trusted user for the sender of a message to be set in this way. +.TP 10 +\fB\-bmalware\fP <\fIfilename\fP> +This debugging option causes Exim to scan the given file or directory +(depending on the used scanner interface), +using the malware scanning framework. The option of \fBav_scanner\fP influences +this option, so if \fBav_scanner\fP's value is dependent upon an expansion then +the expansion should have defaults which apply to this invocation. ACLs are +not invoked, so if \fBav_scanner\fP references an ACL variable then that variable +will never be populated and \fB\-bmalware\fP will fail. +.sp +Exim will have changed working directory before resolving the filename, so +using fully qualified pathnames is advisable. Exim will be running as the Exim +user when it tries to open the file, rather than as the invoking user. +This option requires admin privileges. +.sp +The \fB\-bmalware\fP option will not be extended to be more generally useful, +there are better tools for file\-scanning. This option exists to help +administrators verify their Exim and AV scanner configuration. +.TP 10 +\fB\-bnq\fP +By default, Exim automatically qualifies unqualified addresses (those +without domains) that appear in messages that are submitted locally (that +is, not over TCP/IP). This qualification applies both to addresses in +envelopes, and addresses in header lines. Sender addresses are qualified using +\fBqualify_domain\fP, and recipient addresses using \fBqualify_recipient\fP (which +defaults to the value of \fBqualify_domain\fP). +.sp +Sometimes, qualification is not wanted. For example, if \fB\-bS\fP (batch SMTP) is +being used to re\-submit messages that originally came from remote hosts after +content scanning, you probably do not want to qualify unqualified addresses in +header lines. (Such lines will be present only if you have not enabled a header +syntax check in the appropriate ACL.) +.sp +The \fB\-bnq\fP option suppresses all qualification of unqualified addresses in +messages that originate on the local host. When this is used, unqualified +addresses in the envelope provoke errors (causing message rejection) and +unqualified addresses in header lines are left alone. +.TP 10 +\fB\-bP\fP +If this option is given with no arguments, it causes the values of all Exim's +main configuration options to be written to the standard output. The values +of one or more specific options can be requested by giving their names as +arguments, for example: +.sp + exim \-bP qualify_domain hold_domains +.sp +However, any option setting that is preceded by the word "hide" in the +configuration file is not shown in full, except to an admin user. For other +users, the output is as in this example: +.sp + mysql_servers = <value not displayable> +.sp +If \fBconfig\fP is given as an argument, the config is +output, as it was parsed, any include file resolved, any comment removed. +.sp +If \fBconfig_file\fP is given as an argument, the name of the runtime +configuration file is output. (\fBconfigure_file\fP works too, for +backward compatibility.) +If a list of configuration files was supplied, the value that is output here +is the name of the file that was actually used. +.sp +If the \fB\-n\fP flag is given, then for most modes of \fB\-bP\fP operation the +name will not be output. +.sp +If \fBlog_file_path\fP or \fBpid_file_path\fP are given, the names of the +directories where log files and daemon pid files are written are output, +respectively. If these values are unset, log files are written in a +sub\-directory of the spool directory called \fBlog\fP, and the pid file is +written directly into the spool directory. +.sp +If \fB\-bP\fP is followed by a name preceded by +, for example, +.sp + exim \-bP +local_domains +.sp +it searches for a matching named list of any type (domain, host, address, or +local part) and outputs what it finds. +.sp +If one of the words \fBrouter\fP, \fBtransport\fP, or \fBauthenticator\fP is given, +followed by the name of an appropriate driver instance, the option settings for +that driver are output. For example: +.sp + exim \-bP transport local_delivery +.sp +The generic driver options are output first, followed by the driver's private +options. A list of the names of drivers of a particular type can be obtained by +using one of the words \fBrouter_list\fP, \fBtransport_list\fP, or +\fBauthenticator_list\fP, and a complete list of all drivers with their option +settings can be obtained by using \fBrouters\fP, \fBtransports\fP, or +\fBauthenticators\fP. +.sp +If \fBenvironment\fP is given as an argument, the set of environment +variables is output, line by line. Using the \fB\-n\fP flag suppresses the value of the +variables. +.sp +If invoked by an admin user, then \fBmacro\fP, \fBmacro_list\fP and \fBmacros\fP +are available, similarly to the drivers. Because macros are sometimes used +for storing passwords, this option is restricted. +The output format is one item per line. +For the "\-bP macro <name>" form, if no such macro is found +the exit status will be nonzero. +.TP 10 +\fB\-bp\fP +This option requests a listing of the contents of the mail queue on the +standard output. If the \fB\-bp\fP option is followed by a list of message ids, +just those messages are listed. By default, this option can be used only by an +admin user. However, the \fBqueue_list_requires_admin\fP option can be set false +to allow any user to see the queue. +.sp +Each message in the queue is displayed as in the following example: +.sp + 25m 2.9K 0t5C6f\-0000c8\-00 <alice@wonderland.fict.example> + red.king@looking\-glass.fict.example + <other addresses> +.sp +The first line contains the length of time the message has been in the queue +(in this case 25 minutes), the size of the message (2.9K), the unique local +identifier for the message, and the message sender, as contained in the +envelope. For bounce messages, the sender address is empty, and appears as +"<>". If the message was submitted locally by an untrusted user who overrode +the default sender address, the user's login name is shown in parentheses +before the sender address. +.sp +If the message is frozen (attempts to deliver it are suspended) then the text +"*** frozen ***" is displayed at the end of this line. +.sp +The recipients of the message (taken from the envelope, not the headers) are +displayed on subsequent lines. Those addresses to which the message has already +been delivered are marked with the letter D. If an original address gets +expanded into several addresses via an alias or forward file, the original is +displayed with a D only when deliveries for all of its child addresses are +complete. +.TP 10 +\fB\-bpa\fP +This option operates like \fB\-bp\fP, but in addition it shows delivered addresses +that were generated from the original top level address(es) in each message by +alias or forwarding operations. These addresses are flagged with "+D" instead +of just "D". +.TP 10 +\fB\-bpc\fP +This option counts the number of messages in the queue, and writes the total +to the standard output. It is restricted to admin users, unless +\fBqueue_list_requires_admin\fP is set false. +.TP 10 +\fB\-bpr\fP +This option operates like \fB\-bp\fP, but the output is not sorted into +chronological order of message arrival. This can speed it up when there are +lots of messages in the queue, and is particularly useful if the output is +going to be post\-processed in a way that doesn't need the sorting. +.TP 10 +\fB\-bpra\fP +This option is a combination of \fB\-bpr\fP and \fB\-bpa\fP. +.TP 10 +\fB\-bpru\fP +This option is a combination of \fB\-bpr\fP and \fB\-bpu\fP. +.TP 10 +\fB\-bpu\fP +This option operates like \fB\-bp\fP but shows only undelivered top\-level +addresses for each message displayed. Addresses generated by aliasing or +forwarding are not shown, unless the message was deferred after processing by a +router with the \fBone_time\fP option set. +.TP 10 +\fB\-brt\fP +This option is for testing retry rules, and it must be followed by up to three +arguments. It causes Exim to look for a retry rule that matches the values +and to write it to the standard output. For example: +.sp + exim \-brt bach.comp.mus.example + Retry rule: *.comp.mus.example F,2h,15m; F,4d,30m; +.sp + The first +argument, which is required, can be a complete address in the form +\fIlocal_part@domain\fP, or it can be just a domain name. If the second argument +contains a dot, it is interpreted as an optional second domain name; if no +retry rule is found for the first argument, the second is tried. This ties in +with Exim's behaviour when looking for retry rules for remote hosts \- if no +rule is found that matches the host, one that matches the mail domain is +sought. Finally, an argument that is the name of a specific delivery error, as +used in setting up retry rules, can be given. For example: +.sp + exim \-brt haydn.comp.mus.example quota_3d + Retry rule: *@haydn.comp.mus.example quota_3d F,1h,15m +.TP 10 +\fB\-brw\fP +This option is for testing address rewriting rules, and it must be followed by +a single argument, consisting of either a local part without a domain, or a +complete address with a fully qualified domain. Exim outputs how this address +would be rewritten for each possible place it might appear. +.TP 10 +\fB\-bS\fP +This option is used for batched SMTP input, which is an alternative interface +for non\-interactive local message submission. A number of messages can be +submitted in a single run. However, despite its name, this is not really SMTP +input. Exim reads each message's envelope from SMTP commands on the standard +input, but generates no responses. If the caller is trusted, or +\fBuntrusted_set_sender\fP is set, the senders in the SMTP MAIL commands are +believed; otherwise the sender is always the caller of Exim. +.sp +The message itself is read from the standard input, in SMTP format (leading +dots doubled), terminated by a line containing just a single dot. An error is +provoked if the terminating dot is missing. A further message may then follow. +.sp +As for other local message submissions, the contents of incoming batch SMTP +messages can be checked using the non\-SMTP ACL. +Unqualified addresses are automatically qualified using \fBqualify_domain\fP and +\fBqualify_recipient\fP, as appropriate, unless the \fB\-bnq\fP option is used. +.sp +Some other SMTP commands are recognized in the input. HELO and EHLO act +as RSET; VRFY, EXPN, ETRN, and HELP act as NOOP; +QUIT quits, ignoring the rest of the standard input. +.sp +If any error is encountered, reports are written to the standard output and +error streams, and Exim gives up immediately. The return code is 0 if no error +was detected; it is 1 if one or more messages were accepted before the error +was detected; otherwise it is 2. +.sp +.TP 10 +\fB\-bs\fP +This option causes Exim to accept one or more messages by reading SMTP commands +on the standard input, and producing SMTP replies on the standard output. SMTP +policy controls, as defined in ACLs are applied. +Some user agents use this interface as a way of passing locally\-generated +messages to the MTA. +.sp +In +this usage, if the caller of Exim is trusted, or \fBuntrusted_set_sender\fP is +set, the senders of messages are taken from the SMTP MAIL commands. +Otherwise the content of these commands is ignored and the sender is set up as +the calling user. Unqualified addresses are automatically qualified using +\fBqualify_domain\fP and \fBqualify_recipient\fP, as appropriate, unless the +\fB\-bnq\fP option is used. +.sp +The +\fB\-bs\fP option is also used to run Exim from \fIinetd\fP, as an alternative to +using a listening daemon. Exim can distinguish the two cases by checking +whether the standard input is a TCP/IP socket. When Exim is called from +\fIinetd\fP, the source of the mail is assumed to be remote, and the comments +above concerning senders and qualification do not apply. In this situation, +Exim behaves in exactly the same way as it does when receiving a message via +the listening daemon. +.TP 10 +\fB\-bt\fP +This option runs Exim in address testing mode, in which each argument is taken +as a recipient address to be tested for deliverability. The results are +written to the standard output. If a test fails, and the caller is not an admin +user, no details of the failure are output, because these might contain +sensitive information such as usernames and passwords for database lookups. +.sp +If no arguments are given, Exim runs in an interactive manner, prompting with a +right angle bracket for addresses to be tested. +.sp +Unlike the \fB\-be\fP test option, you cannot arrange for Exim to use the +readline() function, because it is running as \fIroot\fP and there are +security issues. +.sp +Each address is handled as if it were the recipient address of a message +(compare the \fB\-bv\fP option). It is passed to the routers and the result is +written to the standard output. However, any router that has +\fBno_address_test\fP set is bypassed. This can make \fB\-bt\fP easier to use for +genuine routing tests if your first router passes everything to a scanner +program. +.sp +The return code is 2 if any address failed outright; it is 1 if no address +failed outright but at least one could not be resolved for some reason. Return +code 0 is given only when all addresses succeed. +.sp +\fBNote\fP: When actually delivering a message, Exim removes duplicate recipient +addresses after routing is complete, so that only one delivery takes place. +This does not happen when testing with \fB\-bt\fP; the full results of routing are +always shown. +.sp +\fBWarning\fP: \fB\-bt\fP can only do relatively simple testing. If any of the +routers in the configuration makes any tests on the sender address of a +message, +you can use the \fB\-f\fP option to set an appropriate sender when running +\fB\-bt\fP tests. Without it, the sender is assumed to be the calling user at the +default qualifying domain. However, if you have set up (for example) routers +whose behaviour depends on the contents of an incoming message, you cannot test +those conditions using \fB\-bt\fP. The \fB\-N\fP option provides a possible way of +doing such tests. +.TP 10 +\fB\-bV\fP +This option causes Exim to write the current version number, compilation +number, and compilation date of the \fIexim\fP binary to the standard output. +It also lists the DBM library that is being used, the optional modules (such as +specific lookup types), the drivers that are included in the binary, and the +name of the runtime configuration file that is in use. +.sp +As part of its operation, \fB\-bV\fP causes Exim to read and syntax check its +configuration file. However, this is a static check only. It cannot check +values that are to be expanded. For example, although a misspelt ACL verb is +detected, an error in the verb's arguments is not. You cannot rely on \fB\-bV\fP +alone to discover (for example) all the typos in the configuration; some +realistic testing is needed. The \fB\-bh\fP and \fB\-N\fP options provide more +dynamic testing facilities. +.TP 10 +\fB\-bv\fP +This option runs Exim in address verification mode, in which each argument is +taken as a recipient address to be verified by the routers. (This does +not involve any verification callouts). During normal operation, verification +happens mostly as a consequence processing a \fBverify\fP condition in an ACL. If you want to test an entire ACL, possibly +including callouts, see the \fB\-bh\fP and \fB\-bhc\fP options. +.sp +If verification fails, and the caller is not an admin user, no details of the +failure are output, because these might contain sensitive information such as +usernames and passwords for database lookups. +.sp +If no arguments are given, Exim runs in an interactive manner, prompting with a +right angle bracket for addresses to be verified. +.sp +Unlike the \fB\-be\fP test option, you cannot arrange for Exim to use the +readline() function, because it is running as \fIexim\fP and there are +security issues. +.sp +Verification differs from address testing (the \fB\-bt\fP option) in that routers +that have \fBno_verify\fP set are skipped, and if the address is accepted by a +router that has \fBfail_verify\fP set, verification fails. The address is +verified as a recipient if \fB\-bv\fP is used; to test verification for a sender +address, \fB\-bvs\fP should be used. +.sp +If the \fB\-v\fP option is not set, the output consists of a single line for each +address, stating whether it was verified or not, and giving a reason in the +latter case. Without \fB\-v\fP, generating more than one address by redirection +causes verification to end successfully, without considering the generated +addresses. However, if just one address is generated, processing continues, +and the generated address must verify successfully for the overall verification +to succeed. +.sp +When \fB\-v\fP is set, more details are given of how the address has been handled, +and in the case of address redirection, all the generated addresses are also +considered. Verification may succeed for some and fail for others. +.sp +The +return code is 2 if any address failed outright; it is 1 if no address +failed outright but at least one could not be resolved for some reason. Return +code 0 is given only when all addresses succeed. +.sp +If any of the routers in the configuration makes any tests on the sender +address of a message, you should use the \fB\-f\fP option to set an appropriate +sender when running \fB\-bv\fP tests. Without it, the sender is assumed to be the +calling user at the default qualifying domain. +.TP 10 +\fB\-bvs\fP +This option acts like \fB\-bv\fP, but verifies the address as a sender rather +than a recipient address. This affects any rewriting and qualification that +might happen. +.TP 10 +\fB\-bw\fP +This option runs Exim as a daemon, awaiting incoming SMTP connections, +similarly to the \fB\-bd\fP option. All port specifications on the command\-line +and in the configuration file are ignored. Queue\-running may not be specified. +.sp +In this mode, Exim expects to be passed a socket as fd 0 (stdin) which is +listening for connections. This permits the system to start up and have +inetd (or equivalent) listen on the SMTP ports, starting an Exim daemon for +each port only when the first connection is received. +.sp +If the option is given as \fB\-bw\fP<\fItime\fP> then the time is a timeout, after +which the daemon will exit, which should cause inetd to listen once more. +.TP 10 +\fB\-C\fP <\fIfilelist\fP> +This option causes Exim to find the runtime configuration file from the given +list instead of from the list specified by the CONFIGURE_FILE +compile\-time setting. Usually, the list will consist of just a single filename, +but it can be a colon\-separated list of names. In this case, the first +file that exists is used. Failure to open an existing file stops Exim from +proceeding any further along the list, and an error is generated. +.sp +When this option is used by a caller other than root, and the list is different +from the compiled\-in list, Exim gives up its root privilege immediately, and +runs with the real and effective uid and gid set to those of the caller. +However, if a TRUSTED_CONFIG_LIST file is defined in Local/Makefile, that +file contains a list of full pathnames, one per line, for configuration files +which are trusted. Root privilege is retained for any configuration file so +listed, as long as the caller is the Exim user (or the user specified in the +CONFIGURE_OWNER option, if any), and as long as the configuration file is +not writeable by inappropriate users or groups. +.sp +Leaving TRUSTED_CONFIG_LIST unset precludes the possibility of testing a +configuration using \fB\-C\fP right through message reception and delivery, +even if the caller is root. The reception works, but by that time, Exim is +running as the Exim user, so when it re\-executes to regain privilege for the +delivery, the use of \fB\-C\fP causes privilege to be lost. However, root can +test reception and delivery using two separate commands (one to put a message +in the queue, using \fB\-odq\fP, and another to do the delivery, using \fB\-M\fP). +.sp +If ALT_CONFIG_PREFIX is defined in Local/Makefile, it specifies a +prefix string with which any file named in a \fB\-C\fP command line option +must start. In addition, the filename must not contain the sequence /../. +However, if the value of the \fB\-C\fP option is identical to the value of +CONFIGURE_FILE in Local/Makefile, Exim ignores \fB\-C\fP and proceeds as +usual. There is no default setting for ALT_CONFIG_PREFIX; when it is +unset, any filename can be used with \fB\-C\fP. +.sp +ALT_CONFIG_PREFIX can be used to confine alternative configuration files +to a directory to which only root has access. This prevents someone who has +broken into the Exim account from running a privileged Exim with an arbitrary +configuration file. +.sp +The \fB\-C\fP facility is useful for ensuring that configuration files are +syntactically correct, but cannot be used for test deliveries, unless the +caller is privileged, or unless it is an exotic configuration that does not +require privilege. No check is made on the owner or group of the files +specified by this option. +.TP 10 +\fB\-D\fP<\fImacro\fP>=<\fIvalue\fP> +This option can be used to override macro definitions in the configuration file. However, like \fB\-C\fP, if it is used by an +unprivileged caller, it causes Exim to give up its root privilege. +If DISABLE_D_OPTION is defined in Local/Makefile, the use of \fB\-D\fP is +completely disabled, and its use causes an immediate error exit. +.sp +If WHITELIST_D_MACROS is defined in Local/Makefile then it should be a +colon\-separated list of macros which are considered safe and, if \fB\-D\fP only +supplies macros from this list, and the values are acceptable, then Exim will +not give up root privilege if the caller is root, the Exim run\-time user, or +the CONFIGURE_OWNER, if set. This is a transition mechanism and is expected +to be removed in the future. Acceptable values for the macros satisfy the +regexp: ^[A\-Za\-z0\-9_/.\-]*$ +.sp +The entire option (including equals sign if present) must all be within one +command line item. \fB\-D\fP can be used to set the value of a macro to the empty +string, in which case the equals sign is optional. These two commands are +synonymous: +.sp + exim \-DABC ... + exim \-DABC= ... +.sp +To include spaces in a macro definition item, quotes must be used. If you use +quotes, spaces are permitted around the macro name and the equals sign. For +example: +.sp + exim '\-D ABC = something' ... +.sp +\fB\-D\fP may be repeated up to 10 times on a command line. +Only macro names up to 22 letters long can be set. +.TP 10 +\fB\-d\fP<\fIdebug options\fP> +This option causes debugging information to be written to the standard +error stream. It is restricted to admin users because debugging output may show +database queries that contain password information. Also, the details of users' +filter files should be protected. If a non\-admin user uses \fB\-d\fP, Exim +writes an error message to the standard error stream and exits with a non\-zero +return code. +.sp +When \fB\-d\fP is used, \fB\-v\fP is assumed. If \fB\-d\fP is given on its own, a lot of +standard debugging data is output. This can be reduced, or increased to include +some more rarely needed information, by directly following \fB\-d\fP with a string +made up of names preceded by plus or minus characters. These add or remove sets +of debugging data, respectively. For example, \fB\-d+filter\fP adds filter +debugging, whereas \fB\-d\-all+filter\fP selects only filter debugging. Note that +no spaces are allowed in the debug setting. The available debugging categories +are: +.sp + acl ACL interpretation + auth authenticators + deliver general delivery logic + dns DNS lookups (see also resolver) + dnsbl DNS black list (aka RBL) code + exec arguments for execv() calls + expand detailed debugging for string expansions + filter filter handling + hints_lookup hints data lookups + host_lookup all types of name\-to\-IP address handling + ident ident lookup + interface lists of local interfaces + lists matching things in lists + load system load checks + local_scan can be used by local_scan() + lookup general lookup code and all lookups + memory memory handling + noutf8 modifier: avoid UTF\-8 line\-drawing + pid modifier: add pid to debug output lines + process_info setting info for the process log + queue_run queue runs + receive general message reception logic + resolver turn on the DNS resolver's debugging output + retry retry handling + rewrite address rewriting + route address routing + timestamp modifier: add timestamp to debug output lines + tls TLS logic + transport transports + uid changes of uid/gid and looking up uid/gid + verify address verification logic + all almost all of the above (see below), and also \fB\-v\fP +.sp +The all option excludes memory when used as +all, but includes it +for \-all. The reason for this is that +all is something that people +tend to use when generating debug output for Exim maintainers. If +memory +is included, an awful lot of output that is very rarely of interest is +generated, so it now has to be explicitly requested. However, \-all does +turn everything off. +.sp +The resolver option produces output only if the DNS resolver was compiled +with DEBUG enabled. This is not the case in some operating systems. Also, +unfortunately, debugging output from the DNS resolver is written to stdout +rather than stderr. +.sp +The default (\fB\-d\fP with no argument) omits expand, filter, +interface, load, memory, pid, resolver, and timestamp. +However, the pid selector is forced when debugging is turned on for a +daemon, which then passes it on to any re\-executed Exims. Exim also +automatically adds the pid to debug lines when several remote deliveries are +run in parallel. +.sp +The timestamp selector causes the current time to be inserted at the start +of all debug output lines. This can be useful when trying to track down delays +in processing. +The noutf8 selector disables the use of +UTF\-8 line\-drawing characters to group related information. +When disabled. ascii\-art is used instead. +Using the +all option does not set this modifier, +.sp +If the \fBdebug_print\fP option is set in any driver, it produces output whenever +any debugging is selected, or if \fB\-v\fP is used. +.TP 10 +\fB\-dd\fP<\fIdebug options\fP> +This option behaves exactly like \fB\-d\fP except when used on a command that +starts a daemon process. In that case, debugging is turned off for the +subprocesses that the daemon creates. Thus, it is useful for monitoring the +behaviour of the daemon without creating as much output as full debugging does. +.TP 10 +\fB\-dropcr\fP +This is an obsolete option that is now a no\-op. It used to affect the way Exim +handled CR and LF characters in incoming messages. +.TP 10 +\fB\-E\fP +This option specifies that an incoming message is a locally\-generated delivery +failure report. It is used internally by Exim when handling delivery failures +and is not intended for external use. Its only effect is to stop Exim +generating certain messages to the postmaster, as otherwise message cascades +could occur in some situations. As part of the same option, a message id may +follow the characters \fB\-E\fP. If it does, the log entry for the receipt of the +new message contains the id, following "R=", as a cross\-reference. +.TP 10 +\fB\-e\fP\fIx\fP +There are a number of Sendmail options starting with \fB\-oe\fP which seem to be +called by various programs without the leading \fBo\fP in the option. For +example, the \fBvacation\fP program uses \fB\-eq\fP. Exim treats all options of the +form \fB\-e\fP\fIx\fP as synonymous with the corresponding \fB\-oe\fP\fIx\fP options. +.TP 10 +\fB\-F\fP <\fIstring\fP> +This option sets the sender's full name for use when a locally\-generated +message is being accepted. In the absence of this option, the user's \fIgecos\fP +entry from the password data is used. As users are generally permitted to alter +their \fIgecos\fP entries, no security considerations are involved. White space +between \fB\-F\fP and the <\fIstring\fP> is optional. +.TP 10 +\fB\-f\fP <\fIaddress\fP> +This option sets the address of the envelope sender of a locally\-generated +message (also known as the return path). The option can normally be used only +by a trusted user, but \fBuntrusted_set_sender\fP can be set to allow untrusted +users to use it. +.sp +Processes running as root or the Exim user are always trusted. Other +trusted users are defined by the \fBtrusted_users\fP or \fBtrusted_groups\fP +options. In the absence of \fB\-f\fP, or if the caller is not trusted, the sender +of a local message is set to the caller's login name at the default qualify +domain. +.sp +There is one exception to the restriction on the use of \fB\-f\fP: an empty sender +can be specified by any user, trusted or not, to create a message that can +never provoke a bounce. An empty sender can be specified either as an empty +string, or as a pair of angle brackets with nothing between them, as in these +examples of shell commands: +.sp + exim \-f '<>' user@domain + exim \-f "" user@domain +.sp +In addition, the use of \fB\-f\fP is not restricted when testing a filter file +with \fB\-bf\fP or when testing or verifying addresses using the \fB\-bt\fP or +\fB\-bv\fP options. +.sp +Allowing untrusted users to change the sender address does not of itself make +it possible to send anonymous mail. Exim still checks that the \fIFrom:\fP header +refers to the local user, and if it does not, it adds a \fISender:\fP header, +though this can be overridden by setting \fBno_local_from_check\fP. +.sp +White +space between \fB\-f\fP and the <\fIaddress\fP> is optional (that is, they can be +given as two arguments or one combined argument). The sender of a +locally\-generated message can also be set (when permitted) by an initial +"From " line in the message \- see the description of \fB\-bm\fP above \- but +if \fB\-f\fP is also present, it overrides "From ". +.TP 10 +\fB\-G\fP +This option is equivalent to an ACL applying: +.sp + control = suppress_local_fixups +.sp +for every message received. Note that Sendmail will complain about such +bad formatting, where Exim silently just does not fix it up. This may change +in future. +.sp +As this affects audit information, the caller must be a trusted user to use +this option. +.TP 10 +\fB\-h\fP <\fInumber\fP> +This option is accepted for compatibility with Sendmail, but has no effect. (In +Sendmail it overrides the "hop count" obtained by counting \fIReceived:\fP +headers.) +.TP 10 +\fB\-i\fP +This option, which has the same effect as \fB\-oi\fP, specifies that a dot on a +line by itself should not terminate an incoming, non\-SMTP message. I can find +no documentation for this option in Solaris 2.4 Sendmail, but the \fImailx\fP +command in Solaris 2.4 uses it. See also \fB\-ti\fP. +.TP 10 +\fB\-L\fP <\fItag\fP> +This option is equivalent to setting \fBsyslog_processname\fP in the config +file and setting \fBlog_file_path\fP to syslog. +Its use is restricted to administrators. The configuration file has to be +read and parsed, to determine access rights, before this is set and takes +effect, so early configuration file errors will not honour this flag. +.sp +The tag should not be longer than 32 characters. +.TP 10 +\fB\-M\fP <\fImessage id\fP> <\fImessage id\fP> ... +This option requests Exim to run a delivery attempt on each message in turn. If +any of the messages are frozen, they are automatically thawed before the +delivery attempt. The settings of \fBqueue_domains\fP, \fBqueue_smtp_domains\fP, +and \fBhold_domains\fP are ignored. +.sp +Retry +hints for any of the addresses are overridden \- Exim tries to deliver even if +the normal retry time has not yet been reached. This option requires the caller +to be an admin user. However, there is an option called \fBprod_requires_admin\fP +which can be set false to relax this restriction (and also the same requirement +for the \fB\-q\fP, \fB\-R\fP, and \fB\-S\fP options). +.sp +The deliveries happen synchronously, that is, the original Exim process does +not terminate until all the delivery attempts have finished. No output is +produced unless there is a serious error. If you want to see what is happening, +use the \fB\-v\fP option as well, or inspect Exim's main log. +.TP 10 +\fB\-Mar\fP <\fImessage id\fP> <\fIaddress\fP> <\fIaddress\fP> ... +This option requests Exim to add the addresses to the list of recipients of the +message ("ar" for "add recipients"). The first argument must be a message +id, and the remaining ones must be email addresses. However, if the message is +active (in the middle of a delivery attempt), it is not altered. This option +can be used only by an admin user. +.TP 10 +\fB\-MC\fP <\fItransport\fP> <\fIhostname\fP> <\fIsequence number\fP> <\fImessage id\fP> +This option is not intended for use by external callers. It is used internally +by Exim to invoke another instance of itself to deliver a waiting message using +an existing SMTP connection, which is passed as the standard input. This must be the final option, and the caller +must be root or the Exim user in order to use it. +.TP 10 +\fB\-MCA\fP +This option is not intended for use by external callers. It is used internally +by Exim in conjunction with the \fB\-MC\fP option. It signifies that the +connection to the remote host has been authenticated. +.TP 10 +\fB\-MCD\fP +This option is not intended for use by external callers. It is used internally +by Exim in conjunction with the \fB\-MC\fP option. It signifies that the +remote host supports the ESMTP DSN extension. +.TP 10 +\fB\-MCG\fP <\fIqueue name\fP> +This option is not intended for use by external callers. It is used internally +by Exim in conjunction with the \fB\-MC\fP option. It signifies that an +alternate queue is used, named by the following argument. +.TP 10 +\fB\-MCK\fP +This option is not intended for use by external callers. It is used internally +by Exim in conjunction with the \fB\-MC\fP option. It signifies that a +remote host supports the ESMTP CHUNKING extension. +.TP 10 +\fB\-MCP\fP +This option is not intended for use by external callers. It is used internally +by Exim in conjunction with the \fB\-MC\fP option. It signifies that the server to +which Exim is connected supports pipelining. +.TP 10 +\fB\-MCQ\fP <\fIprocess id\fP> <\fIpipe fd\fP> +This option is not intended for use by external callers. It is used internally +by Exim in conjunction with the \fB\-MC\fP option when the original delivery was +started by a queue runner. It passes on the process id of the queue runner, +together with the file descriptor number of an open pipe. Closure of the pipe +signals the final completion of the sequence of processes that are passing +messages through the same SMTP connection. +.TP 10 +\fB\-MCS\fP +This option is not intended for use by external callers. It is used internally +by Exim in conjunction with the \fB\-MC\fP option, and passes on the fact that the +SMTP SIZE option should be used on messages delivered down the existing +connection. +.TP 10 +\fB\-MCT\fP +This option is not intended for use by external callers. It is used internally +by Exim in conjunction with the \fB\-MC\fP option, and passes on the fact that the +host to which Exim is connected supports TLS encryption. +.TP 10 +\fB\-MCt\fP <\fIIP address\fP> <\fIport\fP> <\fIcipher\fP> +This option is not intended for use by external callers. It is used internally +by Exim in conjunction with the \fB\-MC\fP option, and passes on the fact that the +connection is being proxied by a parent process for handling TLS encryption. +The arguments give the local address and port being proxied, and the TLS cipher. +.TP 10 +\fB\-Mc\fP <\fImessage id\fP> <\fImessage id\fP> ... +This option requests Exim to run a delivery attempt on each message, in turn, +but unlike the \fB\-M\fP option, it does check for retry hints, and respects any +that are found. This option is not very useful to external callers. It is +provided mainly for internal use by Exim when it needs to re\-invoke itself in +order to regain root privilege for a delivery. +However, \fB\-Mc\fP can be useful when testing, in order to run a delivery that +respects retry times and other options such as \fBhold_domains\fP that are +overridden when \fB\-M\fP is used. Such a delivery does not count as a queue run. +If you want to run a specific delivery as if in a queue run, you should use +\fB\-q\fP with a message id argument. A distinction between queue run deliveries +and other deliveries is made in one or two places. +.TP 10 +\fB\-Mes\fP <\fImessage id\fP> <\fIaddress\fP> +This option requests Exim to change the sender address in the message to the +given address, which must be a fully qualified address or "<>" ("es" for +"edit sender"). There must be exactly two arguments. The first argument must +be a message id, and the second one an email address. However, if the message +is active (in the middle of a delivery attempt), its status is not altered. +This option can be used only by an admin user. +.TP 10 +\fB\-Mf\fP <\fImessage id\fP> <\fImessage id\fP> ... +This option requests Exim to mark each listed message as "frozen". This +prevents any delivery attempts taking place until the message is "thawed", +either manually or as a result of the \fBauto_thaw\fP configuration option. +However, if any of the messages are active (in the middle of a delivery +attempt), their status is not altered. This option can be used only by an admin +user. +.TP 10 +\fB\-Mg\fP <\fImessage id\fP> <\fImessage id\fP> ... +This option requests Exim to give up trying to deliver the listed messages, +including any that are frozen. However, if any of the messages are active, +their status is not altered. For non\-bounce messages, a delivery error message +is sent to the sender, containing the text "cancelled by administrator". +Bounce messages are just discarded. This option can be used only by an admin +user. +.TP 10 +\fB\-Mmad\fP <\fImessage id\fP> <\fImessage id\fP> ... +This option requests Exim to mark all the recipient addresses in the messages +as already delivered ("mad" for "mark all delivered"). However, if any +message is active (in the middle of a delivery attempt), its status is not +altered. This option can be used only by an admin user. +.TP 10 +\fB\-Mmd\fP <\fImessage id\fP> <\fIaddress\fP> <\fIaddress\fP> ... +This option requests Exim to mark the given addresses as already delivered +("md" for "mark delivered"). The first argument must be a message id, and +the remaining ones must be email addresses. These are matched to recipient +addresses in the message in a case\-sensitive manner. If the message is active +(in the middle of a delivery attempt), its status is not altered. This option +can be used only by an admin user. +.TP 10 +\fB\-Mrm\fP <\fImessage id\fP> <\fImessage id\fP> ... +This option requests Exim to remove the given messages from the queue. No +bounce messages are sent; each message is simply forgotten. However, if any of +the messages are active, their status is not altered. This option can be used +only by an admin user or by the user who originally caused the message to be +placed in the queue. +.TP 10 +\fB\-Mset\fP <\fImessage id\fP> +This option is useful only in conjunction with \fB\-be\fP (that is, when testing +string expansions). Exim loads the given message from its spool before doing +the test expansions, thus setting message\-specific variables such as +\fI$message_size\fP and the header variables. The \fI$recipients\fP variable is made +available. This feature is provided to make it easier to test expansions that +make use of these variables. However, this option can be used only by an admin +user. See also \fB\-bem\fP. +.TP 10 +\fB\-Mt\fP <\fImessage id\fP> <\fImessage id\fP> ... +This option requests Exim to "thaw" any of the listed messages that are +"frozen", so that delivery attempts can resume. However, if any of the +messages are active, their status is not altered. This option can be used only +by an admin user. +.TP 10 +\fB\-Mvb\fP <\fImessage id\fP> +This option causes the contents of the message body (\-D) spool file to be +written to the standard output. This option can be used only by an admin user. +.TP 10 +\fB\-Mvc\fP <\fImessage id\fP> +This option causes a copy of the complete message (header lines plus body) to +be written to the standard output in RFC 2822 format. This option can be used +only by an admin user. +.TP 10 +\fB\-Mvh\fP <\fImessage id\fP> +This option causes the contents of the message headers (\-H) spool file to be +written to the standard output. This option can be used only by an admin user. +.TP 10 +\fB\-Mvl\fP <\fImessage id\fP> +This option causes the contents of the message log spool file to be written to +the standard output. This option can be used only by an admin user. +.TP 10 +\fB\-m\fP +This is apparently a synonym for \fB\-om\fP that is accepted by Sendmail, so Exim +treats it that way too. +.TP 10 +\fB\-N\fP +This is a debugging option that inhibits delivery of a message at the transport +level. It implies \fB\-v\fP. Exim goes through many of the motions of delivery \- +it just doesn't actually transport the message, but instead behaves as if it +had successfully done so. However, it does not make any updates to the retry +database, and the log entries for deliveries are flagged with "*>" rather +than "=>". +.sp +Because \fB\-N\fP discards any message to which it applies, only root or the Exim +user are allowed to use it with \fB\-bd\fP, \fB\-q\fP, \fB\-R\fP or \fB\-M\fP. In other +words, an ordinary user can use it only when supplying an incoming message to +which it will apply. Although transportation never fails when \fB\-N\fP is set, an +address may be deferred because of a configuration problem on a transport, or a +routing problem. Once \fB\-N\fP has been used for a delivery attempt, it sticks to +the message, and applies to any subsequent delivery attempts that may happen +for that message. +.TP 10 +\fB\-n\fP +This option is interpreted by Sendmail to mean "no aliasing". +For normal modes of operation, it is ignored by Exim. +When combined with \fB\-bP\fP it makes the output more terse (suppresses +option names, environment values and config pretty printing). +.TP 10 +\fB\-O\fP <\fIdata\fP> +This option is interpreted by Sendmail to mean set option. It is ignored by +Exim. +.TP 10 +\fB\-oA\fP <\fIfile name\fP> +This option is used by Sendmail in conjunction with \fB\-bi\fP to specify an +alternative alias filename. Exim handles \fB\-bi\fP differently; see the +description above. +.TP 10 +\fB\-oB\fP <\fIn\fP> +This is a debugging option which limits the maximum number of messages that can +be delivered down one SMTP connection, overriding the value set in any smtp +transport. If <\fIn\fP> is omitted, the limit is set to 1. +.TP 10 +\fB\-odb\fP +This option applies to all modes in which Exim accepts incoming messages, +including the listening daemon. It requests "background" delivery of such +messages, which means that the accepting process automatically starts a +delivery process for each message received, but does not wait for the delivery +processes to finish. +.sp +When all the messages have been received, the reception process exits, +leaving the delivery processes to finish in their own time. The standard output +and error streams are closed at the start of each delivery process. +This is the default action if none of the \fB\-od\fP options are present. +.sp +If one of the queueing options in the configuration file +(\fBqueue_only\fP or \fBqueue_only_file\fP, for example) is in effect, \fB\-odb\fP +overrides it if \fBqueue_only_override\fP is set true, which is the default +setting. If \fBqueue_only_override\fP is set false, \fB\-odb\fP has no effect. +.TP 10 +\fB\-odf\fP +This option requests "foreground" (synchronous) delivery when Exim has +accepted a locally\-generated message. (For the daemon it is exactly the same as +\fB\-odb\fP.) A delivery process is automatically started to deliver the message, +and Exim waits for it to complete before proceeding. +.sp +The original Exim reception process does not finish until the delivery +process for the final message has ended. The standard error stream is left open +during deliveries. +.sp +However, like \fB\-odb\fP, this option has no effect if \fBqueue_only_override\fP is +false and one of the queueing options in the configuration file is in effect. +.sp +If there is a temporary delivery error during foreground delivery, the +message is left in the queue for later delivery, and the original reception +process exits. +.TP 10 +\fB\-odi\fP +This option is synonymous with \fB\-odf\fP. It is provided for compatibility with +Sendmail. +.TP 10 +\fB\-odq\fP +This option applies to all modes in which Exim accepts incoming messages, +including the listening daemon. It specifies that the accepting process should +not automatically start a delivery process for each message received. Messages +are placed in the queue, and remain there until a subsequent queue runner +process encounters them. There are several configuration options (such as +\fBqueue_only\fP) that can be used to queue incoming messages under certain +conditions. This option overrides all of them and also \fB\-odqs\fP. It always +forces queueing. +.TP 10 +\fB\-odqs\fP +This option is a hybrid between \fB\-odb\fP/\fB\-odi\fP and \fB\-odq\fP. +However, like \fB\-odb\fP and \fB\-odi\fP, this option has no effect if +\fBqueue_only_override\fP is false and one of the queueing options in the +configuration file is in effect. +.sp +When \fB\-odqs\fP does operate, a delivery process is started for each incoming +message, in the background by default, but in the foreground if \fB\-odi\fP is +also present. The recipient addresses are routed, and local deliveries are done +in the normal way. However, if any SMTP deliveries are required, they are not +done at this time, so the message remains in the queue until a subsequent queue +runner process encounters it. Because routing was done, Exim knows which +messages are waiting for which hosts, and so a number of messages for the same +host can be sent in a single SMTP connection. The \fBqueue_smtp_domains\fP +configuration option has the same effect for specific domains. See also the +\fB\-qq\fP option. +.TP 10 +\fB\-oee\fP +If an error is detected while a non\-SMTP message is being received (for +example, a malformed address), the error is reported to the sender in a mail +message. +.sp +Provided +this error message is successfully sent, the Exim receiving process +exits with a return code of zero. If not, the return code is 2 if the problem +is that the original message has no recipients, or 1 for any other error. +This is the default \fB\-oe\fP\fIx\fP option if Exim is called as \fIrmail\fP. +.TP 10 +\fB\-oem\fP +This is the same as \fB\-oee\fP, except that Exim always exits with a non\-zero +return code, whether or not the error message was successfully sent. +This is the default \fB\-oe\fP\fIx\fP option, unless Exim is called as \fIrmail\fP. +.TP 10 +\fB\-oep\fP +If an error is detected while a non\-SMTP message is being received, the +error is reported by writing a message to the standard error file (stderr). +The return code is 1 for all errors. +.TP 10 +\fB\-oeq\fP +This option is supported for compatibility with Sendmail, but has the same +effect as \fB\-oep\fP. +.TP 10 +\fB\-oew\fP +This option is supported for compatibility with Sendmail, but has the same +effect as \fB\-oem\fP. +.TP 10 +\fB\-oi\fP +This option, which has the same effect as \fB\-i\fP, specifies that a dot on a +line by itself should not terminate an incoming, non\-SMTP message. Otherwise, a +single dot does terminate, though Exim does no special processing for other +lines that start with a dot. This option is set by default if Exim is called as +\fIrmail\fP. See also \fB\-ti\fP. +.TP 10 +\fB\-oitrue\fP +This option is treated as synonymous with \fB\-oi\fP. +.TP 10 +\fB\-oMa\fP <\fIhost address\fP> +A number of options starting with \fB\-oM\fP can be used to set values associated +with remote hosts on locally\-submitted messages (that is, messages not received +over TCP/IP). These options can be used by any caller in conjunction with the +\fB\-bh\fP, \fB\-be\fP, \fB\-bf\fP, \fB\-bF\fP, \fB\-bt\fP, or \fB\-bv\fP testing options. In +other circumstances, they are ignored unless the caller is trusted. +.sp +The \fB\-oMa\fP option sets the sender host address. This may include a port +number at the end, after a full stop (period). For example: +.sp + exim \-bs \-oMa 10.9.8.7.1234 +.sp +An alternative syntax is to enclose the IP address in square brackets, +followed by a colon and the port number: +.sp + exim \-bs \-oMa [10.9.8.7]:1234 +.sp +The IP address is placed in the \fI$sender_host_address\fP variable, and the +port, if present, in \fI$sender_host_port\fP. If both \fB\-oMa\fP and \fB\-bh\fP +are present on the command line, the sender host IP address is taken from +whichever one is last. +.TP 10 +\fB\-oMaa\fP <\fIname\fP> +See \fB\-oMa\fP above for general remarks about the \fB\-oM\fP options. The \fB\-oMaa\fP +option sets the value of \fI$sender_host_authenticated\fP (the authenticator +name). +This option can be used with \fB\-bh\fP and \fB\-bs\fP to set up an +authenticated SMTP session without actually using the SMTP AUTH command. +.TP 10 +\fB\-oMai\fP <\fIstring\fP> +See \fB\-oMa\fP above for general remarks about the \fB\-oM\fP options. The \fB\-oMai\fP +option sets the value of \fI$authenticated_id\fP (the id that was authenticated). +This overrides the default value (the caller's login id, except with \fB\-bh\fP, +where there is no default) for messages from local sources. +.TP 10 +\fB\-oMas\fP <\fIaddress\fP> +See \fB\-oMa\fP above for general remarks about the \fB\-oM\fP options. The \fB\-oMas\fP +option sets the authenticated sender value in \fI$authenticated_sender\fP. It +overrides the sender address that is created from the caller's login id for +messages from local sources, except when \fB\-bh\fP is used, when there is no +default. For both \fB\-bh\fP and \fB\-bs\fP, an authenticated sender that is +specified on a MAIL command overrides this value. +.TP 10 +\fB\-oMi\fP <\fIinterface address\fP> +See \fB\-oMa\fP above for general remarks about the \fB\-oM\fP options. The \fB\-oMi\fP +option sets the IP interface address value. A port number may be included, +using the same syntax as for \fB\-oMa\fP. The interface address is placed in +\fI$received_ip_address\fP and the port number, if present, in \fI$received_port\fP. +.TP 10 +\fB\-oMm\fP <\fImessage reference\fP> +See \fB\-oMa\fP above for general remarks about the \fB\-oM\fP options. The \fB\-oMm\fP +option sets the message reference, e.g. message\-id, and is logged during +delivery. This is useful when some kind of audit trail is required to tie +messages together. The format of the message reference is checked and will +abort if the format is invalid. The option will only be accepted if exim is +running in trusted mode, not as any regular user. +.sp +The best example of a message reference is when Exim sends a bounce message. +The message reference is the message\-id of the original message for which Exim +is sending the bounce. +.TP 10 +\fB\-oMr\fP <\fIprotocol name\fP> +See \fB\-oMa\fP above for general remarks about the \fB\-oM\fP options. The \fB\-oMr\fP +option sets the received protocol value that is stored in +\fI$received_protocol\fP. However, it does not apply (and is ignored) when \fB\-bh\fP +or \fB\-bs\fP is used. For \fB\-bh\fP, the protocol is forced to one of the standard +SMTP protocol names. For \fB\-bs\fP, the protocol is always "local\-" followed by +one of those same names. For \fB\-bS\fP (batched SMTP) however, the protocol can +be set by \fB\-oMr\fP. Repeated use of this option is not supported. +.TP 10 +\fB\-oMs\fP <\fIhost name\fP> +See \fB\-oMa\fP above for general remarks about the \fB\-oM\fP options. The \fB\-oMs\fP +option sets the sender host name in \fI$sender_host_name\fP. When this option is +present, Exim does not attempt to look up a host name from an IP address; it +uses the name it is given. +.TP 10 +\fB\-oMt\fP <\fIident string\fP> +See \fB\-oMa\fP above for general remarks about the \fB\-oM\fP options. The \fB\-oMt\fP +option sets the sender ident value in \fI$sender_ident\fP. The default setting for +local callers is the login id of the calling process, except when \fB\-bh\fP is +used, when there is no default. +.TP 10 +\fB\-om\fP +In Sendmail, this option means "me too", indicating that the sender of a +message should receive a copy of the message if the sender appears in an alias +expansion. Exim always does this, so the option does nothing. +.TP 10 +\fB\-oo\fP +This option is ignored. In Sendmail it specifies "old style headers", +whatever that means. +.TP 10 +\fB\-oP\fP <\fIpath\fP> +This option is useful only in conjunction with \fB\-bd\fP or \fB\-q\fP with a time +value. The option specifies the file to which the process id of the daemon is +written. When \fB\-oX\fP is used with \fB\-bd\fP, or when \fB\-q\fP with a time is used +without \fB\-bd\fP, this is the only way of causing Exim to write a pid file, +because in those cases, the normal pid file is not used. +.TP 10 +\fB\-or\fP <\fItime\fP> +This option sets a timeout value for incoming non\-SMTP messages. If it is not +set, Exim will wait forever for the standard input. The value can also be set +by the \fBreceive_timeout\fP option. +.TP 10 +\fB\-os\fP <\fItime\fP> +This option sets a timeout value for incoming SMTP messages. The timeout +applies to each SMTP command and block of data. The value can also be set by +the \fBsmtp_receive_timeout\fP option; it defaults to 5 minutes. +.TP 10 +\fB\-ov\fP +This option has exactly the same effect as \fB\-v\fP. +.TP 10 +\fB\-oX\fP <\fInumber or string\fP> +This option is relevant only when the \fB\-bd\fP (start listening daemon) option +is also given. It controls which ports and interfaces the daemon uses. When \fB\-oX\fP is used to start a daemon, no pid +file is written unless \fB\-oP\fP is also present to specify a pid filename. +.TP 10 +\fB\-pd\fP +This option applies when an embedded Perl interpreter is linked with Exim. It overrides the setting of the \fBperl_at_start\fP +option, forcing the starting of the interpreter to be delayed until it is +needed. +.TP 10 +\fB\-ps\fP +This option applies when an embedded Perl interpreter is linked with Exim. It overrides the setting of the \fBperl_at_start\fP +option, forcing the starting of the interpreter to occur as soon as Exim is +started. +.TP 10 +\fB\-p\fP<\fIrval\fP>:<\fIsval\fP> +For compatibility with Sendmail, this option is equivalent to +.sp + \-oMr <\fIrval\fP> \-oMs <\fIsval\fP> +.sp +It sets the incoming protocol and host name (for trusted callers). The +host name and its colon can be omitted when only the protocol is to be set. +Note the Exim already has two private options, \fB\-pd\fP and \fB\-ps\fP, that refer +to embedded Perl. It is therefore impossible to set a protocol value of d +or s using this option (but that does not seem a real limitation). +Repeated use of this option is not supported. +.TP 10 +\fB\-q\fP +This option is normally restricted to admin users. However, there is a +configuration option called \fBprod_requires_admin\fP which can be set false to +relax this restriction (and also the same requirement for the \fB\-M\fP, \fB\-R\fP, +and \fB\-S\fP options). +.sp +If other commandline options do not specify an action, +the \fB\-q\fP option starts one queue runner process. This scans the queue of +waiting messages, and runs a delivery process for each one in turn. It waits +for each delivery process to finish before starting the next one. A delivery +process may not actually do any deliveries if the retry times for the addresses +have not been reached. Use \fB\-qf\fP (see below) if you want to override this. +.sp +If +the delivery process spawns other processes to deliver other messages down +passed SMTP connections, the queue runner waits for these to finish before +proceeding. +.sp +When all the queued messages have been considered, the original queue runner +process terminates. In other words, a single pass is made over the waiting +mail, one message at a time. Use \fB\-q\fP with a time (see below) if you want +this to be repeated periodically. +.sp +Exim processes the waiting messages in an unpredictable order. It isn't very +random, but it is likely to be different each time, which is all that matters. +If one particular message screws up a remote MTA, other messages to the same +MTA have a chance of getting through if they get tried first. +.sp +It is possible to cause the messages to be processed in lexical message id +order, which is essentially the order in which they arrived, by setting the +\fBqueue_run_in_order\fP option, but this is not recommended for normal use. +.TP 10 +\fB\-q\fP<\fIqflags\fP> +The \fB\-q\fP option may be followed by one or more flag letters that change its +behaviour. They are all optional, but if more than one is present, they must +appear in the correct order. Each flag is described in a separate item below. +.TP 10 +\fB\-qq...\fP +An option starting with \fB\-qq\fP requests a two\-stage queue run. In the first +stage, the queue is scanned as if the \fBqueue_smtp_domains\fP option matched +every domain. Addresses are routed, local deliveries happen, but no remote +transports are run. +.sp +The hints database that remembers which messages are waiting for specific hosts +is updated, as if delivery to those hosts had been deferred. After this is +complete, a second, normal queue scan happens, with routing and delivery taking +place as normal. Messages that are routed to the same host should mostly be +delivered down a single SMTP +connection because of the hints that were set up during the first queue scan. +This option may be useful for hosts that are connected to the Internet +intermittently. +.TP 10 +\fB\-q[q]i...\fP +If the \fIi\fP flag is present, the queue runner runs delivery processes only for +those messages that haven't previously been tried. (\fIi\fP stands for "initial +delivery".) This can be helpful if you are putting messages in the queue using +\fB\-odq\fP and want a queue runner just to process the new messages. +.TP 10 +\fB\-q[q][i]f...\fP +If one \fIf\fP flag is present, a delivery attempt is forced for each non\-frozen +message, whereas without \fIf\fP only those non\-frozen addresses that have passed +their retry times are tried. +.TP 10 +\fB\-q[q][i]ff...\fP +If \fIff\fP is present, a delivery attempt is forced for every message, whether +frozen or not. +.TP 10 +\fB\-q[q][i][f[f]]l\fP +The \fIl\fP (the letter "ell") flag specifies that only local deliveries are to +be done. If a message requires any remote deliveries, it remains in the queue +for later delivery. +.TP 10 +\fB\-q[q][i][f[f]][l][G<name>[/<time>]]]\fP +If the \fIG\fP flag and a name is present, the queue runner operates on the +queue with the given name rather than the default queue. +The name should not contain a \fI/\fP character. +For a periodic queue run (see below) +append to the name a slash and a time value. +.sp +If other commandline options specify an action, a \fI\-qG<name>\fP option +will specify a queue to operate on. +For example: +.sp + exim \-bp \-qGquarantine + mailq \-qGquarantine + exim \-qGoffpeak \-Rf @special.domain.example +.TP 10 +\fB\-q\fP<\fIqflags\fP> <\fIstart id\fP> <\fIend id\fP> +When scanning the queue, Exim can be made to skip over messages whose ids are +lexically less than a given value by following the \fB\-q\fP option with a +starting message id. For example: +.sp + exim \-q 0t5C6f\-0000c8\-00 +.sp +Messages that arrived earlier than 0t5C6f\-0000c8\-00 are not inspected. If a +second message id is given, messages whose ids are lexically greater than it +are also skipped. If the same id is given twice, for example, +.sp + exim \-q 0t5C6f\-0000c8\-00 0t5C6f\-0000c8\-00 +.sp +just one delivery process is started, for that message. This differs from +\fB\-M\fP in that retry data is respected, and it also differs from \fB\-Mc\fP in +that it counts as a delivery from a queue run. Note that the selection +mechanism does not affect the order in which the messages are scanned. There +are also other ways of selecting specific sets of messages for delivery in a +queue run \- see \fB\-R\fP and \fB\-S\fP. +.TP 10 +\fB\-q\fP<\fIqflags\fP><\fItime\fP> +When a time value is present, the \fB\-q\fP option causes Exim to run as a daemon, +starting a queue runner process at intervals specified by the given time value. This form of the +\fB\-q\fP option is commonly combined with the \fB\-bd\fP option, in which case a +single daemon process handles both functions. A common way of starting up a +combined daemon at system boot time is to use a command such as +.sp + /usr/exim/bin/exim \-bd \-q30m +.sp +Such a daemon listens for incoming SMTP calls, and also starts a queue runner +process every 30 minutes. +.sp +When a daemon is started by \fB\-q\fP with a time value, but without \fB\-bd\fP, no +pid file is written unless one is explicitly requested by the \fB\-oP\fP option. +.TP 10 +\fB\-qR\fP<\fIrsflags\fP> <\fIstring\fP> +This option is synonymous with \fB\-R\fP. It is provided for Sendmail +compatibility. +.TP 10 +\fB\-qS\fP<\fIrsflags\fP> <\fIstring\fP> +This option is synonymous with \fB\-S\fP. +.TP 10 +\fB\-R\fP<\fIrsflags\fP> <\fIstring\fP> +The <\fIrsflags\fP> may be empty, in which case the white space before the string +is optional, unless the string is \fIf\fP, \fIff\fP, \fIr\fP, \fIrf\fP, or \fIrff\fP, +which are the possible values for <\fIrsflags\fP>. White space is required if +<\fIrsflags\fP> is not empty. +.sp +This option is similar to \fB\-q\fP with no time value, that is, it causes Exim to +perform a single queue run, except that, when scanning the messages on the +queue, Exim processes only those that have at least one undelivered recipient +address containing the given string, which is checked in a case\-independent +way. If the <\fIrsflags\fP> start with \fIr\fP, <\fIstring\fP> is interpreted as a +regular expression; otherwise it is a literal string. +.sp +If you want to do periodic queue runs for messages with specific recipients, +you can combine \fB\-R\fP with \fB\-q\fP and a time value. For example: +.sp + exim \-q25m \-R @special.domain.example +.sp +This example does a queue run for messages with recipients in the given domain +every 25 minutes. Any additional flags that are specified with \fB\-q\fP are +applied to each queue run. +.sp +Once a message is selected for delivery by this mechanism, all its addresses +are processed. For the first selected message, Exim overrides any retry +information and forces a delivery attempt for each undelivered address. This +means that if delivery of any address in the first message is successful, any +existing retry information is deleted, and so delivery attempts for that +address in subsequently selected messages (which are processed without forcing) +will run. However, if delivery of any address does not succeed, the retry +information is updated, and in subsequently selected messages, the failing +address will be skipped. +.sp +If the <\fIrsflags\fP> contain \fIf\fP or \fIff\fP, the delivery forcing applies to +all selected messages, not just the first; frozen messages are included when +\fIff\fP is present. +.sp +The \fB\-R\fP option makes it straightforward to initiate delivery of all messages +to a given domain after a host has been down for some time. When the SMTP +command ETRN is accepted by its ACL, its default +effect is to run Exim with the \fB\-R\fP option, but it can be configured to run +an arbitrary command instead. +.TP 10 +\fB\-r\fP +This is a documented (for Sendmail) obsolete alternative name for \fB\-f\fP. +.TP 10 +\fB\-S\fP<\fIrsflags\fP> <\fIstring\fP> +This option acts like \fB\-R\fP except that it checks the string against each +message's sender instead of against the recipients. If \fB\-R\fP is also set, both +conditions must be met for a message to be selected. If either of the options +has \fIf\fP or \fIff\fP in its flags, the associated action is taken. +.TP 10 +\fB\-Tqt\fP <\fItimes\fP> +This is an option that is exclusively for use by the Exim testing suite. It is not +recognized when Exim is run normally. It allows for the setting up of explicit +"queue times" so that various warning/retry features can be tested. +.TP 10 +\fB\-t\fP +When Exim is receiving a locally\-generated, non\-SMTP message on its standard +input, the \fB\-t\fP option causes the recipients of the message to be obtained +from the \fITo:\fP, \fICc:\fP, and \fIBcc:\fP header lines in the message instead of +from the command arguments. The addresses are extracted before any rewriting +takes place and the \fIBcc:\fP header line, if present, is then removed. +.sp +If the command has any arguments, they specify addresses to which the message +is \fInot\fP to be delivered. That is, the argument addresses are removed from +the recipients list obtained from the headers. This is compatible with Smail 3 +and in accordance with the documented behaviour of several versions of +Sendmail, as described in man pages on a number of operating systems (e.g. +Solaris 8, IRIX 6.5, HP\-UX 11). However, some versions of Sendmail \fIadd\fP +argument addresses to those obtained from the headers, and the O'Reilly +Sendmail book documents it that way. Exim can be made to add argument addresses +instead of subtracting them by setting the option +\fBextract_addresses_remove_arguments\fP false. +.sp +If there are any \fBResent\-\fP header lines in the message, Exim extracts +recipients from all \fIResent\-To:\fP, \fIResent\-Cc:\fP, and \fIResent\-Bcc:\fP header +lines instead of from \fITo:\fP, \fICc:\fP, and \fIBcc:\fP. This is for compatibility +with Sendmail and other MTAs. (Prior to release 4.20, Exim gave an error if +\fB\-t\fP was used in conjunction with \fBResent\-\fP header lines.) +.sp +RFC 2822 talks about different sets of \fBResent\-\fP header lines (for when a +message is resent several times). The RFC also specifies that they should be +added at the front of the message, and separated by \fIReceived:\fP lines. It is +not at all clear how \fB\-t\fP should operate in the present of multiple sets, +nor indeed exactly what constitutes a "set". +In practice, it seems that MUAs do not follow the RFC. The \fBResent\-\fP lines +are often added at the end of the header, and if a message is resent more than +once, it is common for the original set of \fBResent\-\fP headers to be renamed as +\fBX\-Resent\-\fP when a new set is added. This removes any possible ambiguity. +.TP 10 +\fB\-ti\fP +This option is exactly equivalent to \fB\-t\fP \fB\-i\fP. It is provided for +compatibility with Sendmail. +.TP 10 +\fB\-tls\-on\-connect\fP +This option is available when Exim is compiled with TLS support. It forces all +incoming SMTP connections to behave as if the incoming port is listed in the +\fBtls_on_connect_ports\fP option. +.TP 10 +\fB\-U\fP +Sendmail uses this option for "initial message submission", and its +documentation states that in future releases, it may complain about +syntactically invalid messages rather than fixing them when this flag is not +set. Exim ignores this option. +.TP 10 +\fB\-v\fP +This option causes Exim to write information to the standard error stream, +describing what it is doing. In particular, it shows the log lines for +receiving and delivering a message, and if an SMTP connection is made, the SMTP +dialogue is shown. Some of the log lines shown may not actually be written to +the log if the setting of \fBlog_selector\fP discards them. Any relevant +selectors are shown with each log line. If none are shown, the logging is +unconditional. +.TP 10 +\fB\-x\fP +AIX uses \fB\-x\fP for a private purpose ("mail from a local mail program has +National Language Support extended characters in the body of the mail item"). +It sets \fB\-x\fP when calling the MTA from its \fBmail\fP command. Exim ignores +this option. +.TP 10 +\fB\-X\fP <\fIlogfile\fP> +This option is interpreted by Sendmail to cause debug information to be sent +to the named file. It is ignored by Exim. +.TP 10 +\fB\-z\fP <\fIlog\-line\fP> +This option writes its argument to Exim's logfile. +Use is restricted to administrators; the intent is for operational notes. +Quotes should be used to maintain a multi\-word item as a single argument, +under most shells. +.sp +. +.SH "SEE ALSO" +.rs +.sp +The full Exim specification, the Exim book, and the Exim wiki. diff --git a/doc/experimental-spec.txt b/doc/experimental-spec.txt new file mode 100644 index 0000000..84fd547 --- /dev/null +++ b/doc/experimental-spec.txt @@ -0,0 +1,989 @@ +From time to time, experimental features may be added to Exim. +While a feature is experimental, there will be a build-time +option whose name starts "EXPERIMENTAL_" that must be set in +order to include the feature. This file contains information +about experimental features, all of which are unstable and +liable to incompatible change. + + +Brightmail AntiSpam (BMI) support +-------------------------------------------------------------- + +Brightmail AntiSpam is a commercial package. Please see +http://www.brightmail.com for more information on +the product. For the sake of clarity, we'll refer to it as +"BMI" from now on. + + +0) BMI concept and implementation overview + +In contrast to how spam-scanning with SpamAssassin is +implemented in exiscan-acl, BMI is more suited for per +-recipient scanning of messages. However, each messages is +scanned only once, but multiple "verdicts" for multiple +recipients can be returned from the BMI server. The exiscan +implementation passes the message to the BMI server just +before accepting it. It then adds the retrieved verdicts to +the messages header file in the spool. These verdicts can then +be queried in routers, where operation is per-recipient +instead of per-message. To use BMI, you need to take the +following steps: + + 1) Compile Exim with BMI support + 2) Set up main BMI options (top section of Exim config file) + 3) Set up ACL control statement (ACL section of the config + file) + 4) Set up your routers to use BMI verdicts (routers section + of the config file). + 5) (Optional) Set up per-recipient opt-in information. + +These four steps are explained in more details below. + +1) Adding support for BMI at compile time + + To compile with BMI support, you need to link Exim against + the Brightmail client SDK, consisting of a library + (libbmiclient_single.so) and a header file (bmi_api.h). + You'll also need to explicitly set a flag in the Makefile to + include BMI support in the Exim binary. Both can be achieved + with these lines in Local/Makefile: + + EXPERIMENTAL_BRIGHTMAIL=yes + CFLAGS=-I/path/to/the/dir/with/the/includefile + EXTRALIBS_EXIM=-L/path/to/the/dir/with/the/library -lbmiclient_single + + If you use other CFLAGS or EXTRALIBS_EXIM settings then + merge the content of these lines with them. + + Note for BMI6.x users: You'll also have to add -lxml2_single + to the EXTRALIBS_EXIM line. Users of 5.5x do not need to do + this. + + You should also include the location of + libbmiclient_single.so in your dynamic linker configuration + file (usually /etc/ld.so.conf) and run "ldconfig" + afterwards, or else the produced Exim binary will not be + able to find the library file. + + +2) Setting up BMI support in the Exim main configuration + + To enable BMI support in the main Exim configuration, you + should set the path to the main BMI configuration file with + the "bmi_config_file" option, like this: + + bmi_config_file = /opt/brightmail/etc/brightmail.cfg + + This must go into section 1 of Exim's configuration file (You + can put it right on top). If you omit this option, it + defaults to /opt/brightmail/etc/brightmail.cfg. + + Note for BMI6.x users: This file is in XML format in V6.xx + and its name is /opt/brightmail/etc/bmiconfig.xml. So BMI + 6.x users MUST set the bmi_config_file option. + + +3) Set up ACL control statement + + To optimize performance, it makes sense only to process + messages coming from remote, untrusted sources with the BMI + server. To set up a messages for processing by the BMI + server, you MUST set the "bmi_run" control statement in any + ACL for an incoming message. You will typically do this in + an "accept" block in the "acl_check_rcpt" ACL. You should + use the "accept" block(s) that accept messages from remote + servers for your own domain(s). Here is an example that uses + the "accept" blocks from Exim's default configuration file: + + + accept domains = +local_domains + endpass + verify = recipient + control = bmi_run + + accept domains = +relay_to_domains + endpass + verify = recipient + control = bmi_run + + If bmi_run is not set in any ACL during reception of the + message, it will NOT be passed to the BMI server. + + +4) Setting up routers to use BMI verdicts + + When a message has been run through the BMI server, one or + more "verdicts" are present. Different recipients can have + different verdicts. Each recipient is treated individually + during routing, so you can query the verdicts by recipient + at that stage. From Exim's view, a verdict can have the + following outcomes: + + o deliver the message normally + o deliver the message to an alternate location + o do not deliver the message + + To query the verdict for a recipient, the implementation + offers the following tools: + + + - Boolean router preconditions. These can be used in any + router. For a simple implementation of BMI, these may be + all that you need. The following preconditions are + available: + + o bmi_deliver_default + + This precondition is TRUE if the verdict for the + recipient is to deliver the message normally. If the + message has not been processed by the BMI server, this + variable defaults to TRUE. + + o bmi_deliver_alternate + + This precondition is TRUE if the verdict for the + recipient is to deliver the message to an alternate + location. You can get the location string from the + $bmi_alt_location expansion variable if you need it. See + further below. If the message has not been processed by + the BMI server, this variable defaults to FALSE. + + o bmi_dont_deliver + + This precondition is TRUE if the verdict for the + recipient is NOT to deliver the message to the + recipient. You will typically use this precondition in a + top-level blackhole router, like this: + + # don't deliver messages handled by the BMI server + bmi_blackhole: + driver = redirect + bmi_dont_deliver + data = :blackhole: + + This router should be on top of all others, so messages + that should not be delivered do not reach other routers + at all. If the message has not been processed by + the BMI server, this variable defaults to FALSE. + + + - A list router precondition to query if rules "fired" on + the message for the recipient. Its name is "bmi_rule". You + use it by passing it a colon-separated list of rule + numbers. You can use this condition to route messages that + matched specific rules. Here is an example: + + # special router for BMI rule #5, #8 and #11 + bmi_rule_redirect: + driver = redirect + bmi_rule = 5:8:11 + data = postmaster@mydomain.com + + + - Expansion variables. Several expansion variables are set + during routing. You can use them in custom router + conditions, for example. The following variables are + available: + + o $bmi_base64_verdict + + This variable will contain the BASE64 encoded verdict + for the recipient being routed. You can use it to add a + header to messages for tracking purposes, for example: + + localuser: + driver = accept + check_local_user + headers_add = X-Brightmail-Verdict: $bmi_base64_verdict + transport = local_delivery + + If there is no verdict available for the recipient being + routed, this variable contains the empty string. + + o $bmi_base64_tracker_verdict + + This variable will contain a BASE64 encoded subset of + the verdict information concerning the "rules" that + fired on the message. You can add this string to a + header, commonly named "X-Brightmail-Tracker". Example: + + localuser: + driver = accept + check_local_user + headers_add = X-Brightmail-Tracker: $bmi_base64_tracker_verdict + transport = local_delivery + + If there is no verdict available for the recipient being + routed, this variable contains the empty string. + + o $bmi_alt_location + + If the verdict is to redirect the message to an + alternate location, this variable will contain the + alternate location string returned by the BMI server. In + its default configuration, this is a header-like string + that can be added to the message with "headers_add". If + there is no verdict available for the recipient being + routed, or if the message is to be delivered normally, + this variable contains the empty string. + + o $bmi_deliver + + This is an additional integer variable that can be used + to query if the message should be delivered at all. You + should use router preconditions instead if possible. + + $bmi_deliver is '0': the message should NOT be delivered. + $bmi_deliver is '1': the message should be delivered. + + + IMPORTANT NOTE: Verdict inheritance. + The message is passed to the BMI server during message + reception, using the target addresses from the RCPT TO: + commands in the SMTP transaction. If recipients get expanded + or re-written (for example by aliasing), the new address(es) + inherit the verdict from the original address. This means + that verdicts also apply to all "child" addresses generated + from top-level addresses that were sent to the BMI server. + + +5) Using per-recipient opt-in information (Optional) + + The BMI server features multiple scanning "profiles" for + individual recipients. These are usually stored in a LDAP + server and are queried by the BMI server itself. However, + you can also pass opt-in data for each recipient from the + MTA to the BMI server. This is particularly useful if you + already look up recipient data in Exim anyway (which can + also be stored in a SQL database or other source). This + implementation enables you to pass opt-in data to the BMI + server in the RCPT ACL. This works by setting the + 'bmi_optin' modifier in a block of that ACL. If should be + set to a list of comma-separated strings that identify the + features which the BMI server should use for that particular + recipient. Ideally, you would use the 'bmi_optin' modifier + in the same ACL block where you set the 'bmi_run' control + flag. Here is an example that will pull opt-in data for each + recipient from a flat file called + '/etc/exim/bmi_optin_data'. + + The file format: + + user1@mydomain.com: <OPTIN STRING1>:<OPTIN STRING2> + user2@thatdomain.com: <OPTIN STRING3> + + + The example: + + accept domains = +relay_to_domains + endpass + verify = recipient + bmi_optin = ${lookup{$local_part@$domain}lsearch{/etc/exim/bmi_optin_data}} + control = bmi_run + + Of course, you can also use any other lookup method that + Exim supports, including LDAP, Postgres, MySQL, Oracle etc., + as long as the result is a list of colon-separated opt-in + strings. + + For a list of available opt-in strings, please contact your + Brightmail representative. + + + + +SRS (Sender Rewriting Scheme) Support +-------------------------------------------------------------- + +Exiscan currently includes SRS support via Miles Wilton's +libsrs_alt library. The current version of the supported +library is 0.5, there are reports of 1.0 working. + +In order to use SRS, you must get a copy of libsrs_alt from + +https://opsec.eu/src/srs/ + +(not the original source, which has disappeared.) + +Unpack the tarball, then refer to MTAs/README.EXIM +to proceed. You need to set + +EXPERIMENTAL_SRS=yes + +in your Local/Makefile. + + + +DCC Support +-------------------------------------------------------------- +Distributed Checksum Clearinghouse; http://www.rhyolite.com/dcc/ + +*) Building exim + +In order to build exim with DCC support add + +EXPERIMENTAL_DCC=yes + +to your Makefile. (Re-)build/install exim. exim -d should show +EXPERIMENTAL_DCC under "Support for". + + +*) Configuration + +In the main section of exim.cf add at least + dccifd_address = /usr/local/dcc/var/dccifd +or + dccifd_address = <ip> <port> + +In the DATA ACL you can use the new condition + dcc = * + +After that "$dcc_header" contains the X-DCC-Header. + +Return values are: + fail for overall "R", "G" from dccifd + defer for overall "T" from dccifd + accept for overall "A", "S" from dccifd + +dcc = */defer_ok works as for spamd. + +The "$dcc_result" variable contains the overall result from DCC +answer. There will an X-DCC: header added to the mail. + +Usually you'll use + defer !dcc = * +to greylist with DCC. + +If you set, in the main section, + dcc_direct_add_header = true +then the dcc header will be added "in deep" and if the spool +file was already written it gets removed. This forces Exim to +write it again if needed. This helps to get the DCC Header +through to eg. SpamAssassin. + +If you want to pass even more headers in the middle of the +DATA stage you can set + $acl_m_dcc_add_header +to tell the DCC routines to add more information; eg, you might set +this to some results from ClamAV. Be careful. Header syntax is +not checked and is added "as is". + +In case you've troubles with sites sending the same queue items from several +hosts and fail to get through greylisting you can use +$acl_m_dcc_override_client_ip + +Setting $acl_m_dcc_override_client_ip to an IP address overrides the default +of $sender_host_address. eg. use the following ACL in DATA stage: + + warn set acl_m_dcc_override_client_ip = \ + ${lookup{$sender_helo_name}nwildlsearch{/etc/mail/multipleip_sites}{$value}{}} + condition = ${if def:acl_m_dcc_override_client_ip} + log_message = dbg: acl_m_dcc_override_client_ip set to \ + $acl_m_dcc_override_client_ip + +Then set something like +# cat /etc/mail/multipleip_sites +mout-xforward.gmx.net 82.165.159.12 +mout.gmx.net 212.227.15.16 + +Use a reasonable IP. eg. one the sending cluster actually uses. + + + +DMARC Support +-------------------------------------------------------------- + +DMARC combines feedback from SPF, DKIM, and header From: in order +to attempt to provide better indicators of the authenticity of an +email. This document does not explain the fundamentals, you +should read and understand how it works by visiting the website at +http://www.dmarc.org/. + +DMARC support is added via the libopendmarc library. Visit: + + http://sourceforge.net/projects/opendmarc/ + +to obtain a copy, or find it in your favorite rpm package +repository. If building from source, this description assumes +that headers will be in /usr/local/include, and that the libraries +are in /usr/local/lib. + +1. To compile Exim with DMARC support, you must first enable SPF. +Please read the Local/Makefile comments on enabling the SUPPORT_SPF +feature. You must also have DKIM support, so you cannot set the +DISABLE_DKIM feature. Once both of those conditions have been met +you can enable DMARC in Local/Makefile: + +EXPERIMENTAL_DMARC=yes +LDFLAGS += -lopendmarc +# CFLAGS += -I/usr/local/include +# LDFLAGS += -L/usr/local/lib + +The first line sets the feature to include the correct code, and +the second line says to link the libopendmarc libraries into the +exim binary. The commented out lines should be uncommented if you +built opendmarc from source and installed in the default location. +Adjust the paths if you installed them elsewhere, but you do not +need to uncomment them if an rpm (or you) installed them in the +package controlled locations (/usr/include and /usr/lib). + + +2. Use the following global settings to configure DMARC: + +Required: +dmarc_tld_file Defines the location of a text file of valid + top level domains the opendmarc library uses + during domain parsing. Maintained by Mozilla, + the most current version can be downloaded + from a link at http://publicsuffix.org/list/. + See also util/renew-opendmarc-tlds.sh script. + +Optional: +dmarc_history_file Defines the location of a file to log results + of dmarc verification on inbound emails. The + contents are importable by the opendmarc tools + which will manage the data, send out DMARC + reports, and expire the data. Make sure the + directory of this file is writable by the user + exim runs as. + +dmarc_forensic_sender Alternate email address to use when sending a + forensic report detailing alignment failures + if a sender domain's dmarc record specifies it + and you have configured Exim to send them. + + If set, this is expanded and used for the + From: header line; the address is extracted + from it and used for the envelope from. + If not set, the From: header is expanded from + the dsn_from option, and <> is used for the + envelope from. + + Default: unset. + + +3. By default, the DMARC processing will run for any remote, +non-authenticated user. It makes sense to only verify DMARC +status of messages coming from remote, untrusted sources. You can +use standard conditions such as hosts, senders, etc, to decide that +DMARC verification should *not* be performed for them and disable +DMARC with a control setting: + + control = dmarc_disable_verify + +A DMARC record can also specify a "forensic address", which gives +exim an email address to submit reports about failed alignment. +Exim does not do this by default because in certain conditions it +results in unintended information leakage (what lists a user might +be subscribed to, etc). You must configure exim to submit forensic +reports to the owner of the domain. If the DMARC record contains a +forensic address and you specify the control statement below, then +exim will send these forensic emails. It's also advised that you +configure a dmarc_forensic_sender because the default sender address +construction might be inadequate. + + control = dmarc_enable_forensic + +(AGAIN: You can choose not to send these forensic reports by simply +not putting the dmarc_enable_forensic control line at any point in +your exim config. If you don't tell it to send them, it will not +send them.) + +There are no options to either control. Both must appear before +the DATA acl. + + +4. You can now run DMARC checks in incoming SMTP by using the +"dmarc_status" ACL condition in the DATA ACL. You are required to +call the spf condition first in the ACLs, then the "dmarc_status" +condition. Putting this condition in the ACLs is required in order +for a DMARC check to actually occur. All of the variables are set +up before the DATA ACL, but there is no actual DMARC check that +occurs until a "dmarc_status" condition is encountered in the ACLs. + +The dmarc_status condition takes a list of strings on its +right-hand side. These strings describe recommended action based +on the DMARC check. To understand what the policy recommendations +mean, refer to the DMARC website above. Valid strings are: + + o accept The DMARC check passed and the library recommends + accepting the email. + o reject The DMARC check failed and the library recommends + rejecting the email. + o quarantine The DMARC check failed and the library recommends + keeping it for further inspection. + o none The DMARC check passed and the library recommends + no specific action, neutral. + o norecord No policy section in the DMARC record for this + sender domain. + o nofrom Unable to determine the domain of the sender. + o temperror Library error or dns error. + o off The DMARC check was disabled for this email. + +You can prefix each string with an exclamation mark to invert its +meaning, for example "!accept" will match all results but +"accept". The string list is evaluated left-to-right in a +short-circuit fashion. When a string matches the outcome of the +DMARC check, the condition succeeds. If none of the listed +strings matches the outcome of the DMARC check, the condition +fails. + +Of course, you can also use any other lookup method that Exim +supports, including LDAP, Postgres, MySQL, etc, as long as the +result is a list of colon-separated strings. + +Performing the check sets up information used by the +${authresults } expansion item. + +Several expansion variables are set before the DATA ACL is +processed, and you can use them in this ACL. The following +expansion variables are available: + + o $dmarc_status + This is a one word status indicating what the DMARC library + thinks of the email. It is a combination of the results of + DMARC record lookup and the SPF/DKIM/DMARC processing results + (if a DMARC record was found). The actual policy declared + in the DMARC record is in a separate expansion variable. + + o $dmarc_status_text + This is a slightly longer, human readable status. + + o $dmarc_used_domain + This is the domain which DMARC used to look up the DMARC + policy record. + + o $dmarc_domain_policy + This is the policy declared in the DMARC record. Valid values + are "none", "reject" and "quarantine". It is blank when there + is any error, including no DMARC record. + +A now-redundant variable $dmarc_ar_header has now been withdrawn. +Use the ${authresults } expansion instead. + + +5. How to enable DMARC advanced operation: +By default, Exim's DMARC configuration is intended to be +non-intrusive and conservative. To facilitate this, Exim will not +create any type of logging files without explicit configuration by +you, the admin. Nor will Exim send out any emails/reports about +DMARC issues without explicit configuration by you, the admin (other +than typical bounce messages that may come about due to ACL +processing or failure delivery issues). + +In order to log statistics suitable to be imported by the opendmarc +tools, you need to: +a. Configure the global setting dmarc_history_file. +b. Configure cron jobs to call the appropriate opendmarc history + import scripts and truncating the dmarc_history_file. + +In order to send forensic reports, you need to: +a. Configure the global setting dmarc_forensic_sender. +b. Configure, somewhere before the DATA ACL, the control option to + enable sending DMARC forensic reports. + + +6. Example usage: +(RCPT ACL) + warn domains = +local_domains + hosts = +local_hosts + control = dmarc_disable_verify + + warn !domains = +screwed_up_dmarc_records + control = dmarc_enable_forensic + + warn condition = (lookup if destined to mailing list) + set acl_m_mailing_list = 1 + +(DATA ACL) + warn dmarc_status = accept : none : off + !authenticated = * + log_message = DMARC DEBUG: $dmarc_status $dmarc_used_domain + + warn dmarc_status = !accept + !authenticated = * + log_message = DMARC DEBUG: '$dmarc_status' for $dmarc_used_domain + + warn dmarc_status = quarantine + !authenticated = * + set $acl_m_quarantine = 1 + # Do something in a transport with this flag variable + + deny condition = ${if eq{$dmarc_domain_policy}{reject}} + condition = ${if eq{$acl_m_mailing_list}{1}} + message = Messages from $dmarc_used_domain break mailing lists + + deny dmarc_status = reject + !authenticated = * + message = Message from $dmarc_used_domain failed sender's DMARC policy, REJECT + + warn add_header = :at_start:${authresults {$primary_hostname}} + + + +DSN extra information +--------------------- +If compiled with EXPERIMENTAL_DSN_INFO extra information will be added +to DSN fail messages ("bounces"), when available. The intent is to aid +tracing of specific failing messages, when presented with a "bounce" +complaint and needing to search logs. + + +The remote MTA IP address, with port number if nonstandard. +Example: + Remote-MTA: X-ip; [127.0.0.1]:587 +Rationale: + Several addresses may correspond to the (already available) + dns name for the remote MTA. + +The remote MTA connect-time greeting. +Example: + X-Remote-MTA-smtp-greeting: X-str; 220 the.local.host.name ESMTP Exim x.yz Tue, 2 Mar 1999 09:44:33 +0000 +Rationale: + This string sometimes presents the remote MTA's idea of its + own name, and sometimes identifies the MTA software. + +The remote MTA response to HELO or EHLO. +Example: + X-Remote-MTA-helo-response: X-str; 250-the.local.host.name Hello localhost [127.0.0.1] +Limitations: + Only the first line of a multiline response is recorded. +Rationale: + This string sometimes presents the remote MTA's view of + the peer IP connecting to it. + +The reporting MTA detailed diagnostic. +Example: + X-Exim-Diagnostic: X-str; SMTP error from remote mail server after RCPT TO:<d3@myhost.test.ex>: 550 hard error +Rationale: + This string sometimes give extra information over the + existing (already available) Diagnostic-Code field. + + +Note that non-RFC-documented field names and data types are used. + + +LMDB Lookup support +------------------- +LMDB is an ultra-fast, ultra-compact, crash-proof key-value embedded data store. +It is modeled loosely on the BerkeleyDB API. You should read about the feature +set as well as operation modes at https://symas.com/products/lightning-memory-mapped-database/ + +LMDB single key lookup support is provided by linking to the LMDB C library. +The current implementation does not support writing to the LMDB database. + +Visit https://github.com/LMDB/lmdb to download the library or find it in your +operating systems package repository. + +If building from source, this description assumes that headers will be in +/usr/local/include, and that the libraries are in /usr/local/lib. + +1. In order to build exim with LMDB lookup support add or uncomment + +EXPERIMENTAL_LMDB=yes + +to your Local/Makefile. (Re-)build/install exim. exim -d should show +Experimental_LMDB in the line "Support for:". + +EXPERIMENTAL_LMDB=yes +LDFLAGS += -llmdb +# CFLAGS += -I/usr/local/include +# LDFLAGS += -L/usr/local/lib + +The first line sets the feature to include the correct code, and +the second line says to link the LMDB libraries into the +exim binary. The commented out lines should be uncommented if you +built LMDB from source and installed in the default location. +Adjust the paths if you installed them elsewhere, but you do not +need to uncomment them if an rpm (or you) installed them in the +package controlled locations (/usr/include and /usr/lib). + +2. Create your LMDB files, you can use the mdb_load utility which is +part of the LMDB distribution our your favourite language bindings. + +3. Add the single key lookups to your exim.conf file, example lookups +are below. + +${lookup{$sender_address_domain}lmdb{/var/lib/baruwa/data/db/relaydomains.mdb}{$value}} +${lookup{$sender_address_domain}lmdb{/var/lib/baruwa/data/db/relaydomains.mdb}{$value}fail} +${lookup{$sender_address_domain}lmdb{/var/lib/baruwa/data/db/relaydomains.mdb}} + + +Queuefile transport +------------------- +Queuefile is a pseudo transport which does not perform final delivery. +It simply copies the exim spool files out of the spool directory into +an external directory retaining the exim spool format. + +The spool files can then be processed by external processes and then +requeued into exim spool directories for final delivery. +However, note carefully the warnings in the main documentation on +qpool file formats. + +The motivation/inspiration for the transport is to allow external +processes to access email queued by exim and have access to all the +information which would not be available if the messages were delivered +to the process in the standard email formats. + +The mailscanner package is one of the processes that can take advantage +of this transport to filter email. + +The transport can be used in the same way as the other existing transports, +i.e by configuring a router to route mail to a transport configured with +the queuefile driver. + +The transport only takes one option: + +* directory - This is used to specify the directory messages should be +copied to. Expanded. + +The generic transport options (body_only, current_directory, disable_logging, +debug_print, delivery_date_add, envelope_to_add, event_action, group, +headers_add, headers_only, headers_remove, headers_rewrite, home_directory, +initgroups, max_parallel, message_size_limit, rcpt_include_affixes, +retry_use_local_part, return_path, return_path_add, shadow_condition, +shadow_transport, transport_filter, transport_filter_timeout, user) are +ignored. + +Sample configuration: + +(Router) + +scan: + driver = accept + transport = scan + +(Transport) + +scan: + driver = queuefile + directory = /var/spool/baruwa-scanner/input + + +In order to build exim with Queuefile transport support add or uncomment + +EXPERIMENTAL_QUEUEFILE=yes + +to your Local/Makefile. (Re-)build/install exim. exim -d should show +Experimental_QUEUEFILE in the line "Support for:". + + +ARC support +----------- +Specification: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-11 +Note that this is not an RFC yet, so may change. + +ARC is intended to support the utility of SPF and DKIM in the presence of +intermediaries in the transmission path - forwarders and mailinglists - +by establishing a cryptographically-signed chain in headers. + +Normally one would only bother doing ARC-signing when functioning as +an intermediary. One might do verify for local destinations. + +ARC uses the notion of a "ADministrative Management Domain" (ADMD). +Described in RFC 5598 (section 2.3), this is essentially the set of +mail-handling systems that the mail transits. A label should be chosen to +identify the ADMD. Messages should be ARC-verified on entry to the ADMD, +and ARC-signed on exit from it. + + +Verification +-- +An ACL condition is provided to perform the "verifier actions" detailed +in section 6 of the above specification. It may be called from the DATA ACL +and succeeds if the result matches any of a given list. +It also records the highest ARC instance number (the chain size) +and verification result for later use in creating an Authentication-Results: +standard header. + + verify = arc/<acceptable_list> none:fail:pass + + add_header = :at_start:${authresults {<admd-identifier>}} + + Note that it would be wise to strip incoming messages of A-R headers + that claim to be from our own <admd-identifier>. + +There are four new variables: + + $arc_state One of pass, fail, none + $arc_state_reason (if fail, why) + $arc_domains colon-sep list of ARC chain domains, in chain order. + problematic elements may have empty list elements + $arc_oldest_pass lowest passing instance number of chain + +Example: + logwrite = oldest-p-ams: <${reduce {$lh_ARC-Authentication-Results:} \ + {} \ + {${if = {$arc_oldest_pass} \ + {${extract {i}{${extract {1}{;}{$item}}}}} \ + {$item} {$value}}} \ + }> + +Receive log lines for an ARC pass will be tagged "ARC". + + +Signing +-- +arc_sign = <admd-identifier> : <selector> : <privkey> [ : <options> ] +An option on the smtp transport, which constructs and prepends to the message +an ARC set of headers. The textually-first Authentication-Results: header +is used as a basis (you must have added one on entry to the ADMD). +Expanded as a whole; if unset, empty or forced-failure then no signing is done. +If it is set, all of the first three elements must be non-empty. + +The fourth element is optional, and if present consists of a comma-separated list +of options. The options implemented are + + timestamps Add a t= tag to the generated AMS and AS headers, with the + current time. + expire[=<val>] Add an x= tag to the generated AMS header, with an expiry time. + If the value <val> is an plain number it is used unchanged. + If it starts with a '+' then the following number is added + to the current time, as an offset in seconds. + If a value is not given it defaults to a one month offset. + +[As of writing, gmail insist that a t= tag on the AS is mandatory] + +Caveats: + * There must be an Authentication-Results header, presumably added by an ACL + while receiving the message, for the same ADMD, for arc_sign to succeed. + This requires careful coordination between inbound and outbound logic. + + Only one A-R header is taken account of. This is a limitation versus + the ARC spec (which says that all A-R headers from within the ADMD must + be used). + + * If passing a message to another system, such as a mailing-list manager + (MLM), between receipt and sending, be wary of manipulations to headers made + by the MLM. + + For instance, Mailman with REMOVE_DKIM_HEADERS==3 might improve + deliverability in a pre-ARC world, but that option also renames the + Authentication-Results header, which breaks signing. + + * Even if you use multiple DKIM keys for different domains, the ARC concept + should try to stick to one ADMD, so pick a primary domain and use that for + AR headers and outbound signing. + +Signing is not compatible with cutthrough delivery; any (before expansion) +value set for the option will result in cutthrough delivery not being +used via the transport in question. + + + + +REQUIRETLS support +------------------ +Ref: https://tools.ietf.org/html/draft-ietf-uta-smtp-require-tls-03 + +If compiled with EXPERIMENTAL_REQUIRETLS support is included for this +feature, where a REQUIRETLS option is added to the MAIL command. +The client may not retry in clear if the MAIL+REQUIRETLS fails (or was never +offered), and the server accepts an obligation that any onward transmission +by SMTP of the messages accepted will also use REQUIRETLS - or generate a +fail DSN. + +The Exim implementation includes +- a main-part option tls_advertise_requiretls; host list, default "*" +- an observability variable $requiretls returning yes/no +- an ACL "control = requiretls" modifier for setting the requirement +- Log lines and Received: headers capitalise the S in the protocol + element: "P=esmtpS" + +Differences from spec: +- we support upgrading the requirement for REQUIRETLS, including adding + it from cold, within an MTA. The spec only define the sourcing MUA + as being able to source the requirement, and makes no mention of upgrade. +- No support is coded for the RequireTLS header (which can be used + to annul DANE and/or STS policiy). [this can _almost_ be done in + transport option expansions, but not quite: it requires tha DANE-present + but STARTTLS-failing targets fallback to cleartext, which current DANE + coding specifically blocks] + +Note that REQUIRETLS is only advertised once a TLS connection is achieved +(in contrast to STARTTLS). If you want to check the advertising, do something +like "swaks -s 127.0.0.1 -tls -q HELO". + + + + +Early pipelining support +------------------------ +Ref: https://datatracker.ietf.org/doc/draft-harris-early-pipe/ + +If compiled with EXPERIMENTAL_PIPE_CONNECT support is included for this feature. +The server advertises the feature in its EHLO response, currently using the name +"X_PIPE_CONNECT" (this will change, some time in the future). +A client may cache this information, along with the rest of the EHLO response, +and use it for later connections. Those later ones can send esmtp commands before +a banner is received. + +Up to 1.5 roundtrip times can be taken out of cleartext connections, 2.5 on +STARTTLS connections. + +In combination with the traditional PIPELINING feature the following example +sequences are possible (among others): + +(client) (server) + +EHLO,MAIL,RCPT,DATA -> + <- banner,EHLO-resp,MAIL-ack,RCPT-ack,DATA-goahead +message-data -> +------ + +EHLO,MAIL,RCPT,BDAT -> + <- banner,EHLO-resp,MAIL-ack,RCPT-ack +message-data -> +------ + +EHLO,STARTTLS -> + <- banner,EHLO-resp,TLS-goahead +TLS1.2-client-hello -> + <- TLS-server-hello,cert,hello-done +client-Kex,change-cipher,finished -> + <- change-cipher,finished +EHLO,MAIL,RCPT,DATA -> + <- EHLO-resp,MAIL-ack,RCPT-ack,DATA-goahead + +------ +(tls-on-connect) +TLS1.2-client-hello -> + <- TLS-server-hello,cert,hello-done +client-Kex,change-cipher,finished -> + <- change-cipher,finshed + <- banner +EHLO,MAIL,RCPT,DATA -> + <- EHLO-resp,MAIL-ack,RCPT-ack,DATA-goahead + +Where the initial client packet is SMTP, it can combine with the TCP Fast Open +feature and be sent in the TCP SYN. + + +A main-section option "pipelining_connect_advertise_hosts" (default: *) +and an smtp transport option "hosts_pipe_connect" (default: unset) +control the feature. + +If the "pipelining" log_selector is enabled, the "L" field in server <= +log lines has a period appended if the feature was advertised but not used; +or has an asterisk appended if the feature was used. In client => lines +the "L" field has an asterisk appended if the feature was used. + +The "retry_data_expire" option controls cache invalidation. +Entries are also rewritten (or cleared) if the adverised features +change. + + +NOTE: since the EHLO command must be constructed before the connection is +made it cannot depend on the interface IP address that will be used. +Transport configurations should be checked for this. An example avoidance: + + helo_data = ${if def:sending_ip_address \ + {${lookup dnsdb{>! ptr=$sending_ip_address} \ + {${sg{$value} {^([^!]*).*\$} {\$1}}} fail}} \ + {$primary_hostname}} + + + + +-------------------------------------------------------------- +End of file +-------------------------------------------------------------- diff --git a/doc/filter.txt b/doc/filter.txt new file mode 100644 index 0000000..c361acc --- /dev/null +++ b/doc/filter.txt @@ -0,0 +1,1725 @@ +Exim's interfaces to mail filtering + +Philip Hazel + +Copyright (c) 2014 University of Cambridge + +Revision 4.92 10 Feb 2019 PH + +------------------------------------------------------------------------------- + +TABLE OF CONTENTS + +1. Forwarding and filtering in Exim + + 1.1. Introduction + 1.2. Filter operation + 1.3. Testing a new filter file + 1.4. Installing a filter file + 1.5. Testing an installed filter file + 1.6. Details of filtering commands + +2. Sieve filter files + + 2.1. Recognition of Sieve filters + 2.2. Saving to specified folders + 2.3. Strings containing header names + 2.4. Exists test with empty list of headers + 2.5. Header test with invalid MIME encoding in header + 2.6. Address test for multiple addresses per header + 2.7. Semantics of keep + 2.8. Semantics of fileinto + 2.9. Semantics of redirect + 2.10. String arguments + 2.11. Number units + 2.12. RFC compliance + +3. Exim filter files + + 3.1. Format of Exim filter files + 3.2. Data values in filter commands + 3.3. String expansion + 3.4. Some useful general variables + 3.5. Header variables + 3.6. User variables + 3.7. Current directory + 3.8. Significant deliveries + 3.9. Filter commands + 3.10. The add command + 3.11. The deliver command + 3.12. The save command + 3.13. The pipe command + 3.14. Mail commands + 3.15. Logging commands + 3.16. The finish command + 3.17. The testprint command + 3.18. The fail command + 3.19. The freeze command + 3.20. The headers command + 3.21. Obeying commands conditionally + 3.22. String testing conditions + 3.23. Numeric testing conditions + 3.24. Testing for significant deliveries + 3.25. Testing for error messages + 3.26. Testing a list of addresses + 3.27. Testing for personal mail + 3.28. Alias addresses for the personal condition + 3.29. Details of the personal condition + 3.30. Testing delivery status + 3.31. Multiple personal mailboxes + 3.32. Ignoring delivery errors + 3.33. Examples of Exim filter commands + + + +=============================================================================== +1. FORWARDING AND FILTERING IN EXIM + +This document describes the user interfaces to Exim's in-built mail filtering +facilities, and is copyright (c) University of Cambridge 2014. It corresponds +to Exim version 4.92. + + +1.1 Introduction +---------------- + +Most Unix mail transfer agents (programs that deliver mail) permit individual +users to specify automatic forwarding of their mail, usually by placing a list +of forwarding addresses in a file called .forward in their home directories. +Exim extends this facility by allowing the forwarding instructions to be a set +of rules rather than just a list of addresses, in effect providing ".forward +with conditions". Operating the set of rules is called filtering, and the file +that contains them is called a filter file. + +Exim supports two different kinds of filter file. An Exim filter contains +instructions in a format that is unique to Exim. A Sieve filter contains +instructions in the Sieve format that is defined by RFC 3028. As this is a +standard format, Sieve filter files may already be familiar to some users. +Sieve files should also be portable between different environments. However, +the Exim filtering facility contains more features (such as variable +expansion), and better integration with the host environment (such as the use +of external processes and pipes). + +The choice of which kind of filter to use can be left to the end-user, provided +that the system administrator has configured Exim appropriately for both kinds +of filter. However, if interoperability is important, Sieve is the only choice. + +The ability to use filtering or traditional forwarding has to be enabled by the +system administrator, and some of the individual facilities can be separately +enabled or disabled. A local document should be provided to describe exactly +what has been enabled. In the absence of this, consult your system +administrator. + +This document describes how to use a filter file and the format of its +contents. It is intended for use by end-users. Both Sieve filters and Exim +filters are covered. However, for Sieve filters, only issues that relate to the +Exim implementation are discussed, since Sieve itself is described elsewhere. + +The contents of traditional .forward files are not described here. They +normally contain just a list of addresses, file names, or pipe commands, +separated by commas or newlines, but other types of item are also available. +The full details can be found in the chapter on the redirect router in the Exim +specification, which also describes how the system administrator can set up and +control the use of filtering. + + +1.2 Filter operation +-------------------- + +It is important to realize that, in Exim, no deliveries are actually made while +a filter or traditional .forward file is being processed. Running a filter or +processing a traditional .forward file sets up future delivery operations, but +does not carry them out. + +The result of filter or .forward file processing is a list of destinations to +which a message should be delivered. The deliveries themselves take place +later, along with all other deliveries for the message. This means that it is +not possible to test for successful deliveries while filtering. It also means +that any duplicate addresses that are generated are dropped, because Exim never +delivers the same message to the same address more than once. + + +1.3 Testing a new filter file +----------------------------- + +Filter files, especially the more complicated ones, should always be tested, as +it is easy to make mistakes. Exim provides a facility for preliminary testing +of a filter file before installing it. This tests the syntax of the file and +its basic operation, and can also be used with traditional .forward files. + +Because a filter can do tests on the content of messages, a test message is +required. Suppose you have a new filter file called myfilter and a test message +in a file called test-message. Assuming that Exim is installed with the +conventional path name /usr/sbin/sendmail (some operating systems use /usr/lib/ +sendmail), the following command can be used: + +/usr/sbin/sendmail -bf myfilter <test-message + +The -bf option tells Exim that the following item on the command line is the +name of a filter file that is to be tested. There is also a -bF option, which +is similar, but which is used for testing system filter files, as opposed to +user filter files, and which is therefore of use only to the system +administrator. + +The test message is supplied on the standard input. If there are no +message-dependent tests in the filter, an empty file (/dev/null) can be used. A +supplied message must start with header lines or the "From " message separator +line that is found in many multi-message folder files. Note that blank lines at +the start terminate the header lines. A warning is given if no header lines are +read. + +The result of running this command, provided no errors are detected in the +filter file, is a list of the actions that Exim would try to take if presented +with the message for real. For example, for an Exim filter, the output + +Deliver message to: gulliver@lilliput.fict.example +Save message to: /home/lemuel/mail/archive + +means that one copy of the message would be sent to +gulliver@lilliput.fict.example, and another would be added to the file /home/ +lemuel/mail/archive, if all went well. + +The actions themselves are not attempted while testing a filter file in this +way; there is no check, for example, that any forwarding addresses are valid. +For an Exim filter, if you want to know why a particular action is being taken, +add the -v option to the command. This causes Exim to output the results of any +conditional tests and to indent its output according to the depth of nesting of +if commands. Further additional output from a filter test can be generated by +the testprint command, which is described below. + +When Exim is outputting a list of the actions it would take, if any text +strings are included in the output, non-printing characters therein are +converted to escape sequences. In particular, if any text string contains a +newline character, this is shown as "\n" in the testing output. + +When testing a filter in this way, Exim makes up an "envelope" for the message. +The recipient is by default the user running the command, and so is the sender, +but the command can be run with the -f option to supply a different sender. For +example, + +/usr/sbin/sendmail -bf myfilter \ + -f islington@never.where <test-message + +Alternatively, if the -f option is not used, but the first line of the supplied +message is a "From " separator from a message folder file (not the same thing +as a From: header line), the sender is taken from there. If -f is present, the +contents of any "From " line are ignored. + +The "return path" is the same as the envelope sender, unless the message +contains a Return-path: header, in which case it is taken from there. You need +not worry about any of this unless you want to test out features of a filter +file that rely on the sender address or the return path. + +It is possible to change the envelope recipient by specifying further options. +The -bfd option changes the domain of the recipient address, while the -bfl +option changes the "local part", that is, the part before the @ sign. An +adviser could make use of these to test someone else's filter file. + +The -bfp and -bfs options specify the prefix or suffix for the local part. +These are relevant only when support for multiple personal mailboxes is +implemented; see the description in section 3.31 below. + + +1.4 Installing a filter file +---------------------------- + +A filter file is normally installed under the name .forward in your home +directory - it is distinguished from a conventional .forward file by its first +line (described below). However, the file name is configurable, and some system +administrators may choose to use some different name or location for filter +files. + + +1.5 Testing an installed filter file +------------------------------------ + +Testing a filter file before installation cannot find every potential problem; +for example, it does not actually run commands to which messages are piped. +Some "live" tests should therefore also be done once a filter is installed. + +If at all possible, test your filter file by sending messages from some other +account. If you send a message to yourself from the filtered account, and +delivery fails, the error message will be sent back to the same account, which +may cause another delivery failure. It won't cause an infinite sequence of such +messages, because delivery failure messages do not themselves generate further +messages. However, it does mean that the failure won't be returned to you, and +also that the postmaster will have to investigate the stuck message. + +If you have to test an Exim filter from the same account, a sensible precaution +is to include the line + +if error_message then finish endif + +as the first filter command, at least while testing. This causes filtering to +be abandoned for a delivery failure message, and since no destinations are +generated, the message goes on to be delivered to the original address. Unless +there is a good reason for not doing so, it is recommended that the above test +be left in all Exim filter files. (This does not apply to Sieve files.) + + +1.6 Details of filtering commands +--------------------------------- + +The filtering commands for Sieve and Exim filters are completely different in +syntax and semantics. The Sieve mechanism is defined in RFC 3028; in the next +chapter we describe how it is integrated into Exim. The subsequent chapter +covers Exim filtering commands in detail. + + + +=============================================================================== +2. SIEVE FILTER FILES + +The code for Sieve filtering in Exim was contributed by Michael Haardt, and +most of the content of this chapter is taken from the notes he provided. Since +Sieve is an extensible language, it is important to understand "Sieve" in this +context as "the specific implementation of Sieve for Exim". + +This chapter does not contain a description of Sieve, since that can be found +in RFC 3028, which should be read in conjunction with these notes. + +The Exim Sieve implementation offers the core as defined by RFC 3028, +comparison tests, the subaddress parameter, the copy, envelope, fileinto, +notify, and vacation extensions, but not the reject extension. Exim does not +support message delivery notifications (MDNs), so adding it just to the Sieve +filter (as required for reject) makes little sense. + +In order for Sieve to work properly in Exim, the system administrator needs to +make some adjustments to the Exim configuration. These are described in the +chapter on the redirect router in the full Exim specification. + + +2.1 Recognition of Sieve filters +-------------------------------- + +A filter file is interpreted as a Sieve filter if its first line is + +# Sieve filter + +This is what distinguishes it from a conventional .forward file or an Exim +filter file. + + +2.2 Saving to specified folders +------------------------------- + +If the system administrator has set things up as suggested in the Exim +specification, and you use keep or fileinto to save a mail into a folder, +absolute files are stored where specified, relative files are stored relative +to $home, and inbox goes to the standard mailbox location. + + +2.3 Strings containing header names +----------------------------------- + +RFC 3028 does not specify what happens if a string denoting a header field does +not contain a valid header name, for example, it contains a colon. This +implementation generates an error instead of ignoring the header field in order +to ease script debugging, which fits in with the common picture of Sieve. + + +2.4 Exists test with empty list of headers +------------------------------------------ + +The exists test succeeds only if all the specified headers exist. RFC 3028 does +not explicitly specify what happens on an empty list of headers. This +implementation evaluates that condition as true, interpreting the RFC in a +strict sense. + + +2.5 Header test with invalid MIME encoding in header +---------------------------------------------------- + +Some MUAs process invalid base64 encoded data, generating junk. Others ignore +junk after seeing an equal sign in base64 encoded data. RFC 2047 does not +specify how to react in this case, other than stating that a client must not +forbid to process a message for that reason. RFC 2045 specifies that invalid +data should be ignored (apparently looking at end of line characters). It also +specifies that invalid data may lead to rejecting messages containing them (and +there it appears to talk about true encoding violations), which is a clear +contradiction to ignoring them. + +RFC 3028 does not specify how to process incorrect MIME words. This +implementation treats them literally, as it does if the word is correct but its +character set cannot be converted to UTF-8. + + +2.6 Address test for multiple addresses per header +-------------------------------------------------- + +A header may contain multiple addresses. RFC 3028 does not explicitly specify +how to deal with them, but since the address test checks if anything matches +anything else, matching one address suffices to satisfy the condition. That +makes it impossible to test if a header contains a certain set of addresses and +no more, but it is more logical than letting the test fail if the header +contains an additional address besides the one the test checks for. + + +2.7 Semantics of keep +--------------------- + +The keep command is equivalent to + +fileinto "inbox"; + +It saves the message and resets the implicit keep flag. It does not set the +implicit keep flag; there is no command to set it once it has been reset. + + +2.8 Semantics of fileinto +------------------------- + +RFC 3028 does not specify whether fileinto should try to create a mail folder +if it does not exist. This implementation allows the sysadmin to configure that +aspect using the appendfile transport options create_directory, create_file, +and file_must_exist. See the appendfile transport in the Exim specification for +details. + + +2.9 Semantics of redirect +------------------------- + +Sieve scripts are supposed to be interoperable between servers, so this +implementation does not allow mail to be redirected to unqualified addresses, +because the domain would depend on the system being used. On systems with +virtual mail domains, the default domain is probably not what the user expects +it to be. + + +2.10 String arguments +--------------------- + +There has been confusion if the string arguments to require are to be matched +case-sensitively or not. This implementation matches them with the match type +:is (default, see section 2.7.1 of the RFC) and the comparator i;ascii-casemap +(default, see section 2.7.3 of the RFC). The RFC defines the command defaults +clearly, so any different implementations violate RFC 3028. The same is valid +for comparator names, also specified as strings. + + +2.11 Number units +----------------- + +There is a mistake in RFC 3028: the suffix G denotes gibi-, not tebibyte. The +mistake is obvious, because RFC 3028 specifies G to denote 2^30 (which is gibi, +not tebi), and that is what this implementation uses as the scaling factor for +the suffix G. + + +2.12 RFC compliance +------------------- + +Exim requires the first line of a Sieve filter to be + +# Sieve filter + +Of course the RFC does not specify that line. Do not expect examples to work +without adding it, though. + +RFC 3028 requires the use of CRLF to terminate a line. The rationale was that +CRLF is universally used in network protocols to mark the end of the line. This +implementation does not embed Sieve in a network protocol, but uses Sieve +scripts as part of the Exim MTA. Since all parts of Exim use LF as the newline +character, this implementation does, too, by default, though the system +administrator may choose (at Exim compile time) to use CRLF instead. + +Exim violates RFC 2822, section 3.6.8, by accepting 8-bit header names, so this +implementation repeats this violation to stay consistent with Exim. This is in +preparation for UTF-8 data. + +Sieve scripts cannot contain NUL characters in strings, but mail headers could +contain MIME encoded NUL characters, which could never be matched by Sieve +scripts using exact comparisons. For that reason, this implementation extends +the Sieve quoted string syntax with \0 to describe a NUL character, violating \ +0 being the same as 0 in RFC 3028. Even without using \0, the following tests +are all true in this implementation. Implementations that use C-style strings +will only evaluate the first test as true. + +Subject: =?iso-8859-1?q?abc=00def + +header :contains "Subject" ["abc"] +header :contains "Subject" ["def"] +header :matches "Subject" ["abc?def"] + +Note that by considering Sieve to be an MUA, RFC 2047 can be interpreted in a +way that NUL characters truncating strings is allowed for Sieve +implementations, although not recommended. It is further allowed to use encoded +NUL characters in headers, but that's not recommended either. The above example +shows why. + +RFC 3028 states that if an implementation fails to convert a character set to +UTF-8, two strings cannot be equal if one contains octets greater than 127. +Assuming that all unknown character sets are one-byte character sets with the +lower 128 octets being US-ASCII is not sound, so this implementation violates +RFC 3028 and treats such MIME words literally. That way at least something +could be matched. + +The folder specified by fileinto must not contain the character sequence ".." +to avoid security problems. RFC 3028 does not specify the syntax of folders +apart from keep being equivalent to + +fileinto "INBOX"; + +This implementation uses inbox instead. + +Sieve script errors currently cause messages to be silently filed into inbox. +RFC 3028 requires that the user is notified of that condition. This may be +implemented in the future by adding a header line to mails that are filed into +inbox due to an error in the filter. + + + +=============================================================================== +3. EXIM FILTER FILES + +This chapter contains a full description of the contents of Exim filter files. + + +3.1 Format of Exim filter files +------------------------------- + +Apart from leading white space, the first text in an Exim filter file must be + +# Exim filter + +This is what distinguishes it from a conventional .forward file or a Sieve +filter file. If the file does not have this initial line (or the equivalent for +a Sieve filter), it is treated as a conventional .forward file, both when +delivering mail and when using the -bf testing mechanism. The white space in +the line is optional, and any capitalization may be used. Further text on the +same line is treated as a comment. For example, you could have + +# Exim filter <<== do not edit or remove this line! + +The remainder of the file is a sequence of filtering commands, which consist of +keywords and data values. For example, in the command + +deliver gulliver@lilliput.fict.example + +the keyword is "deliver" and the data value is +"gulliver@lilliput.fict.example". White space or line breaks separate the +components of a command, except in the case of conditions for the if command, +where round brackets (parentheses) also act as separators. Complete commands +are separated from each other by white space or line breaks; there are no +special terminators. Thus, several commands may appear on one line, or one +command may be spread over a number of lines. + +If the character # follows a separator anywhere in a command, everything from # +up to the next newline is ignored. This provides a way of including comments in +a filter file. + + +3.2 Data values in filter commands +---------------------------------- + +There are two ways in which a data value can be input: + + * If the text contains no white space, it can be typed verbatim. However, if + it is part of a condition, it must also be free of round brackets + (parentheses), as these are used for grouping in conditions. + + * Otherwise, text must be enclosed in double quotation marks. In this case, + the character \ (backslash) is treated as an "escape character" within the + string, causing the following character or characters to be treated + specially: + + \n is replaced by a newline + \r is replaced by a carriage return + \t is replaced by a tab + +Backslash followed by up to three octal digits is replaced by the character +specified by those digits, and "\x" followed by up to two hexadecimal digits is +treated similarly. Backslash followed by any other character is replaced by the +second character, so that in particular, "\"" becomes """ and "\\" becomes "\". +A data item enclosed in double quotes can be continued onto the next line by +ending the first line with a backslash. Any leading white space at the start of +the continuation line is ignored. + +In addition to the escape character processing that occurs when strings are +enclosed in quotes, most data values are also subject to string expansion (as +described in the next section), in which case the characters "$" and "\" are +also significant. This means that if a single backslash is actually required in +such a string, and the string is also quoted, "\\\\" has to be entered. + +The maximum permitted length of a data string, before expansion, is 1024 +characters. + + +3.3 String expansion +-------------------- + +Most data values are expanded before use. Expansion consists of replacing +substrings beginning with "$" with other text. The full expansion facilities +available in Exim are extensive. If you want to know everything that Exim can +do with strings, you should consult the chapter on string expansion in the Exim +documentation. + +In filter files, by far the most common use of string expansion is the +substitution of the contents of a variable. For example, the substring + +$reply_address + +is replaced by the address to which replies to the message should be sent. If +such a variable name is followed by a letter or digit or underscore, it must be +enclosed in curly brackets (braces), for example, + +${reply_address} + +If a "$" character is actually required in an expanded string, it must be +escaped with a backslash, and because backslash is also an escape character in +quoted input strings, it must be doubled in that case. The following two +examples illustrate two different ways of testing for a "$" character in a +message: + +if $message_body contains \$ then ... +if $message_body contains "\\$" then ... + +You can prevent part of a string from being expanded by enclosing it between +two occurrences of "\N". For example, + +if $message_body contains \N$$$$\N then ... + +tests for a run of four dollar characters. + + +3.4 Some useful general variables +--------------------------------- + +A complete list of the available variables is given in the Exim documentation. +This shortened list contains the ones that are most likely to be useful in +personal filter files: + +$body_linecount: The number of lines in the body of the message. + +$body_zerocount: The number of binary zero characters in the body of the +message. + +$home: In conventional configurations, this variable normally contains the +user's home directory. The system administrator can, however, change this. + +$local_part: The part of the email address that precedes the @ sign - normally +the user's login name. If support for multiple personal mailboxes is enabled +(see section 3.31 below) and a prefix or suffix for the local part was +recognized, it is removed from the string in this variable. + +$local_part_prefix: If support for multiple personal mailboxes is enabled (see +section 3.31 below), and a local part prefix was recognized, this variable +contains the prefix. Otherwise it contains an empty string. + +$local_part_suffix: If support for multiple personal mailboxes is enabled (see +section 3.31 below), and a local part suffix was recognized, this variable +contains the suffix. Otherwise it contains an empty string. + +$message_body: The initial portion of the body of the message. By default, up +to 500 characters are read into this variable, but the system administrator can +configure this to some other value. Newlines in the body are converted into +single spaces. + +$message_body_end: The final portion of the body of the message, formatted and +limited in the same way as $message_body. + +$message_body_size: The size of the body of the message, in bytes. + +$message_exim_id: The message's local identification string, which is unique +for each message handled by a single host. + +$message_headers: The header lines of the message, concatenated into a single +string, with newline characters between them. + +$message_size: The size of the entire message, in bytes. + +$original_local_part: When an address that arrived with the message is being +processed, this contains the same value as the variable $local_part. However, +if an address generated by an alias, forward, or filter file is being +processed, this variable contains the local part of the original address. + +$reply_address: The contents of the Reply-to: header, if the message has one; +otherwise the contents of the From: header. It is the address to which normal +replies to the message should be sent. + +$return_path: The return path - that is, the sender field that will be +transmitted as part of the message's envelope if the message is sent to another +host. This is the address to which delivery errors are sent. In many cases, +this variable has the same value as $sender_address, but if, for example, an +incoming message to a mailing list has been expanded, $return_path may have +been changed to contain the address of the list maintainer. + +$sender_address: The sender address that was received in the envelope of the +message. This is not necessarily the same as the contents of the From: or +Sender: header lines. For delivery error messages ("bounce messages") there is +no sender address, and this variable is empty. + +$tod_full: A full version of the time and date, for example: Wed, 18 Oct 1995 +09:51:40 +0100. The timezone is always given as a numerical offset from GMT. + +$tod_log: The time and date in the format used for writing Exim's log files, +without the timezone, for example: 1995-10-12 15:32:29. + +$tod_zone: The local timezone offset, for example: +0100. + + +3.5 Header variables +-------------------- + +There is a special set of expansion variables containing the header lines of +the message being processed. These variables have names beginning with $header_ +followed by the name of the header line, terminated by a colon. For example, + +$header_from: +$header_subject: + +The whole item, including the terminating colon, is replaced by the contents of +the message header line. If there is more than one header line with the same +name, their contents are concatenated. For header lines whose data consists of +a list of addresses (for example, From: and To:), a comma and newline is +inserted between each set of data. For all other header lines, just a newline +is used. + +Leading and trailing white space is removed from header line data, and if there +are any MIME "words" that are encoded as defined by RFC 2047 (because they +contain non-ASCII characters), they are decoded and translated, if possible, to +a local character set. Translation is attempted only on operating systems that +have the iconv() function. This makes the header line look the same as it would +when displayed by an MUA. The default character set is ISO-8859-1, but this can +be changed by means of the headers command (see below). + +If you want to see the actual characters that make up a header line, you can +specify $rheader_ instead of $header_. This inserts the "raw" header line, +unmodified. + +There is also an intermediate form, requested by $bheader_, which removes +leading and trailing space and decodes MIME "words", but does not do any +character translation. If an attempt to decode what looks superficially like a +MIME "word" fails, the raw string is returned. If decoding produces a binary +zero character, it is replaced by a question mark. + +The capitalization of the name following $header_ is not significant. Because +any printing character except colon may appear in the name of a message's +header (this is a requirement of RFC 2822, the document that describes the +format of a mail message) curly brackets must not be used in this case, as they +will be taken as part of the header name. Two shortcuts are allowed in naming +header variables: + + * The initiating $header_, $rheader_, or $bheader_ can be abbreviated to $h_, + $rh_, or $bh_, respectively. + + * The terminating colon can be omitted if the next character is white space. + The white space character is retained in the expanded string. However, this + is not recommended, because it makes it easy to forget the colon when it + really is needed. + +If the message does not contain a header of the given name, an empty string is +substituted. Thus it is important to spell the names of headers correctly. Do +not use $header_Reply_to when you really mean $header_Reply-to. + + +3.6 User variables +------------------ + +There are ten user variables with names $n0 - $n9 that can be incremented by +the add command (see section 3.10). These can be used for "scoring" messages in +various ways. If Exim is configured to run a "system filter" on every message, +the values left in these variables are copied into the variables $sn0 - $sn9 at +the end of the system filter, thus making them available to users' filter +files. How these values are used is entirely up to the individual installation. + + +3.7 Current directory +--------------------- + +The contents of your filter file should not make any assumptions about the +current directory. It is best to use absolute paths for file names; you can +normally make use of the $home variable to refer to your home directory. The +save command automatically inserts $home at the start of non-absolute paths. + + +3.8 Significant deliveries +-------------------------- + +When in the course of delivery a message is processed by a filter file, what +happens next, that is, after the filter file has been processed, depends on +whether or not the filter sets up any significant deliveries. If at least one +significant delivery is set up, the filter is considered to have handled the +entire delivery arrangements for the current address, and no further processing +of the address takes place. If, however, no significant deliveries are set up, +Exim continues processing the current address as if there were no filter file, +and typically sets up a delivery of a copy of the message into a local mailbox. +In particular, this happens in the special case of a filter file containing +only comments. + +The delivery commands deliver, save, and pipe are by default significant. +However, if such a command is preceded by the word "unseen", its delivery is +not considered to be significant. In contrast, other commands such as mail and +vacation do not set up significant deliveries unless preceded by the word +"seen". The following example commands set up significant deliveries: + +deliver jack@beanstalk.example +pipe $home/bin/mymailscript +seen mail subject "message discarded" +seen finish + +The following example commands do not set up significant deliveries: + +unseen deliver jack@beanstalk.example +unseen pipe $home/bin/mymailscript +mail subject "message discarded" +finish + + +3.9 Filter commands +------------------- + +The filter commands that are described in subsequent sections are listed below, +with the section in which they are described in brackets: + +add increment a user variable (section 3.10) +deliver deliver to an email address (section 3.11) +fail force delivery failure (sysadmin use) (section 3.18) +finish end processing (section 3.16) +freeze freeze message (sysadmin use) (section 3.19) +headers set the header character set (section 3.20) +if test condition(s) (section 3.21) +logfile define log file (section 3.15) +logwrite write to log file (section 3.15) +mail send a reply message (section 3.14) +pipe pipe to a command (section 3.13) +save save to a file (section 3.12) +testprint print while testing (section 3.17) +vacation tailored form of mail (section 3.14) + +The headers command has additional parameters that can be used only in a system +filter. The fail and freeze commands are available only when Exim's filtering +facilities are being used as a system filter, and are therefore usable only by +the system administrator and not by ordinary users. They are mentioned only +briefly in this document; for more information, see the main Exim +specification. + + +3.10 The add command +-------------------- + + add <number> to <user variable> +e.g. add 2 to n3 + +There are 10 user variables of this type, with names $n0 - $n9. Their values +can be obtained by the normal expansion syntax (for example $n3) in other +commands. At the start of filtering, these variables all contain zero. Both +arguments of the add command are expanded before use, making it possible to add +variables to each other. Subtraction can be obtained by adding negative +numbers. + + +3.11 The deliver command +------------------------ + + deliver <mail address> +e.g. deliver "Dr Livingstone <David@somewhere.africa.example>" + +This command provides a forwarding operation. The delivery that it sets up is +significant unless the command is preceded by "unseen" (see section 3.8). The +message is sent on to the given address, exactly as happens if the address had +appeared in a traditional .forward file. If you want to deliver the message to +a number of different addresses, you can use more than one deliver command +(each one may have only one address). However, duplicate addresses are +discarded. + +To deliver a copy of the message to your normal mailbox, your login name can be +given as the address. Once an address has been processed by the filtering +mechanism, an identical generated address will not be so processed again, so +doing this does not cause a loop. + +However, if you have a mail alias, you should not refer to it here. For +example, if the mail address L.Gulliver is aliased to lg303 then all references +in Gulliver's .forward file should be to lg303. A reference to the alias will +not work for messages that are addressed to that alias, since, like .forward +file processing, aliasing is performed only once on an address, in order to +avoid looping. + +Following the new address, an optional second address, preceded by "errors_to" +may appear. This changes the address to which delivery errors on the forwarded +message will be sent. Instead of going to the message's original sender, they +go to this new address. For ordinary users, the only value that is permitted +for this address is the user whose filter file is being processed. For example, +the user lg303 whose mailbox is in the domain lilliput.example could have a +filter file that contains + +deliver jon@elsewhere.example errors_to lg303@lilliput.example + +Clearly, using this feature makes sense only in situations where not all +messages are being forwarded. In particular, bounce messages must not be +forwarded in this way, as this is likely to create a mail loop if something +goes wrong. + + +3.12 The save command +--------------------- + + save <file name> +e.g. save $home/mail/bookfolder + +This command specifies that a copy of the message is to be appended to the +given file (that is, the file is to be used as a mail folder). The delivery +that save sets up is significant unless the command is preceded by "unseen" +(see section 3.8). + +More than one save command may be obeyed; each one causes a copy of the message +to be written to its argument file, provided they are different (duplicate save +commands are ignored). + +If the file name does not start with a / character, the contents of the $home +variable are prepended, unless it is empty, or the system administrator has +disabled this feature. In conventional configurations, this variable is +normally set in a user filter to the user's home directory, but the system +administrator may set it to some other path. In some configurations, $home may +be unset, or prepending may be disabled, in which case a non-absolute path name +may be generated. Such configurations convert this to an absolute path when the +delivery takes place. In a system filter, $home is never set. + +The user must of course have permission to write to the file, and the writing +of the file takes place in a process that is running as the user, under the +user's primary group. Any secondary groups to which the user may belong are not +normally taken into account, though the system administrator can configure Exim +to set them up. In addition, the ability to use this command at all is +controlled by the system administrator - it may be forbidden on some systems. + +An optional mode value may be given after the file name. The value for the mode +is interpreted as an octal number, even if it does not begin with a zero. For +example: + +save /some/folder 640 + +This makes it possible for users to override the system-wide mode setting for +file deliveries, which is normally 600. If an existing file does not have the +correct mode, it is changed. + +An alternative form of delivery may be enabled on your system, in which each +message is delivered into a new file in a given directory. If this is the case, +this functionality can be requested by giving the directory name terminated by +a slash after the save command, for example + +save separated/messages/ + +There are several different formats for such deliveries; check with your system +administrator or local documentation to find out which (if any) are available +on your system. If this functionality is not enabled, the use of a path name +ending in a slash causes an error. + + +3.13 The pipe command +--------------------- + + pipe <command> +e.g. pipe "$home/bin/countmail $sender_address" + +This command specifies that the message is to be delivered to the specified +command using a pipe. The delivery that it sets up is significant unless the +command is preceded by "unseen" (see section 3.8). Remember, however, that no +deliveries are done while the filter is being processed. All deliveries happen +later on. Therefore, the result of running the pipe is not available to the +filter. + +When the deliveries are done, a separate process is run, and a copy of the +message is passed on its standard input. The process runs as the user, under +the user's primary group. Any secondary groups to which the user may belong are +not normally taken into account, though the system administrator can configure +Exim to set them up. More than one pipe command may appear; each one causes a +copy of the message to be written to its argument pipe, provided they are +different (duplicate pipe commands are ignored). + +When the time comes to transport the message, the command supplied to pipe is +split up by Exim into a command name and a number of arguments. These are +delimited by white space except for arguments enclosed in double quotes, in +which case backslash is interpreted as an escape, or in single quotes, in which +case no escaping is recognized. Note that as the whole command is normally +supplied in double quotes, a second level of quoting is required for internal +double quotes. For example: + +pipe "$home/myscript \"size is $message_size\"" + +String expansion is performed on the separate components after the line has +been split up, and the command is then run directly by Exim; it is not run +under a shell. Therefore, substitution cannot change the number of arguments, +nor can quotes, backslashes or other shell metacharacters in variables cause +confusion. + +Documentation for some programs that are normally run via this kind of pipe +often suggest that the command should start with + +IFS=" " + +This is a shell command, and should not be present in Exim filter files, since +it does not normally run the command under a shell. + +However, there is an option that the administrator can set to cause a shell to +be used. In this case, the entire command is expanded as a single string and +passed to the shell for interpretation. It is recommended that this be avoided +if at all possible, since it can lead to problems when inserted variables +contain shell metacharacters. + +The default PATH set up for the command is determined by the system +administrator, usually containing at least /bin and /usr/bin so that common +commands are available without having to specify an absolute file name. +However, it is possible for the system administrator to restrict the pipe +facility so that the command name must not contain any / characters, and must +be found in one of the directories in the configured PATH. It is also possible +for the system administrator to lock out the use of the pipe command +altogether. + +When the command is run, a number of environment variables are set up. The +complete list for pipe deliveries may be found in the Exim reference manual. +Those that may be useful for pipe deliveries from user filter files are: + +DOMAIN the domain of the address +HOME your home directory +LOCAL_PART see below +LOCAL_PART_PREFIX see below +LOCAL_PART_SUFFIX see below +LOGNAME your login name +MESSAGE_ID the unique id of the message +PATH the command search path +RECIPIENT the complete recipient address +SENDER the sender of the message +SHELL /bin/sh +USER see below + +LOCAL_PART, LOGNAME, and USER are all set to the same value, namely, your login +id. LOCAL_PART_PREFIX and LOCAL_PART_SUFFIX may be set if Exim is configured to +recognize prefixes or suffixes in the local parts of addresses. For example, a +message addressed to pat-suf2@domain.example may cause the filter for user pat +to be run. If this sets up a pipe delivery, LOCAL_PART_SUFFIX is "-suf2" when +the pipe command runs. The system administrator has to configure Exim specially +for this feature to be available. + +If you run a command that is a shell script, be very careful in your use of +data from the incoming message in the commands in your script. RFC 2822 is very +generous in the characters that are permitted to appear in mail addresses, and +in particular, an address may begin with a vertical bar or a slash. For this +reason you should always use quotes round any arguments that involve data from +the message, like this: + +/some/command '$SENDER' + +so that inserted shell meta-characters do not cause unwanted effects. + +Remember that, as was explained earlier, the pipe command is not run at the +time the filter file is interpreted. The filter just defines what deliveries +are required for one particular addressee of a message. The deliveries +themselves happen later, once Exim has decided everything that needs to be done +for the message. + +A consequence of this is that you cannot inspect the return code from the pipe +command from within the filter. Nevertheless, the code returned by the command +is important, because Exim uses it to decide whether the delivery has succeeded +or failed. + +The command should return a zero completion code if all has gone well. Most +non-zero codes are treated by Exim as indicating a failure of the pipe. This is +treated as a delivery failure, causing the message to be returned to its +sender. However, there are some completion codes that are treated as temporary +errors. The message remains on Exim's spool disk, and the delivery is tried +again later, though it will ultimately time out if the delivery failures go on +too long. The completion codes to which this applies can be specified by the +system administrator; the default values are 73 and 75. + +The pipe command should not normally write anything to its standard output or +standard error file descriptors. If it does, whatever is written is normally +returned to the sender of the message as a delivery error, though this action +can be varied by the system administrator. + + +3.14 Mail commands +------------------ + +There are two commands that cause the creation of a new mail message, neither +of which count as a significant delivery unless the command is preceded by the +word "seen" (see section 3.8). This is a powerful facility, but it should be +used with care, because of the danger of creating infinite sequences of +messages. The system administrator can forbid the use of these commands +altogether. + +To help prevent runaway message sequences, these commands have no effect when +the incoming message is a bounce (delivery error) message, and messages sent by +this means are treated as if they were reporting delivery errors. Thus, they +should never themselves cause a bounce message to be returned. The basic +mail-sending command is + +mail [to <address-list>] + [cc <address-list>] + [bcc <address-list>] + [from <address>] + [reply_to <address>] + [subject <text>] + [extra_headers <text>] + [text <text>] + [[expand] file <filename>] + [return message] + [log <log file name>] + [once <note file name>] + [once_repeat <time interval>] +e.g. mail text "Your message about $h_subject: has been received" + +Each <address-list> can contain a number of addresses, separated by commas, in +the format of a To: or Cc: header line. In fact, the text you supply here is +copied exactly into the appropriate header line. It may contain additional +information as well as email addresses. For example: + +mail to "Julius Caesar <jc@rome.example>, \ + <ma@rome.example> (Mark A.)" + +Similarly, the texts supplied for from and reply_to are copied into their +respective header lines. + +As a convenience for use in one common case, there is also a command called +vacation. It behaves in the same way as mail, except that the defaults for the +subject, file, log, once, and once_repeat options are + +subject "On vacation" +expand file .vacation.msg +log .vacation.log +once .vacation +once_repeat 7d + +respectively. These are the same file names and repeat period used by the +traditional Unix vacation command. The defaults can be overridden by explicit +settings, but if a file name is given its contents are expanded only if +explicitly requested. + +Warning: The vacation command should always be used conditionally, subject to +at least the personal condition (see section 3.27 below) so as not to send +automatic replies to non-personal messages from mailing lists or elsewhere. +Sending an automatic response to a mailing list or a mailing list manager is an +Internet Sin. + +For both commands, the key/value argument pairs can appear in any order. At +least one of text or file must appear (except with vacation, where there is a +default for file); if both are present, the text string appears first in the +message. If expand precedes file, each line of the file is subject to string +expansion before it is included in the message. + +Several lines of text can be supplied to text by including the escape sequence +"\n" in the string wherever a newline is required. If the command is output +during filter file testing, newlines in the text are shown as "\n". + +Note that the keyword for creating a Reply-To: header is reply_to, because Exim +keywords may contain underscores, but not hyphens. If the from keyword is +present and the given address does not match the user who owns the forward +file, Exim normally adds a Sender: header to the message, though it can be +configured not to do this. + +The extra_headers keyword allows you to add custom header lines to the message. +The text supplied must be one or more syntactically valid RFC 2822 header +lines. You can use "\n" within quoted text to specify newlines between headers, +and also to define continued header lines. For example: + +extra_headers "h1: first\nh2: second\n continued\nh3: third" + +No newline should appear at the end of the final header line. + +If no to argument appears, the message is sent to the address in the +$reply_address variable (see section 3.3 above). An In-Reply-To: header is +automatically included in the created message, giving a reference to the +message identification of the incoming message. + +If return message is specified, the incoming message that caused the filter +file to be run is added to the end of the message, subject to a maximum size +limitation. + +If a log file is specified, a line is added to it for each message sent. + +If a once file is specified, it is used to hold a database for remembering who +has received a message, and no more than one message is ever sent to any +particular address, unless once_repeat is set. This specifies a time interval +after which another copy of the message is sent. The interval is specified as a +sequence of numbers, each followed by the initial letter of one of "seconds", +"minutes", "hours", "days", or "weeks". For example, + +once_repeat 5d4h + +causes a new message to be sent if at least 5 days and 4 hours have elapsed +since the last one was sent. There must be no white space in a time interval. + +Commonly, the file name specified for once is used as the base name for +direct-access (DBM) file operations. There are a number of different DBM +libraries in existence. Some operating systems provide one as a default, but +even in this case a different one may have been used when building Exim. With +some DBM libraries, specifying once results in two files being created, with +the suffixes .dir and .pag being added to the given name. With some others a +single file with the suffix .db is used, or the name is used unchanged. + +Using a DBM file for implementing the once feature means that the file grows as +large as necessary. This is not usually a problem, but some system +administrators want to put a limit on it. The facility can be configured not to +use a DBM file, but instead, to use a regular file with a maximum size. The +data in such a file is searched sequentially, and if the file fills up, the +oldest entry is deleted to make way for a new one. This means that some +correspondents may receive a second copy of the message after an unpredictable +interval. Consult your local information to see if your system is configured +this way. + +More than one mail or vacation command may be obeyed in a single filter run; +they are all honoured, even when they are to the same recipient. + + +3.15 Logging commands +--------------------- + +A log can be kept of actions taken by a filter file. This facility is normally +available in conventional configurations, but there are some situations where +it might not be. Also, the system administrator may choose to disable it. Check +your local information if in doubt. + +Logging takes place while the filter file is being interpreted. It does not +queue up for later like the delivery commands. The reason for this is so that a +log file need be opened only once for several write operations. There are two +commands, neither of which constitutes a significant delivery. The first +defines a file to which logging output is subsequently written: + + logfile <file name> +e.g. logfile $home/filter.log + +The file name must be fully qualified. You can use $home, as in this example, +to refer to your home directory. The file name may optionally be followed by a +mode for the file, which is used if the file has to be created. For example, + +logfile $home/filter.log 0644 + +The number is interpreted as octal, even if it does not begin with a zero. The +default for the mode is 600. It is suggested that the logfile command normally +appear as the first command in a filter file. Once a log file has been obeyed, +the logwrite command can be used to write to it: + + logwrite "<some text string>" +e.g. logwrite "$tod_log $message_id processed" + +It is possible to have more than one logfile command, to specify writing to +different log files in different circumstances. A previously opened log is +closed on a subsequent logfile command. Writing takes place at the end of the +file, and a newline character is added to the end of each string if there isn't +one already there. Newlines can be put in the middle of the string by using the +"\n" escape sequence. Lines from simultaneous deliveries may get interleaved in +the file, as there is no interlocking, so you should plan your logging with +this in mind. However, data should not get lost. + + +3.16 The finish command +----------------------- + +The command finish, which has no arguments, causes Exim to stop interpreting +the filter file. This is not a significant action unless preceded by "seen". A +filter file containing only "seen finish" is a black hole. + + +3.17 The testprint command +-------------------------- + +It is sometimes helpful to be able to print out the values of variables when +testing filter files. The command + + testprint <text> +e.g. testprint "home=$home reply_address=$reply_address" + +does nothing when mail is being delivered. However, when the filtering code is +being tested by means of the -bf option (see section 1.3 above), the value of +the string is written to the standard output. + + +3.18 The fail command +--------------------- + +When Exim's filtering facilities are being used as a system filter, the fail +command is available, to force delivery failure. Because this command is +normally usable only by the system administrator, and not enabled for use by +ordinary users, it is described in more detail in the main Exim specification +rather than in this document. + + +3.19 The freeze command +----------------------- + +When Exim's filtering facilities are being used as a system filter, the freeze +command is available, to freeze a message on the queue. Because this command is +normally usable only by the system administrator, and not enabled for use by +ordinary users, it is described in more detail in the main Exim specification +rather than in this document. + + +3.20 The headers command +------------------------ + +The headers command can be used to change the target character set that is used +when translating the contents of encoded header lines for insertion by the +$header_ mechanism (see section 3.5 above). The default can be set in the Exim +configuration; if not specified, ISO-8859-1 is used. The only currently +supported format for the headers command in user filters is as in this example: + +headers charset "UTF-8" + +That is, headers is followed by the word "charset" and then the name of a +character set. This particular example would be useful if you wanted to compare +the contents of a header to a UTF-8 string. + +In system filter files, the headers command can be used to add or remove header +lines from the message. These features are described in the main Exim +specification. + + +3.21 Obeying commands conditionally +----------------------------------- + +Most of the power of filtering comes from the ability to test conditions and +obey different commands depending on the outcome. The if command is used to +specify conditional execution, and its general form is + +if <condition> +then <commands> +elif <condition> +then <commands> +else <commands> +endif + +There may be any number of elif and then sections (including none) and the else +section is also optional. Any number of commands, including nested if commands, +may appear in any of the <commands> sections. + +Conditions can be combined by using the words and and or, and round brackets +(parentheses) can be used to specify how several conditions are to combine. +Without brackets, and is more binding than or. For example: + +if +$h_subject: contains "Make money" or +$h_precedence: is "junk" or +($h_sender: matches ^\\d{8}@ and not personal) or +$message_body contains "this is not spam" +then +seen finish +endif + +A condition can be preceded by not to negate it, and there are also some +negative forms of condition that are more English-like. + + +3.22 String testing conditions +------------------------------ + +There are a number of conditions that operate on text strings, using the words +"begins", "ends", "is", "contains" and "matches". If you want to apply the same +test to more than one header line, you can easily concatenate them into a +single string for testing, as in this example: + +if "$h_to:, $h_cc:" contains me@domain.example then ... + +If a string-testing condition name is written in lower case, the testing of +letters is done without regard to case; if it is written in upper case (for +example, "CONTAINS"), the case of letters is taken into account. + + <text1> begins <text2> + <text1> does not begin <text2> +e.g. $header_from: begins "Friend@" + +A "begins" test checks for the presence of the second string at the start of +the first, both strings having been expanded. + + <text1> ends <text2> + <text1> does not end <text2> +e.g. $header_from: ends "public.com.example" + +An "ends" test checks for the presence of the second string at the end of the +first, both strings having been expanded. + + <text1> is <text2> + <text1> is not <text2> +e.g. $local_part_suffix is "-foo" + +An "is" test does an exact match between the strings, having first expanded +both strings. + + <text1> contains <text2> + <text1> does not contain <text2> +e.g. $header_subject: contains "evolution" + +A "contains" test does a partial string match, having expanded both strings. + + <text1> matches <text2> + <text1> does not match <text2> +e.g. $sender_address matches "(bill|john)@" + +For a "matches" test, after expansion of both strings, the second one is +interpreted as a regular expression. Exim uses the PCRE regular expression +library, which provides regular expressions that are compatible with Perl. + +The match succeeds if the regular expression matches any part of the first +string. If you want a regular expression to match only at the start or end of +the subject string, you must encode that requirement explicitly, using the "^" +or "$" metacharacters. The above example, which is not so constrained, matches +all these addresses: + +bill@test.example +john@some.example +spoonbill@example.com +littlejohn@example.com + +To match only the first two, you could use this: + +if $sender_address matches "^(bill|john)@" then ... + +Care must be taken if you need a backslash in a regular expression, because +backslashes are interpreted as escape characters both by the string expansion +code and by Exim's normal processing of strings in quotes. For example, if you +want to test the sender address for a domain ending in .com the regular +expression is + +\.com$ + +The backslash and dollar sign in that expression have to be escaped when used +in a filter command, as otherwise they would be interpreted by the expansion +code. Thus, what you actually write is + +if $sender_address matches \\.com\$ + +An alternative way of handling this is to make use of the "\N" expansion flag +for suppressing expansion: + +if $sender_address matches \N\.com$\N + +Everything between the two occurrences of "\N" is copied without change by the +string expander (and in fact you do not need the final one, because it is at +the end of the string). If the regular expression is given in quotes (mandatory +only if it contains white space) you have to write either + +if $sender_address matches "\\\\.com\\$" + +or + +if $sender_address matches "\\N\\.com$\\N" + +If the regular expression contains bracketed sub-expressions, numeric variable +substitutions such as $1 can be used in the subsequent actions after a +successful match. If the match fails, the values of the numeric variables +remain unchanged. Previous values are not restored after endif. In other words, +only one set of values is ever available. If the condition contains several +sub-conditions connected by and or or, it is the strings extracted from the +last successful match that are available in subsequent actions. Numeric +variables from any one sub-condition are also available for use in subsequent +sub-conditions, because string expansion of a condition occurs just before it +is tested. + + +3.23 Numeric testing conditions +------------------------------- + +The following conditions are available for performing numerical tests: + + <number1> is above <number2> + <number1> is not above <number2> + <number1> is below <number2> + <number1> is not below <number2> +e.g. $message_size is not above 10k + +The <number> arguments must expand to strings of digits, optionally followed by +one of the letters K or M (upper case or lower case) which cause multiplication +by 1024 and 1024x1024 respectively. + + +3.24 Testing for significant deliveries +--------------------------------------- + +You can use the delivered condition to test whether or not any previously +obeyed filter commands have set up a significant delivery. For example: + +if not delivered then save mail/anomalous endif + +"Delivered" is perhaps a poor choice of name for this condition, because the +message has not actually been delivered; rather, a delivery has been set up for +later processing. + + +3.25 Testing for error messages +------------------------------- + +The condition error_message is true if the incoming message is a bounce (mail +delivery error) message. Putting the command + +if error_message then finish endif + +at the head of your filter file is a useful insurance against things going +wrong in such a way that you cannot receive delivery error reports. Note: +error_message is a condition, not an expansion variable, and therefore is not +preceded by "$". + + +3.26 Testing a list of addresses +-------------------------------- + +There is a facility for looping through a list of addresses and applying a +condition to each of them. It takes the form + +foranyaddress <string> (<condition>) + +where <string> is interpreted as a list of RFC 2822 addresses, as in a typical +header line, and <condition> is any valid filter condition or combination of +conditions. The "group" syntax that is defined for certain header lines that +contain addresses is supported. + +The parentheses surrounding the condition are mandatory, to delimit it from +possible further sub-conditions of the enclosing if command. Within the +condition, the expansion variable $thisaddress is set to the non-comment +portion of each of the addresses in the string in turn. For example, if the +string is + +B.Simpson <bart@sfld.example>, lisa@sfld.example (his sister) + +then $thisaddress would take on the values "bart@sfld.example" and +"lisa@sfld.example" in turn. + +If there are no valid addresses in the list, the whole condition is false. If +the internal condition is true for any one address, the overall condition is +true and the loop ends. If the internal condition is false for all addresses in +the list, the overall condition is false. This example tests for the presence +of an eight-digit local part in any address in a To: header: + +if foranyaddress $h_to: ( $thisaddress matches ^\\d{8}@ ) then ... + +When the overall condition is true, the value of $thisaddress in the commands +that follow then is the last value it took on inside the loop. At the end of +the if command, the value of $thisaddress is reset to what it was before. It is +best to avoid the use of multiple occurrences of foranyaddress, nested or +otherwise, in a single if command, if the value of $thisaddress is to be used +afterwards, because it isn't always clear what the value will be. Nested if +commands should be used instead. + +Header lines can be joined together if a check is to be applied to more than +one of them. For example: + +if foranyaddress $h_to:,$h_cc: .... + +This scans through the addresses in both the To: and the Cc: headers. + + +3.27 Testing for personal mail +------------------------------ + +A common requirement is to distinguish between incoming personal mail and mail +from a mailing list, or from a robot or other automatic process (for example, a +bounce message). In particular, this test is normally required for "vacation +messages". + +The personal condition checks that the message is not a bounce message and that +the current user's email address appears in the To: header. It also checks that +the sender is not the current user or one of a number of common daemons, and +that there are no header lines starting List- in the message. Finally, it +checks the content of the Precedence: header line, if there is one. + +You should always use the personal condition when generating automatic +responses. This example shows the use of personal in a filter file that is +sending out vacation messages: + +if personal then +mail to $reply_address +subject "I am on holiday" +file $home/vacation/message +once $home/vacation/once +once_repeat 10d +endif + +It is tempting, when writing commands like the above, to quote the original +subject in the reply. For example: + +subject "Re: $h_subject:" + +There is a danger in doing this, however. It may allow a third party to +subscribe you to an opt-in mailing list, provided that the list accepts bounce +messages as subscription confirmations. (Messages sent from filters are always +sent as bounce messages.) Well-managed lists require a non-bounce message to +confirm a subscription, so the danger is relatively small. + +If prefixes or suffixes are in use for local parts - something which depends on +the configuration of Exim (see section 3.31 below) - the tests for the current +user are done with the full address (including the prefix and suffix, if any) +as well as with the prefix and suffix removed. If the system is configured to +rewrite local parts of mail addresses, for example, to rewrite "dag46" as +"Dirk.Gently", the rewritten form of the address is also used in the tests. + + +3.28 Alias addresses for the personal condition +----------------------------------------------- + +It is quite common for people who have mail accounts on a number of different +systems to forward all their mail to one system, and in this case a check for +personal mail should test all their various mail addresses. To allow for this, +the personal condition keyword can be followed by + +alias <address> + +any number of times, for example: + +if personal alias smith@else.where.example + alias jones@other.place.example +then ... + +The alias addresses are treated as alternatives to the current user's email +address when testing the contents of header lines. + + +3.29 Details of the personal condition +-------------------------------------- + +The basic personal test is roughly equivalent to the following: + +not error_message and +$message_headers does not contain "\nList-Id:" and +$message_headers does not contain "\nList-Help:" and +$message_headers does not contain "\nList-Subscribe:" and +$message_headers does not contain "\nList-Unsubscribe:" and +$message_headers does not contain "\nList-Post:" and +$message_headers does not contain "\nList-Owner:" and +$message_headers does not contain "\nList-Archive:" and +( +"${if def:h_auto-submitted:{present}{absent}}" is "absent" or +$header_auto-submitted: is "no" +) and +$header_precedence: does not contain "bulk" and +$header_precedence: does not contain "list" and +$header_precedence: does not contain "junk" and +foranyaddress $header_to: +( $thisaddress contains "$local_part$domain" ) and +not foranyaddress $header_from: +( +$thisaddress contains "$local_part@$domain" or +$thisaddress contains "server@" or +$thisaddress contains "daemon@" or +$thisaddress contains "root@" or +$thisaddress contains "listserv@" or +$thisaddress contains "majordomo@" or +$thisaddress contains "-request@" or +$thisaddress matches "^owner-[^@]+@" +) + +The variable $local_part contains the local part of the mail address of the +user whose filter file is being run - it is normally your login id. The $domain +variable contains the mail domain. As explained above, if aliases or rewriting +are defined, or if prefixes or suffixes are in use, the tests for the current +user are also done with alternative addresses. + + +3.30 Testing delivery status +---------------------------- + +There are two conditions that are intended mainly for use in system filter +files, but which are available in users' filter files as well. The condition +first_delivery is true if this is the first process that is attempting to +deliver the message, and false otherwise. This indicator is not reset until the +first delivery process successfully terminates; if there is a crash or a power +failure (for example), the next delivery attempt is also a "first delivery". + +In a user filter file first_delivery will be false if there was previously an +error in the filter, or if a delivery for the user failed owing to, for +example, a quota error, or if forwarding to a remote address was deferred for +some reason. + +The condition manually_thawed is true if the message was "frozen" for some +reason, and was subsequently released by the system administrator. It is +unlikely to be of use in users' filter files. + + +3.31 Multiple personal mailboxes +-------------------------------- + +The system administrator can configure Exim so that users can set up variants +on their email addresses and handle them separately. Consult your system +administrator or local documentation to see if this facility is enabled on your +system, and if so, what the details are. + +The facility involves the use of a prefix or a suffix on an email address. For +example, all mail addressed to lg303-<something> would be the property of user +lg303, who could determine how it was to be handled, depending on the value of +<something>. + +There are two possible ways in which this can be set up. The first possibility +is the use of multiple .forward files. In this case, mail to lg303-foo, for +example, is handled by looking for a file called .forward-foo in lg303's home +directory. If such a file does not exist, delivery fails and the message is +returned to its sender. + +The alternative approach is to pass all messages through a single .forward +file, which must be a filter file so that it can distinguish between the +different cases by referencing the variables $local_part_prefix or +$local_part_suffix, as in the final example in section 3.33 below. + +It is possible to configure Exim to support both schemes at once. In this case, +a specific .forward-foo file is first sought; if it is not found, the basic +.forward file is used. + +The personal test (see section 3.27) includes prefixes and suffixes in its +checking. + + +3.32 Ignoring delivery errors +----------------------------- + +As was explained above, filtering just sets up addresses for delivery - no +deliveries are actually done while a filter file is active. If any of the +generated addresses subsequently suffers a delivery failure, an error message +is generated in the normal way. However, if a filter command that sets up a +delivery is preceded by the word "noerror", errors for that delivery, and any +deliveries consequent on it (that is, from alias, forwarding, or filter files +it invokes) are ignored. + + +3.33 Examples of Exim filter commands +------------------------------------- + +Simple forwarding: + +# Exim filter +deliver baggins@rivendell.middle-earth.example + +Vacation handling using traditional means, assuming that the .vacation.msg and +other files have been set up in your home directory: + +# Exim filter +unseen pipe "/usr/ucb/vacation \"$local_part\"" + +Vacation handling inside Exim, having first created a file called .vacation.msg +in your home directory: + +# Exim filter +if personal then vacation endif + +File some messages by subject: + +# Exim filter +if $header_subject: contains "empire" or +$header_subject: contains "foundation" +then +save $home/mail/f+e +endif + +Save all non-urgent messages by weekday: + +# Exim filter +if $header_subject: does not contain "urgent" and +$tod_full matches "^(...)," +then +save $home/mail/$1 +endif + +Throw away all mail from one site, except from postmaster: + +# Exim filter +if $reply_address contains "@spam.site.example" and +$reply_address does not contain "postmaster@" +then +seen finish +endif + +Handle multiple personal mailboxes: + +# Exim filter +if $local_part_suffix is "-foo" +then +save $home/mail/foo +elif $local_part_suffix is "-bar" +then +save $home/mail/bar +endif + diff --git a/doc/openssl.txt b/doc/openssl.txt new file mode 100644 index 0000000..3efa833 --- /dev/null +++ b/doc/openssl.txt @@ -0,0 +1,165 @@ +OpenSSL +======= + +The OpenSSL Project documents their supported releases at +<https://www.openssl.org/policies/releasestrat.html>. The Exim +Maintainers are unwilling to try to support Exim built with a +version of a critical security library which is unmaintained. + +Thus as versions of OpenSSL become unsupported by OpenSSL, they become +unsupported by Exim. Exim might build with older releases of OpenSSL, +but that's risky behaviour. + +If your operating system vendor continues to ship an older version of +OpenSSL and is diligently backporting security fixes, and they support +Exim, then they will be backporting fixes to their packages of Exim too. +If you wish to stick purely to packages of OpenSSL, then stick to +packages of Exim too. + +If someone maintains "backports", that is worth exploring too. + +Note that a number of OSes use Exim with GnuTLS, not OpenSSL. + +Otherwise, assuming that your operating system has old OpenSSL, and you +wish to use current Exim with OpenSSL, then you need to build and +install your own, without interfering with the system libraries. +Fortunately, this is easy. + +So this only applies if you build Exim yourself. + + +Insecure versions and ciphers +----------------------------- + +Email delivery to MX hosts is usually done with automatic fallback to +plaintext if TLS could not be negotiated. There are good historical reasons +for this. You can and should avoid it by using DNSSEC for signing your DNS +and publishing TLSA records, to enable "DANE" security. This signals to +senders that they should be able to verify your certificates, and that they +should not fallback to cleartext. + +In the absence of DANE, trying to increase the security of TLS by removing +support for older generations of ciphers and protocols will actually _lower_ +the security, because the clients fallback to plaintext and retry anyway. As +a result, you should give serious thought to enabling older features which are +no longer default in OpenSSL. + +The examples below explicitly enable ssl3 and weak ciphers. + +We don't like this, but reality doesn't care and is messy. + + +Build +----- + +Extract the current source of OpenSSL. Change into that directory. + +This assumes that `/opt/openssl` is not in use. If it is, pick +something else. `/opt/exim/openssl` perhaps. + +If you pick a location shared amongst various local packages, such as +`/usr/local` on Linux, then the new OpenSSL will be used by all of those +packages. If that's what you want, great! If instead you want to +ensure that only software you explicitly set to use the newer OpenSSL +will try to use the new OpenSSL, then stick to something like +`/opt/openssl`. + + ./config --prefix=/opt/openssl --openssldir=/etc/ssl \ + -L/opt/openssl/lib -Wl,-R/opt/openssl/lib \ + enable-ssl-trace shared \ + enable-ssl3 enable-ssl3-method enable-weak-ssl-ciphers + make + make install + +On some systems, the linker uses `-rpath` instead of `-R`; on such systems, +replace the parameter starting `-Wl` with: `-Wl,-rpath,/opt/openssl/lib`. +There are more variations on less common systems. + +You now have an installed OpenSSL under /opt/openssl which will not be +used by any system programs. + +When you copy `src/EDITME` to `Local/Makefile` to make your build edits, +choose the pkg-config approach in that file, but also tell Exim to add +the relevant directory into the rpath stamped into the binary: + + PKG_CONFIG_PATH=/opt/openssl/lib/pkgconfig + + SUPPORT_TLS=yes + USE_OPENSSL_PC=openssl + LDFLAGS+=-ldl -Wl,-rpath,/opt/openssl/lib + +The -ldl is needed by OpenSSL 1.0.2+ on Linux and is not needed on most +other platforms. The LDFLAGS is needed because `pkg-config` doesn't know +how to emit information about RPATH-stamping, but we can still leverage +`pkg-config` for everything else. + +Then build Exim: + + make + sudo make install + + +Confirming +---------- + +Run: + + exim -d-all+expand --version + +and look for the `Library version: OpenSSL:` lines. + +To look at the libraries _probably_ found by the linker, use: + + ldd $(which exim) # most platforms + otool -L $(which exim) # MacOS + +although that does not correctly handle restrictions imposed upon +executables which are setuid. + +If the `chrpath` package is installed, then: + + chrpath -l $(which exim) + +will show the DT_RPATH stamped into the binary. + +Your `binutils` package should come with `readelf`, so an alternative +is to run: + + readelf -d $(which exim) | grep RPATH + +It is important to use `RPATH` and not `RUNPATH`! + +The gory details about `RUNPATH` (skip unless interested): +The OpenSSL library might be opened indirectly by some other library +which Exim depends upon. If the executable does have `RUNPATH` then +that will inhibit using either of `RPATH` or `RUNPATH` from the +executable for finding the OpenSSL library when that other library tries +to load it. +In fact, if the intermediate library has a `RUNPATH` stamped into it, +then this will block `RPATH` too, and will create problems with Exim. +If you're in such a situation, and those libraries were supplied to you +instead of built by you, then you're reaching the limits of sane +repairability and it's time to prioritize rebuilding your mail-server +hosts to be a current OS release which natively pulls in an +upstream-supported OpenSSL, or stick to the OS releases of Exim. + + +Very Advanced +------------- + +You can not use $ORIGIN for portably packing OpenSSL in with Exim with +normal Exim builds, because Exim is installed setuid which causes the +runtime linker to ignore $ORIGIN in DT_RPATH. + +_If_ following the steps for a non-setuid Exim, _then_ you can use: + + EXTRALIBS_EXIM=-ldl '-Wl,-rpath,$$ORIGIN/../lib' + +The doubled `$$` is needed for the make(1) layer and the quotes needed +for the shell invoked by make(1) for calling the linker. + +Note that this is sufficiently far outside normal that the build-system +doesn't support it by default; you'll want to drop a symlink to the lib +directory into the Exim release top-level directory, so that lib exists +as a sibling to the build-$platform directory. + diff --git a/doc/spec.txt b/doc/spec.txt new file mode 100644 index 0000000..b522487 --- /dev/null +++ b/doc/spec.txt @@ -0,0 +1,37579 @@ +Specification of the Exim Mail Transfer Agent + +Exim Maintainers + +Copyright (c) 2018 University of Cambridge + +Revision 4.92 10 Feb 2019 EM + +------------------------------------------------------------------------------- + +TABLE OF CONTENTS + +1. Introduction + + 1.1. Exim documentation + 1.2. FTP site and websites + 1.3. Mailing lists + 1.4. Bug reports + 1.5. Where to find the Exim distribution + 1.6. Limitations + 1.7. Runtime configuration + 1.8. Calling interface + 1.9. Terminology + +2. Incorporated code +3. How Exim receives and delivers mail + + 3.1. Overall philosophy + 3.2. Policy control + 3.3. User filters + 3.4. Message identification + 3.5. Receiving mail + 3.6. Handling an incoming message + 3.7. Life of a message + 3.8. Processing an address for delivery + 3.9. Processing an address for verification + 3.10. Running an individual router + 3.11. Duplicate addresses + 3.12. Router preconditions + 3.13. Delivery in detail + 3.14. Retry mechanism + 3.15. Temporary delivery failure + 3.16. Permanent delivery failure + 3.17. Failures to deliver bounce messages + +4. Building and installing Exim + + 4.1. Unpacking + 4.2. Multiple machine architectures and operating systems + 4.3. PCRE library + 4.4. DBM libraries + 4.5. Pre-building configuration + 4.6. Support for iconv() + 4.7. Including TLS/SSL encryption support + 4.8. Use of tcpwrappers + 4.9. Including support for IPv6 + 4.10. Dynamically loaded lookup module support + 4.11. The building process + 4.12. Output from "make" + 4.13. Overriding build-time options for Exim + 4.14. OS-specific header files + 4.15. Overriding build-time options for the monitor + 4.16. Installing Exim binaries and scripts + 4.17. Installing info documentation + 4.18. Setting up the spool directory + 4.19. Testing + 4.20. Replacing another MTA with Exim + 4.21. Upgrading Exim + 4.22. Stopping the Exim daemon on Solaris + +5. The Exim command line + + 5.1. Setting options by program name + 5.2. Trusted and admin users + 5.3. Command line options + +6. The Exim runtime configuration file + + 6.1. Using a different configuration file + 6.2. Configuration file format + 6.3. File inclusions in the configuration file + 6.4. Macros in the configuration file + 6.5. Macro substitution + 6.6. Redefining macros + 6.7. Overriding macro values + 6.8. Example of macro usage + 6.9. Builtin macros + 6.10. Conditional skips in the configuration file + 6.11. Common option syntax + 6.12. Boolean options + 6.13. Integer values + 6.14. Octal integer values + 6.15. Fixed point numbers + 6.16. Time intervals + 6.17. String values + 6.18. Expanded strings + 6.19. User and group names + 6.20. List construction + 6.21. Changing list separators + 6.22. Empty items in lists + 6.23. Format of driver configurations + +7. The default configuration file + + 7.1. Macros + 7.2. Main configuration settings + 7.3. ACL configuration + 7.4. Router configuration + 7.5. Transport configuration + 7.6. Default retry rule + 7.7. Rewriting configuration + 7.8. Authenticators configuration + +8. Regular expressions +9. File and database lookups + + 9.1. Examples of different lookup syntax + 9.2. Lookup types + 9.3. Single-key lookup types + 9.4. Query-style lookup types + 9.5. Temporary errors in lookups + 9.6. Default values in single-key lookups + 9.7. Partial matching in single-key lookups + 9.8. Lookup caching + 9.9. Quoting lookup data + 9.10. More about dnsdb + 9.11. Dnsdb lookup modifiers + 9.12. Pseudo dnsdb record types + 9.13. Multiple dnsdb lookups + 9.14. More about LDAP + 9.15. Format of LDAP queries + 9.16. LDAP quoting + 9.17. LDAP connections + 9.18. LDAP authentication and control information + 9.19. Format of data returned by LDAP + 9.20. More about NIS+ + 9.21. SQL lookups + 9.22. More about MySQL, PostgreSQL, Oracle, InterBase, and Redis + 9.23. Specifying the server in the query + 9.24. Special MySQL features + 9.25. Special PostgreSQL features + 9.26. More about SQLite + 9.27. More about Redis + +10. Domain, host, address, and local part lists + + 10.1. Expansion of lists + 10.2. Negated items in lists + 10.3. File names in lists + 10.4. An lsearch file is not an out-of-line list + 10.5. Named lists + 10.6. Named lists compared with macros + 10.7. Named list caching + 10.8. Domain lists + 10.9. Host lists + 10.10. Special host list patterns + 10.11. Host list patterns that match by IP address + 10.12. Host list patterns for single-key lookups by host address + 10.13. Host list patterns that match by host name + 10.14. Behaviour when an IP address or name cannot be found + 10.15. Mixing wildcarded host names and addresses in host lists + 10.16. Temporary DNS errors when looking up host information + 10.17. Host list patterns for single-key lookups by host name + 10.18. Host list patterns for query-style lookups + 10.19. Address lists + 10.20. Case of letters in address lists + 10.21. Local part lists + +11. String expansions + + 11.1. Literal text in expanded strings + 11.2. Character escape sequences in expanded strings + 11.3. Testing string expansions + 11.4. Forced expansion failure + 11.5. Expansion items + 11.6. Expansion operators + 11.7. Expansion conditions + 11.8. Combining expansion conditions + 11.9. Expansion variables + +12. Embedded Perl + + 12.1. Setting up so Perl can be used + 12.2. Calling Perl subroutines + 12.3. Calling Exim functions from Perl + 12.4. Use of standard output and error by Perl + +13. Starting the daemon and the use of network interfaces + + 13.1. Starting a listening daemon + 13.2. Special IP listening addresses + 13.3. Overriding local_interfaces and daemon_smtp_ports + 13.4. Support for the submissions (aka SSMTP or SMTPS) protocol + 13.5. IPv6 address scopes + 13.6. Disabling IPv6 + 13.7. Examples of starting a listening daemon + 13.8. Recognizing the local host + 13.9. Delivering to a remote host + +14. Main configuration + + 14.1. Miscellaneous + 14.2. Exim parameters + 14.3. Privilege controls + 14.4. Logging + 14.5. Frozen messages + 14.6. Data lookups + 14.7. Message ids + 14.8. Embedded Perl Startup + 14.9. Daemon + 14.10. Resource control + 14.11. Policy controls + 14.12. Callout cache + 14.13. TLS + 14.14. Local user handling + 14.15. All incoming messages (SMTP and non-SMTP) + 14.16. Non-SMTP incoming messages + 14.17. Incoming SMTP messages + 14.18. SMTP extensions + 14.19. Processing messages + 14.20. System filter + 14.21. Routing and delivery + 14.22. Bounce and warning messages + 14.23. Alphabetical list of main options + +15. Generic options for routers +16. The accept router +17. The dnslookup router + + 17.1. Problems with DNS lookups + 17.2. Declining addresses by dnslookup + 17.3. Private options for dnslookup + 17.4. Effect of qualify_single and search_parents + +18. The ipliteral router +19. The iplookup router +20. The manualroute router + + 20.1. Private options for manualroute + 20.2. Routing rules in route_list + 20.3. Routing rules in route_data + 20.4. Format of the list of hosts + 20.5. Format of one host item + 20.6. How the list of hosts is used + 20.7. How the options are used + 20.8. Manualroute examples + +21. The queryprogram router +22. The redirect router + + 22.1. Redirection data + 22.2. Forward files and address verification + 22.3. Interpreting redirection data + 22.4. Items in a non-filter redirection list + 22.5. Redirecting to a local mailbox + 22.6. Special items in redirection lists + 22.7. Duplicate addresses + 22.8. Repeated redirection expansion + 22.9. Errors in redirection lists + 22.10. Private options for the redirect router + +23. Environment for running local transports + + 23.1. Concurrent deliveries + 23.2. Uids and gids + 23.3. Current and home directories + 23.4. Expansion variables derived from the address + +24. Generic options for transports +25. Address batching in local transports +26. The appendfile transport + + 26.1. The file and directory options + 26.2. Private options for appendfile + 26.3. Operational details for appending + 26.4. Operational details for delivery to a new file + 26.5. Maildir delivery + 26.6. Using tags to record message sizes + 26.7. Using a maildirsize file + 26.8. Mailstore delivery + 26.9. Non-special new file delivery + +27. The autoreply transport + + 27.1. Private options for autoreply + +28. The lmtp transport +29. The pipe transport + + 29.1. Concurrent delivery + 29.2. Returned status and data + 29.3. How the command is run + 29.4. Environment variables + 29.5. Private options for pipe + 29.6. Using an external local delivery agent + +30. The smtp transport + + 30.1. Multiple messages on a single connection + 30.2. Use of the $host and $host_address variables + 30.3. Use of $tls_cipher and $tls_peerdn + 30.4. Private options for smtp + 30.5. How the limits for the number of hosts to try are used + +31. Address rewriting + + 31.1. Explicitly configured address rewriting + 31.2. When does rewriting happen? + 31.3. Testing the rewriting rules that apply on input + 31.4. Rewriting rules + 31.5. Rewriting patterns + 31.6. Rewriting replacements + 31.7. Rewriting flags + 31.8. Flags specifying which headers and envelope addresses to rewrite + 31.9. The SMTP-time rewriting flag + 31.10. Flags controlling the rewriting process + 31.11. Rewriting examples + +32. Retry configuration + + 32.1. Changing retry rules + 32.2. Format of retry rules + 32.3. Choosing which retry rule to use for address errors + 32.4. Choosing which retry rule to use for host and message errors + 32.5. Retry rules for specific errors + 32.6. Retry rules for specified senders + 32.7. Retry parameters + 32.8. Retry rule examples + 32.9. Timeout of retry data + 32.10. Long-term failures + 32.11. Deliveries that work intermittently + +33. SMTP authentication + + 33.1. Generic options for authenticators + 33.2. The AUTH parameter on MAIL commands + 33.3. Authentication on an Exim server + 33.4. Testing server authentication + 33.5. Authentication by an Exim client + +34. The plaintext authenticator + + 34.1. Plaintext options + 34.2. Using plaintext in a server + 34.3. The PLAIN authentication mechanism + 34.4. The LOGIN authentication mechanism + 34.5. Support for different kinds of authentication + 34.6. Using plaintext in a client + +35. The cram_md5 authenticator + + 35.1. Using cram_md5 as a server + 35.2. Using cram_md5 as a client + +36. The cyrus_sasl authenticator + + 36.1. Using cyrus_sasl as a server + +37. The dovecot authenticator +38. The gsasl authenticator + + 38.1. gsasl auth variables + +39. The heimdal_gssapi authenticator + + 39.1. heimdal_gssapi auth variables + +40. The spa authenticator + + 40.1. Using spa as a server + 40.2. Using spa as a client + +41. The tls authenticator +42. Encrypted SMTP connections using TLS/SSL + + 42.1. Support for the "submissions" (aka "ssmtp" and "smtps") protocol + 42.2. OpenSSL vs GnuTLS + 42.3. GnuTLS parameter computation + 42.4. Requiring specific ciphers in OpenSSL + 42.5. Requiring specific ciphers or other parameters in GnuTLS + 42.6. Configuring an Exim server to use TLS + 42.7. Requesting and verifying client certificates + 42.8. Revoked certificates + 42.9. Configuring an Exim client to use TLS + 42.10. Use of TLS Server Name Indication + 42.11. Multiple messages on the same encrypted TCP/IP connection + 42.12. Certificates and all that + 42.13. Certificate chains + 42.14. Self-signed certificates + 42.15. DANE + +43. Access control lists + + 43.1. Testing ACLs + 43.2. Specifying when ACLs are used + 43.3. The non-SMTP ACLs + 43.4. The SMTP connect ACL + 43.5. The EHLO/HELO ACL + 43.6. The DATA ACLs + 43.7. The SMTP DKIM ACL + 43.8. The SMTP MIME ACL + 43.9. The SMTP PRDR ACL + 43.10. The QUIT ACL + 43.11. The not-QUIT ACL + 43.12. Finding an ACL to use + 43.13. ACL return codes + 43.14. Unset ACL options + 43.15. Data for message ACLs + 43.16. Data for non-message ACLs + 43.17. Format of an ACL + 43.18. ACL verbs + 43.19. ACL variables + 43.20. Condition and modifier processing + 43.21. ACL modifiers + 43.22. Use of the control modifier + 43.23. Summary of message fixup control + 43.24. Adding header lines in ACLs + 43.25. Removing header lines in ACLs + 43.26. ACL conditions + 43.27. Using DNS lists + 43.28. Specifying the IP address for a DNS list lookup + 43.29. DNS lists keyed on domain names + 43.30. Multiple explicit keys for a DNS list + 43.31. Data returned by DNS lists + 43.32. Variables set from DNS lists + 43.33. Additional matching conditions for DNS lists + 43.34. Negated DNS matching conditions + 43.35. Handling multiple DNS records from a DNS list + 43.36. Detailed information from merged DNS lists + 43.37. DNS lists and IPv6 + 43.38. Rate limiting incoming messages + 43.39. Ratelimit options for what is being measured + 43.40. Ratelimit update modes + 43.41. Ratelimit options for handling fast clients + 43.42. Limiting the rate of different events + 43.43. Using rate limiting + 43.44. Address verification + 43.45. Callout verification + 43.46. Additional parameters for callouts + 43.47. Callout caching + 43.48. Sender address verification reporting + 43.49. Redirection while verifying + 43.50. Client SMTP authorization (CSA) + 43.51. Bounce address tag validation + 43.52. Using an ACL to control relaying + 43.53. Checking a relay configuration + +44. Content scanning at ACL time + + 44.1. Scanning for viruses + 44.2. Scanning with SpamAssassin and Rspamd + 44.3. Calling SpamAssassin from an Exim ACL + 44.4. Scanning MIME parts + 44.5. Scanning with regular expressions + +45. Adding a local scan function to Exim + + 45.1. Building Exim to use a local scan function + 45.2. API for local_scan() + 45.3. Configuration options for local_scan() + 45.4. Available Exim variables + 45.5. Structure of header lines + 45.6. Structure of recipient items + 45.7. Available Exim functions + 45.8. More about Exim's memory handling + +46. System-wide message filtering + + 46.1. Specifying a system filter + 46.2. Testing a system filter + 46.3. Contents of a system filter + 46.4. Additional variable for system filters + 46.5. Defer, freeze, and fail commands for system filters + 46.6. Adding and removing headers in a system filter + 46.7. Setting an errors address in a system filter + 46.8. Per-address filtering + +47. Message processing + + 47.1. Submission mode for non-local messages + 47.2. Line endings + 47.3. Unqualified addresses + 47.4. The UUCP From line + 47.5. Resent- header lines + 47.6. The Auto-Submitted: header line + 47.7. The Bcc: header line + 47.8. The Date: header line + 47.9. The Delivery-date: header line + 47.10. The Envelope-to: header line + 47.11. The From: header line + 47.12. The Message-ID: header line + 47.13. The Received: header line + 47.14. The References: header line + 47.15. The Return-path: header line + 47.16. The Sender: header line + 47.17. Adding and removing header lines in routers and transports + 47.18. Constructed addresses + 47.19. Case of local parts + 47.20. Dots in local parts + 47.21. Rewriting addresses + +48. SMTP processing + + 48.1. Outgoing SMTP and LMTP over TCP/IP + 48.2. Errors in outgoing SMTP + 48.3. Incoming SMTP messages over TCP/IP + 48.4. Unrecognized SMTP commands + 48.5. Syntax and protocol errors in SMTP commands + 48.6. Use of non-mail SMTP commands + 48.7. The VRFY and EXPN commands + 48.8. The ETRN command + 48.9. Incoming local SMTP + 48.10. Outgoing batched SMTP + 48.11. Incoming batched SMTP + +49. Customizing bounce and warning messages + + 49.1. Customizing bounce messages + 49.2. Customizing warning messages + +50. Some common configuration settings + + 50.1. Sending mail to a smart host + 50.2. Using Exim to handle mailing lists + 50.3. Syntax errors in mailing lists + 50.4. Re-expansion of mailing lists + 50.5. Closed mailing lists + 50.6. Variable Envelope Return Paths (VERP) + 50.7. Virtual domains + 50.8. Multiple user mailboxes + 50.9. Simplified vacation processing + 50.10. Taking copies of mail + 50.11. Intermittently connected hosts + 50.12. Exim on the upstream server host + 50.13. Exim on the intermittently connected client host + +51. Using Exim as a non-queueing client +52. Log files + + 52.1. Where the logs are written + 52.2. Logging to local files that are periodically "cycled" + 52.3. Datestamped log files + 52.4. Logging to syslog + 52.5. Log line flags + 52.6. Logging message reception + 52.7. Logging deliveries + 52.8. Discarded deliveries + 52.9. Deferred deliveries + 52.10. Delivery failures + 52.11. Fake deliveries + 52.12. Completion + 52.13. Summary of Fields in Log Lines + 52.14. Other log entries + 52.15. Reducing or increasing what is logged + 52.16. Message log + +53. Exim utilities + + 53.1. Finding out what Exim processes are doing (exiwhat) + 53.2. Selective queue listing (exiqgrep) + 53.3. Summarizing the queue (exiqsumm) + 53.4. Extracting specific information from the log (exigrep) + 53.5. Selecting messages by various criteria (exipick) + 53.6. Cycling log files (exicyclog) + 53.7. Mail statistics (eximstats) + 53.8. Checking access policy (exim_checkaccess) + 53.9. Making DBM files (exim_dbmbuild) + 53.10. Finding individual retry times (exinext) + 53.11. Hints database maintenance + 53.12. exim_dumpdb + 53.13. exim_tidydb + 53.14. exim_fixdb + 53.15. Mailbox maintenance (exim_lock) + +54. The Exim monitor + + 54.1. Running the monitor + 54.2. The stripcharts + 54.3. Main action buttons + 54.4. The log display + 54.5. The queue display + 54.6. The queue menu + +55. Security considerations + + 55.1. Building a more "hardened" Exim + 55.2. Root privilege + 55.3. Running Exim without privilege + 55.4. Delivering to local files + 55.5. Running local commands + 55.6. Trust in configuration data + 55.7. IPv4 source routing + 55.8. The VRFY, EXPN, and ETRN commands in SMTP + 55.9. Privileged users + 55.10. Spool files + 55.11. Use of argv[0] + 55.12. Use of %f formatting + 55.13. Embedded Exim path + 55.14. Dynamic module directory + 55.15. Use of sprintf() + 55.16. Use of debug_printf() and log_write() + 55.17. Use of strcat() and strcpy() + +56. Format of spool files + + 56.1. Format of the -H file + 56.2. Format of the -D file + +57. DKIM and SPF + + 57.1. DKIM (DomainKeys Identified Mail) + 57.2. Signing outgoing messages + 57.3. Verifying DKIM signatures in incoming mail + 57.4. SPF (Sender Policy Framework) + +58. Proxies + + 58.1. Inbound proxies + 58.2. Outbound proxies + 58.3. Logging + +59. Internationalisation + + 59.1. MTA operations + 59.2. MDA operations + +60. Events +61. Adding new drivers or lookup types + + + +=============================================================================== +1. INTRODUCTION + +Exim is a mail transfer agent (MTA) for hosts that are running Unix or +Unix-like operating systems. It was designed on the assumption that it would be +run on hosts that are permanently connected to the Internet. However, it can be +used on intermittently connected hosts with suitable configuration adjustments. + +Configuration files currently exist for the following operating systems: AIX, +BSD/OS (aka BSDI), Darwin (Mac OS X), DGUX, Dragonfly, FreeBSD, GNU/Hurd, GNU/ +Linux, HI-OSF (Hitachi), HI-UX, HP-UX, IRIX, MIPS RISCOS, NetBSD, OpenBSD, +OpenUNIX, QNX, SCO, SCO SVR4.2 (aka UNIX-SV), Solaris (aka SunOS5), SunOS4, +Tru64-Unix (formerly Digital UNIX, formerly DEC-OSF1), Ultrix, and UnixWare. +Some of these operating systems are no longer current and cannot easily be +tested, so the configuration files may no longer work in practice. + +There are also configuration files for compiling Exim in the Cygwin environment +that can be installed on systems running Windows. However, this document does +not contain any information about running Exim in the Cygwin environment. + +The terms and conditions for the use and distribution of Exim are contained in +the file NOTICE. Exim is distributed under the terms of the GNU General Public +Licence, a copy of which may be found in the file LICENCE. + +The use, supply, or promotion of Exim for the purpose of sending bulk, +unsolicited electronic mail is incompatible with the basic aims of Exim, which +revolve around the free provision of a service that enhances the quality of +personal communications. The author of Exim regards indiscriminate mass-mailing +as an antisocial, irresponsible abuse of the Internet. + +Exim owes a great deal to Smail 3 and its author, Ron Karr. Without the +experience of running and working on the Smail 3 code, I could never have +contemplated starting to write a new MTA. Many of the ideas and user interfaces +were originally taken from Smail 3, though the actual code of Exim is entirely +new, and has developed far beyond the initial concept. + +Many people, both in Cambridge and around the world, have contributed to the +development and the testing of Exim, and to porting it to various operating +systems. I am grateful to them all. The distribution now contains a file called +ACKNOWLEDGMENTS, in which I have started recording the names of contributors. + + +1.1 Exim documentation +---------------------- + +This edition of the Exim specification applies to version 4.92 of Exim. +Substantive changes from the 4.91 edition are marked in some renditions of this +document; this paragraph is so marked if the rendition is capable of showing a +change indicator. + +This document is very much a reference manual; it is not a tutorial. The reader +is expected to have some familiarity with the SMTP mail transfer protocol and +with general Unix system administration. Although there are some discussions +and examples in places, the information is mostly organized in a way that makes +it easy to look up, rather than in a natural order for sequential reading. +Furthermore, this manual aims to cover every aspect of Exim in detail, +including a number of rarely-used, special-purpose features that are unlikely +to be of very wide interest. + +An "easier" discussion of Exim which provides more in-depth explanatory, +introductory, and tutorial material can be found in a book entitled The Exim +SMTP Mail Server (second edition, 2007), published by UIT Cambridge (https:// +www.uit.co.uk/exim-book/). + +The book also contains a chapter that gives a general introduction to SMTP and +Internet mail. Inevitably, however, the book is unlikely to be fully up-to-date +with the latest release of Exim. (Note that the earlier book about Exim, +published by O'Reilly, covers Exim 3, and many things have changed in Exim 4.) + +If you are using a Debian distribution of Exim, you will find information about +Debian-specific features in the file /usr/share/doc/exim4-base/README.Debian. +The command man update-exim.conf is another source of Debian-specific +information. + +As Exim develops, there may be features in newer versions that have not yet +made it into this document, which is updated only when the most significant +digit of the fractional part of the version number changes. Specifications of +new features that are not yet in this manual are placed in the file doc/ +NewStuff in the Exim distribution. + +Some features may be classified as "experimental". These may change +incompatibly while they are developing, or even be withdrawn. For this reason, +they are not documented in this manual. Information about experimental features +can be found in the file doc/experimental.txt. + +All changes to Exim (whether new features, bug fixes, or other kinds of change) +are noted briefly in the file called doc/ChangeLog. + +This specification itself is available as an ASCII file in doc/spec.txt so that +it can easily be searched with a text editor. Other files in the doc directory +are: + +OptionLists.txt list of all options in alphabetical order +dbm.discuss.txt discussion about DBM libraries +exim.8 a man page of Exim's command line options +experimental.txt documentation of experimental features +filter.txt specification of the filter language +Exim3.upgrade upgrade notes from release 2 to release 3 +Exim4.upgrade upgrade notes from release 3 to release 4 +openssl.txt installing a current OpenSSL release + +The main specification and the specification of the filtering language are also +available in other formats (HTML, PostScript, PDF, and Texinfo). Section 1.5 +below tells you how to get hold of these. + + +1.2 FTP site and websites +------------------------- + +The primary site for Exim source distributions is the exim.org FTP site, +available over HTTPS, HTTP and FTP. These services, and the exim.org website, +are hosted at the University of Cambridge. + +As well as Exim distribution tar files, the Exim website contains a number of +differently formatted versions of the documentation. A recent addition to the +online information is the Exim wiki (https://wiki.exim.org), which contains +what used to be a separate FAQ, as well as various other examples, tips, and +know-how that have been contributed by Exim users. The wiki site should always +redirect to the correct place, which is currently provided by GitHub, and is +open to editing by anyone with a GitHub account. + +An Exim Bugzilla exists at https://bugs.exim.org. You can use this to report +bugs, and also to add items to the wish list. Please search first to check that +you are not duplicating a previous entry. Please do not ask for configuration +help in the bug-tracker. + + +1.3 Mailing lists +----------------- + +The following Exim mailing lists exist: + +exim-announce@exim.org Moderated, low volume announcements list +exim-users@exim.org General discussion list +exim-dev@exim.org Discussion of bugs, enhancements, etc. +exim-cvs@exim.org Automated commit messages from the VCS + +You can subscribe to these lists, change your existing subscriptions, and view +or search the archives via the mailing lists link on the Exim home page. If you +are using a Debian distribution of Exim, you may wish to subscribe to the +Debian-specific mailing list pkg-exim4-users@lists.alioth.debian.org via this +web page: + +https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-exim4-users + +Please ask Debian-specific questions on that list and not on the general Exim +lists. + + +1.4 Bug reports +--------------- + +Reports of obvious bugs can be emailed to bugs@exim.org or reported via the +Bugzilla (https://bugs.exim.org). However, if you are unsure whether some +behaviour is a bug or not, the best thing to do is to post a message to the +exim-dev mailing list and have it discussed. + + +1.5 Where to find the Exim distribution +--------------------------------------- + +The master distribution site for the Exim distribution is + +https://downloads.exim.org/ + +The service is available over HTTPS, HTTP and FTP. We encourage people to +migrate to HTTPS. + +The content served at https://downloads.exim.org/ is identical to the content +served at https://ftp.exim.org/pub/exim and ftp://ftp.exim.org/pub/exim. + +If accessing via a hostname containing ftp, then the file references that +follow are relative to the exim directories at these sites. If accessing via +the hostname downloads then the subdirectories described here are top-level +directories. + +There are now quite a number of independent mirror sites around the world. +Those that I know about are listed in the file called Mirrors. + +Within the top exim directory there are subdirectories called exim3 (for +previous Exim 3 distributions), exim4 (for the latest Exim 4 distributions), +and Testing for testing versions. In the exim4 subdirectory, the current +release can always be found in files called + +exim-n.nn.tar.xz +exim-n.nn.tar.gz +exim-n.nn.tar.bz2 + +where n.nn is the highest such version number in the directory. The three files +contain identical data; the only difference is the type of compression. The .xz +file is usually the smallest, while the .gz file is the most portable to old +systems. + +The distributions will be PGP signed by an individual key of the Release +Coordinator. This key will have a uid containing an email address in the +exim.org domain and will have signatures from other people, including other +Exim maintainers. We expect that the key will be in the "strong set" of PGP +keys. There should be a trust path to that key from the Exim Maintainer's PGP +keys, a version of which can be found in the release directory in the file +Exim-Maintainers-Keyring.asc. All keys used will be available in public +keyserver pools, such as pool.sks-keyservers.net. + +At the time of the last update, releases were being made by Jeremy Harris and +signed with key 0xBCE58C8CE41F32DF. Other recent keys used for signing are +those of Heiko Schlittermann, 0x26101B62F69376CE, and of Phil Pennock, +0x4D1E900E14C1CC04. + +The signatures for the tar bundles are in: + +exim-n.nn.tar.xz.asc +exim-n.nn.tar.gz.asc +exim-n.nn.tar.bz2.asc + +For each released version, the log of changes is made available in a separate +file in the directory ChangeLogs so that it is possible to find out what has +changed without having to download the entire distribution. + +The main distribution contains ASCII versions of this specification and other +documentation; other formats of the documents are available in separate files +inside the exim4 directory of the FTP site: + +exim-html-n.nn.tar.gz +exim-pdf-n.nn.tar.gz +exim-postscript-n.nn.tar.gz +exim-texinfo-n.nn.tar.gz + +These tar files contain only the doc directory, not the complete distribution, +and are also available in .bz2 and .xz forms. + + +1.6 Limitations +--------------- + + * Exim is designed for use as an Internet MTA, and therefore handles + addresses in RFC 2822 domain format only. It cannot handle UUCP "bang + paths", though simple two-component bang paths can be converted by a + straightforward rewriting configuration. This restriction does not prevent + Exim from being interfaced to UUCP as a transport mechanism, provided that + domain addresses are used. + + * Exim insists that every address it handles has a domain attached. For + incoming local messages, domainless addresses are automatically qualified + with a configured domain value. Configuration options specify from which + remote systems unqualified addresses are acceptable. These are then + qualified on arrival. + + * The only external transport mechanisms that are currently implemented are + SMTP and LMTP over a TCP/IP network (including support for IPv6). However, + a pipe transport is available, and there are facilities for writing + messages to files and pipes, optionally in batched SMTP format; these + facilities can be used to send messages to other transport mechanisms such + as UUCP, provided they can handle domain-style addresses. Batched SMTP + input is also catered for. + + * Exim is not designed for storing mail for dial-in hosts. When the volumes + of such mail are large, it is better to get the messages "delivered" into + files (that is, off Exim's queue) and subsequently passed on to the dial-in + hosts by other means. + + * Although Exim does have basic facilities for scanning incoming messages, + these are not comprehensive enough to do full virus or spam scanning. Such + operations are best carried out using additional specialized software + packages. If you compile Exim with the content-scanning extension, + straightforward interfaces to a number of common scanners are provided. + + +1.7 Runtime configuration +------------------------- + +Exim's runtime configuration is held in a single text file that is divided into +a number of sections. The entries in this file consist of keywords and values, +in the style of Smail 3 configuration files. A default configuration file which +is suitable for simple online installations is provided in the distribution, +and is described in chapter 7 below. + + +1.8 Calling interface +--------------------- + +Like many MTAs, Exim has adopted the Sendmail command line interface so that it +can be a straight replacement for /usr/lib/sendmail or /usr/sbin/sendmail when +sending mail, but you do not need to know anything about Sendmail in order to +run Exim. For actions other than sending messages, Sendmail-compatible options +also exist, but those that produce output (for example, -bp, which lists the +messages in the queue) do so in Exim's own format. There are also some +additional options that are compatible with Smail 3, and some further options +that are new to Exim. Chapter 5 documents all Exim's command line options. This +information is automatically made into the man page that forms part of the Exim +distribution. + +Control of messages in the queue can be done via certain privileged command +line options. There is also an optional monitor program called eximon, which +displays current information in an X window, and which contains a menu +interface to Exim's command line administration options. + + +1.9 Terminology +--------------- + +The body of a message is the actual data that the sender wants to transmit. It +is the last part of a message and is separated from the header (see below) by a +blank line. + +When a message cannot be delivered, it is normally returned to the sender in a +delivery failure message or a "non-delivery report" (NDR). The term bounce is +commonly used for this action, and the error reports are often called bounce +messages. This is a convenient shorthand for "delivery failure error report". +Such messages have an empty sender address in the message's envelope (see +below) to ensure that they cannot themselves give rise to further bounce +messages. + +The term default appears frequently in this manual. It is used to qualify a +value which is used in the absence of any setting in the configuration. It may +also qualify an action which is taken unless a configuration setting specifies +otherwise. + +The term defer is used when the delivery of a message to a specific destination +cannot immediately take place for some reason (a remote host may be down, or a +user's local mailbox may be full). Such deliveries are deferred until a later +time. + +The word domain is sometimes used to mean all but the first component of a +host's name. It is not used in that sense here, where it normally refers to the +part of an email address following the @ sign. + +A message in transit has an associated envelope, as well as a header and a +body. The envelope contains a sender address (to which bounce messages should +be delivered), and any number of recipient addresses. References to the sender +or the recipients of a message usually mean the addresses in the envelope. An +MTA uses these addresses for delivery, and for returning bounce messages, not +the addresses that appear in the header lines. + +The header of a message is the first part of a message's text, consisting of a +number of lines, each of which has a name such as From:, To:, Subject:, etc. +Long header lines can be split over several text lines by indenting the +continuations. The header is separated from the body by a blank line. + +The term local part, which is taken from RFC 2822, is used to refer to the part +of an email address that precedes the @ sign. The part that follows the @ sign +is called the domain or mail domain. + +The terms local delivery and remote delivery are used to distinguish delivery +to a file or a pipe on the local host from delivery by SMTP over TCP/IP to +another host. As far as Exim is concerned, all hosts other than the host it is +running on are remote. + +Return path is another name that is used for the sender address in a message's +envelope. + +The term queue is used to refer to the set of messages awaiting delivery +because this term is in widespread use in the context of MTAs. However, in +Exim's case, the reality is more like a pool than a queue, because there is +normally no ordering of waiting messages. + +The term queue runner is used to describe a process that scans the queue and +attempts to deliver those messages whose retry times have come. This term is +used by other MTAs and also relates to the command runq, but in Exim the +waiting messages are normally processed in an unpredictable order. + +The term spool directory is used for a directory in which Exim keeps the +messages in its queue - that is, those that it is in the process of delivering. +This should not be confused with the directory in which local mailboxes are +stored, which is called a "spool directory" by some people. In the Exim +documentation, "spool" is always used in the first sense. + + + +=============================================================================== +2. INCORPORATED CODE + +A number of pieces of external code are included in the Exim distribution. + + * Regular expressions are supported in the main Exim program and in the Exim + monitor using the freely-distributable PCRE library, copyright (c) + University of Cambridge. The source to PCRE is no longer shipped with Exim, + so you will need to use the version of PCRE shipped with your system, or + obtain and install the full version of the library from ftp:// + ftp.csx.cam.ac.uk/pub/software/programming/pcre. + + * Support for the cdb (Constant DataBase) lookup method is provided by code + contributed by Nigel Metheringham of (at the time he contributed it) Planet + Online Ltd. The implementation is completely contained within the code of + Exim. It does not link against an external cdb library. The code contains + the following statements: + + Copyright (c) 1998 Nigel Metheringham, Planet Online Ltd + + This program is free software; you can redistribute it and/or modify it + under the terms of the GNU General Public License as published by the + Free Software Foundation; either version 2 of the License, or (at your + option) any later version. This code implements Dan Bernstein's + Constant DataBase (cdb) spec. Information, the spec and sample code for + cdb can be obtained from https://cr.yp.to/cdb.html. This implementation + borrows some code from Dan Bernstein's implementation (which has no + license restrictions applied to it). + + * Client support for Microsoft's Secure Password Authentication is provided + by code contributed by Marc Prud'hommeaux. Server support was contributed + by Tom Kistner. This includes code taken from the Samba project, which is + released under the Gnu GPL. + + * Support for calling the Cyrus pwcheck and saslauthd daemons is provided by + code taken from the Cyrus-SASL library and adapted by Alexander S. + Sabourenkov. The permission notice appears below, in accordance with the + conditions expressed therein. + + Copyright (c) 2001 Carnegie Mellon University. All rights reserved. + + Redistribution and use in source and binary forms, with or without + modification, are permitted provided that the following conditions are + met: + + 1. Redistributions of source code must retain the above copyright + notice, this list of conditions and the following disclaimer. + + 2. Redistributions in binary form must reproduce the above copyright + notice, this list of conditions and the following disclaimer in the + documentation and/or other materials provided with the + distribution. + + 3. The name "Carnegie Mellon University" must not be used to endorse + or promote products derived from this software without prior + written permission. For permission or any other legal details, + please contact + + Office of Technology Transfer + Carnegie Mellon University + 5000 Forbes Avenue + Pittsburgh, PA 15213-3890 + (412) 268-4387, fax: (412) 268-7395 + tech-transfer@andrew.cmu.edu + + 4. Redistributions of any form whatsoever must retain the following + acknowledgment: + + "This product includes software developed by Computing Services at + Carnegie Mellon University (https://www.cmu.edu/computing/." + + CARNEGIE MELLON UNIVERSITY DISCLAIMS ALL WARRANTIES WITH REGARD TO + THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + AND FITNESS, IN NO EVENT SHALL CARNEGIE MELLON UNIVERSITY BE LIABLE + FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN + AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING + OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS + SOFTWARE. + + * The Exim Monitor program, which is an X-Window application, includes + modified versions of the Athena StripChart and TextPop widgets. This code + is copyright by DEC and MIT, and their permission notice appears below, in + accordance with the conditions expressed therein. + + Copyright 1987, 1988 by Digital Equipment Corporation, Maynard, + Massachusetts, and the Massachusetts Institute of Technology, + Cambridge, Massachusetts. + + All Rights Reserved + + Permission to use, copy, modify, and distribute this software and its + documentation for any purpose and without fee is hereby granted, + provided that the above copyright notice appear in all copies and that + both that copyright notice and this permission notice appear in + supporting documentation, and that the names of Digital or MIT not be + used in advertising or publicity pertaining to distribution of the + software without specific, written prior permission. + + DIGITAL DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, + INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO + EVENT SHALL DIGITAL BE LIABLE FOR ANY SPECIAL, INDIRECT OR + CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF + USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR + OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + PERFORMANCE OF THIS SOFTWARE. + + * The DMARC implementation uses the OpenDMARC library which is Copyrighted by + The Trusted Domain Project. Portions of Exim source which use OpenDMARC + derived code are indicated in the respective source files. The full + OpenDMARC license is provided in the LICENSE.opendmarc file contained in + the distributed source code. + + * Many people have contributed code fragments, some large, some small, that + were not covered by any specific license requirements. It is assumed that + the contributors are happy to see their code incorporated into Exim under + the GPL. + + + +=============================================================================== +3. HOW EXIM RECEIVES AND DELIVERS MAIL + + +3.1 Overall philosophy +---------------------- + +Exim is designed to work efficiently on systems that are permanently connected +to the Internet and are handling a general mix of mail. In such circumstances, +most messages can be delivered immediately. Consequently, Exim does not +maintain independent queues of messages for specific domains or hosts, though +it does try to send several messages in a single SMTP connection after a host +has been down, and it also maintains per-host retry information. + + +3.2 Policy control +------------------ + +Policy controls are now an important feature of MTAs that are connected to the +Internet. Perhaps their most important job is to stop MTAs from being abused as +"open relays" by misguided individuals who send out vast amounts of unsolicited +junk and want to disguise its source. Exim provides flexible facilities for +specifying policy controls on incoming mail: + + * Exim 4 (unlike previous versions of Exim) implements policy controls on + incoming mail by means of Access Control Lists (ACLs). Each list is a + series of statements that may either grant or deny access. ACLs can be used + at several places in the SMTP dialogue while receiving a message from a + remote host. However, the most common places are after each RCPT command, + and at the very end of the message. The sysadmin can specify conditions for + accepting or rejecting individual recipients or the entire message, + respectively, at these two points (see chapter 43). Denial of access + results in an SMTP error code. + + * An ACL is also available for locally generated, non-SMTP messages. In this + case, the only available actions are to accept or deny the entire message. + + * When Exim is compiled with the content-scanning extension, facilities are + provided in the ACL mechanism for passing the message to external virus and + /or spam scanning software. The result of such a scan is passed back to the + ACL, which can then use it to decide what to do with the message. + + * When a message has been received, either from a remote host or from the + local host, but before the final acknowledgment has been sent, a locally + supplied C function called local_scan() can be run to inspect the message + and decide whether to accept it or not (see chapter 45). If the message is + accepted, the list of recipients can be modified by the function. + + * Using the local_scan() mechanism is another way of calling external scanner + software. The SA-Exim add-on package works this way. It does not require + Exim to be compiled with the content-scanning extension. + + * After a message has been accepted, a further checking mechanism is + available in the form of the system filter (see chapter 46). This runs at + the start of every delivery process. + + +3.3 User filters +---------------- + +In a conventional Exim configuration, users are able to run private filters by +setting up appropriate .forward files in their home directories. See chapter 22 +(about the redirect router) for the configuration needed to support this, and +the separate document entitled Exim's interfaces to mail filtering for user +details. Two different kinds of filtering are available: + + * Sieve filters are written in the standard filtering language that is + defined by RFC 3028. + + * Exim filters are written in a syntax that is unique to Exim, but which is + more powerful than Sieve, which it pre-dates. + +User filters are run as part of the routing process, described below. + + +3.4 Message identification +-------------------------- + +Every message handled by Exim is given a message id which is sixteen characters +long. It is divided into three parts, separated by hyphens, for example +"16VDhn-0001bo-D3". Each part is a sequence of letters and digits, normally +encoding numbers in base 62. However, in the Darwin operating system (Mac OS X) +and when Exim is compiled to run under Cygwin, base 36 (avoiding the use of +lower case letters) is used instead, because the message id is used to +construct filenames, and the names of files in those systems are not always +case-sensitive. + +The detail of the contents of the message id have changed as Exim has evolved. +Earlier versions relied on the operating system not re-using a process id (pid) +within one second. On modern operating systems, this assumption can no longer +be made, so the algorithm had to be changed. To retain backward compatibility, +the format of the message id was retained, which is why the following rules are +somewhat eccentric: + + * The first six characters of the message id are the time at which the + message started to be received, to a granularity of one second. That is, + this field contains the number of seconds since the start of the epoch (the + normal Unix way of representing the date and time of day). + + * After the first hyphen, the next six characters are the id of the process + that received the message. + + * There are two different possibilities for the final two characters: + + 1. If localhost_number is not set, this value is the fractional part of + the time of reception, normally in units of 1/2000 of a second, but for + systems that must use base 36 instead of base 62 (because of + case-insensitive file systems), the units are 1/1000 of a second. + + 2. If localhost_number is set, it is multiplied by 200 (100) and added to + the fractional part of the time, which in this case is in units of 1/ + 200 (1/100) of a second. + +After a message has been received, Exim waits for the clock to tick at the +appropriate resolution before proceeding, so that if another message is +received by the same process, or by another process with the same (re-used) +pid, it is guaranteed that the time will be different. In most cases, the clock +will already have ticked while the message was being received. + + +3.5 Receiving mail +------------------ + +The only way Exim can receive mail from another host is using SMTP over TCP/IP, +in which case the sender and recipient addresses are transferred using SMTP +commands. However, from a locally running process (such as a user's MUA), there +are several possibilities: + + * If the process runs Exim with the -bm option, the message is read + non-interactively (usually via a pipe), with the recipients taken from the + command line, or from the body of the message if -t is also used. + + * If the process runs Exim with the -bS option, the message is also read + non-interactively, but in this case the recipients are listed at the start + of the message in a series of SMTP RCPT commands, terminated by a DATA + command. This is called "batch SMTP" format, but it isn't really SMTP. The + SMTP commands are just another way of passing envelope addresses in a + non-interactive submission. + + * If the process runs Exim with the -bs option, the message is read + interactively, using the SMTP protocol. A two-way pipe is normally used for + passing data between the local process and the Exim process. This is "real" + SMTP and is handled in the same way as SMTP over TCP/IP. For example, the + ACLs for SMTP commands are used for this form of submission. + + * A local process may also make a TCP/IP call to the host's loopback address + (127.0.0.1) or any other of its IP addresses. When receiving messages, Exim + does not treat the loopback address specially. It treats all such + connections in the same way as connections from other hosts. + +In the three cases that do not involve TCP/IP, the sender address is +constructed from the login name of the user that called Exim and a default +qualification domain (which can be set by the qualify_domain configuration +option). For local or batch SMTP, a sender address that is passed using the +SMTP MAIL command is ignored. However, the system administrator may allow +certain users ("trusted users") to specify a different sender addresses +unconditionally, or all users to specify certain forms of different sender +address. The -f option or the SMTP MAIL command is used to specify these +different addresses. See section 5.2 for details of trusted users, and the +untrusted_set_sender option for a way of allowing untrusted users to change +sender addresses. + +Messages received by either of the non-interactive mechanisms are subject to +checking by the non-SMTP ACL if one is defined. Messages received using SMTP +(either over TCP/IP or interacting with a local process) can be checked by a +number of ACLs that operate at different times during the SMTP session. Either +individual recipients or the entire message can be rejected if local policy +requirements are not met. The local_scan() function (see chapter 45) is run for +all incoming messages. + +Exim can be configured not to start a delivery process when a message is +received; this can be unconditional, or depend on the number of incoming SMTP +connections or the system load. In these situations, new messages wait on the +queue until a queue runner process picks them up. However, in standard +configurations under normal conditions, delivery is started as soon as a +message is received. + + +3.6 Handling an incoming message +-------------------------------- + +When Exim accepts a message, it writes two files in its spool directory. The +first contains the envelope information, the current status of the message, and +the header lines, and the second contains the body of the message. The names of +the two spool files consist of the message id, followed by "-H" for the file +containing the envelope and header, and "-D" for the data file. + +By default, all these message files are held in a single directory called input +inside the general Exim spool directory. Some operating systems do not perform +very well if the number of files in a directory gets large; to improve +performance in such cases, the split_spool_directory option can be used. This +causes Exim to split up the input files into 62 sub-directories whose names are +single letters or digits. When this is done, the queue is processed one +sub-directory at a time instead of all at once, which can improve overall +performance even when there are not enough files in each directory to affect +file system performance. + +The envelope information consists of the address of the message's sender and +the addresses of the recipients. This information is entirely separate from any +addresses contained in the header lines. The status of the message includes a +list of recipients who have already received the message. The format of the +first spool file is described in chapter 56. + +Address rewriting that is specified in the rewrite section of the configuration +(see chapter 31) is done once and for all on incoming addresses, both in the +header lines and the envelope, at the time the message is accepted. If during +the course of delivery additional addresses are generated (for example, via +aliasing), these new addresses are rewritten as soon as they are generated. At +the time a message is actually delivered (transported) further rewriting can +take place; because this is a transport option, it can be different for +different forms of delivery. It is also possible to specify the addition or +removal of certain header lines at the time the message is delivered (see +chapters 15 and 24). + + +3.7 Life of a message +--------------------- + +A message remains in the spool directory until it is completely delivered to +its recipients or to an error address, or until it is deleted by an +administrator or by the user who originally created it. In cases when delivery +cannot proceed - for example when a message can neither be delivered to its +recipients nor returned to its sender, the message is marked "frozen" on the +spool, and no more deliveries are attempted. + +An administrator can "thaw" such messages when the problem has been corrected, +and can also freeze individual messages by hand if necessary. In addition, an +administrator can force a delivery error, causing a bounce message to be sent. + +There are options called ignore_bounce_errors_after and timeout_frozen_after, +which discard frozen messages after a certain time. The first applies only to +frozen bounces, the second to all frozen messages. + +While Exim is working on a message, it writes information about each delivery +attempt to its main log file. This includes successful, unsuccessful, and +delayed deliveries for each recipient (see chapter 52). The log lines are also +written to a separate message log file for each message. These logs are solely +for the benefit of the administrator and are normally deleted along with the +spool files when processing of a message is complete. The use of individual +message logs can be disabled by setting no_message_logs; this might give an +improvement in performance on very busy systems. + +All the information Exim itself needs to set up a delivery is kept in the first +spool file, along with the header lines. When a successful delivery occurs, the +address is immediately written at the end of a journal file, whose name is the +message id followed by "-J". At the end of a delivery run, if there are some +addresses left to be tried again later, the first spool file (the "-H" file) is +updated to indicate which these are, and the journal file is then deleted. +Updating the spool file is done by writing a new file and renaming it, to +minimize the possibility of data loss. + +Should the system or Exim crash after a successful delivery but before the +spool file has been updated, the journal is left lying around. The next time +Exim attempts to deliver the message, it reads the journal file and updates the +spool file before proceeding. This minimizes the chances of double deliveries +caused by crashes. + + +3.8 Processing an address for delivery +-------------------------------------- + +The main delivery processing elements of Exim are called routers and transports +, and collectively these are known as drivers. Code for a number of them is +provided in the source distribution, and compile-time options specify which +ones are included in the binary. Runtime options specify which ones are +actually used for delivering messages. + +Each driver that is specified in the runtime configuration is an instance of +that particular driver type. Multiple instances are allowed; for example, you +can set up several different smtp transports, each with different option values +that might specify different ports or different timeouts. Each instance has its +own identifying name. In what follows we will normally use the instance name +when discussing one particular instance (that is, one specific configuration of +the driver), and the generic driver name when discussing the driver's features +in general. + +A router is a driver that operates on an address, either determining how its +delivery should happen, by assigning it to a specific transport, or converting +the address into one or more new addresses (for example, via an alias file). A +router may also explicitly choose to fail an address, causing it to be bounced. + +A transport is a driver that transmits a copy of the message from Exim's spool +to some destination. There are two kinds of transport: for a local transport, +the destination is a file or a pipe on the local host, whereas for a remote +transport the destination is some other host. A message is passed to a specific +transport as a result of successful routing. If a message has several +recipients, it may be passed to a number of different transports. + +An address is processed by passing it to each configured router instance in +turn, subject to certain preconditions, until a router accepts the address or +specifies that it should be bounced. We will describe this process in more +detail shortly. First, as a simple example, we consider how each recipient +address in a message is processed in a small configuration of three routers. + +To make this a more concrete example, it is described in terms of some actual +routers, but remember, this is only an example. You can configure Exim's +routers in many different ways, and there may be any number of routers in a +configuration. + +The first router that is specified in a configuration is often one that handles +addresses in domains that are not recognized specifically by the local host. +Typically these are addresses for arbitrary domains on the Internet. A +precondition is set up which looks for the special domains known to the host +(for example, its own domain name), and the router is run for addresses that do +not match. Typically, this is a router that looks up domains in the DNS in +order to find the hosts to which this address routes. If it succeeds, the +address is assigned to a suitable SMTP transport; if it does not succeed, the +router is configured to fail the address. + +The second router is reached only when the domain is recognized as one that +"belongs" to the local host. This router does redirection - also known as +aliasing and forwarding. When it generates one or more new addresses from the +original, each of them is routed independently from the start. Otherwise, the +router may cause an address to fail, or it may simply decline to handle the +address, in which case the address is passed to the next router. + +The final router in many configurations is one that checks to see if the +address belongs to a local mailbox. The precondition may involve a check to see +if the local part is the name of a login account, or it may look up the local +part in a file or a database. If its preconditions are not met, or if the +router declines, we have reached the end of the routers. When this happens, the +address is bounced. + + +3.9 Processing an address for verification +------------------------------------------ + +As well as being used to decide how to deliver to an address, Exim's routers +are also used for address verification. Verification can be requested as one of +the checks to be performed in an ACL for incoming messages, on both sender and +recipient addresses, and it can be tested using the -bv and -bvs command line +options. + +When an address is being verified, the routers are run in "verify mode". This +does not affect the way the routers work, but it is a state that can be +detected. By this means, a router can be skipped or made to behave differently +when verifying. A common example is a configuration in which the first router +sends all messages to a message-scanning program unless they have been +previously scanned. Thus, the first router accepts all addresses without any +checking, making it useless for verifying. Normally, the no_verify option would +be set for such a router, causing it to be skipped in verify mode. + + +3.10 Running an individual router +--------------------------------- + +As explained in the example above, a number of preconditions are checked before +running a router. If any are not met, the router is skipped, and the address is +passed to the next router. When all the preconditions on a router are met, the +router is run. What happens next depends on the outcome, which is one of the +following: + + * accept: The router accepts the address, and either assigns it to a + transport or generates one or more "child" addresses. Processing the + original address ceases unless the unseen option is set on the router. This + option can be used to set up multiple deliveries with different routing + (for example, for keeping archive copies of messages). When unseen is set, + the address is passed to the next router. Normally, however, an accept + return marks the end of routing. + + Any child addresses generated by the router are processed independently, + starting with the first router by default. It is possible to change this by + setting the redirect_router option to specify which router to start at for + child addresses. Unlike pass_router (see below) the router specified by + redirect_router may be anywhere in the router configuration. + + * pass: The router recognizes the address, but cannot handle it itself. It + requests that the address be passed to another router. By default, the + address is passed to the next router, but this can be changed by setting + the pass_router option. However, (unlike redirect_router) the named router + must be below the current router (to avoid loops). + + * decline: The router declines to accept the address because it does not + recognize it at all. By default, the address is passed to the next router, + but this can be prevented by setting the no_more option. When no_more is + set, all the remaining routers are skipped. In effect, no_more converts + decline into fail. + + * fail: The router determines that the address should fail, and queues it for + the generation of a bounce message. There is no further processing of the + original address unless unseen is set on the router. + + * defer: The router cannot handle the address at the present time. (A + database may be offline, or a DNS lookup may have timed out.) No further + processing of the address happens in this delivery attempt. It is tried + again next time the message is considered for delivery. + + * error: There is some error in the router (for example, a syntax error in + its configuration). The action is as for defer. + +If an address reaches the end of the routers without having been accepted by +any of them, it is bounced as unrouteable. The default error message in this +situation is "unrouteable address", but you can set your own message by making +use of the cannot_route_message option. This can be set for any router; the +value from the last router that "saw" the address is used. + +Sometimes while routing you want to fail a delivery when some conditions are +met but others are not, instead of passing the address on for further routing. +You can do this by having a second router that explicitly fails the delivery +when the relevant conditions are met. The redirect router has a "fail" facility +for this purpose. + + +3.11 Duplicate addresses +------------------------ + +Once routing is complete, Exim scans the addresses that are assigned to local +and remote transports and discards any duplicates that it finds. During this +check, local parts are treated case-sensitively. This happens only when +actually delivering a message; when testing routers with -bt, all the routed +addresses are shown. + + +3.12 Router preconditions +------------------------- + +The preconditions that are tested for each router are listed below, in the +order in which they are tested. The individual configuration options are +described in more detail in chapter 15. + + * The local_part_prefix and local_part_suffix options can specify that the + local parts handled by the router may or must have certain prefixes and/or + suffixes. If a mandatory affix (prefix or suffix) is not present, the + router is skipped. These conditions are tested first. When an affix is + present, it is removed from the local part before further processing, + including the evaluation of any other conditions. + + * Routers can be designated for use only when not verifying an address, that + is, only when routing it for delivery (or testing its delivery routing). If + the verify option is set false, the router is skipped when Exim is + verifying an address. Setting the verify option actually sets two options, + verify_sender and verify_recipient, which independently control the use of + the router for sender and recipient verification. You can set these options + directly if you want a router to be used for only one type of verification. + Note that cutthrough delivery is classed as a recipient verification for + this purpose. + + * If the address_test option is set false, the router is skipped when Exim is + run with the -bt option to test an address routing. This can be helpful + when the first router sends all new messages to a scanner of some sort; it + makes it possible to use -bt to test subsequent delivery routing without + having to simulate the effect of the scanner. + + * Routers can be designated for use only when verifying an address, as + opposed to routing it for delivery. The verify_only option controls this. + Again, cutthrough delivery counts as a verification. + + * Individual routers can be explicitly skipped when running the routers to + check an address given in the SMTP EXPN command (see the expn option). + + * If the domains option is set, the domain of the address must be in the set + of domains that it defines. + + * If the local_parts option is set, the local part of the address must be in + the set of local parts that it defines. If local_part_prefix or + local_part_suffix is in use, the prefix or suffix is removed from the local + part before this check. If you want to do precondition tests on local parts + that include affixes, you can do so by using a condition option (see below) + that uses the variables $local_part, $local_part_prefix, and + $local_part_suffix as necessary. + + * If the check_local_user option is set, the local part must be the name of + an account on the local host. If this check succeeds, the uid and gid of + the local user are placed in $local_user_uid and $local_user_gid and the + user's home directory is placed in $home; these values can be used in the + remaining preconditions. + + * If the router_home_directory option is set, it is expanded at this point, + because it overrides the value of $home. If this expansion were left till + later, the value of $home as set by check_local_user would be used in + subsequent tests. Having two different values of $home in the same router + could lead to confusion. + + * If the senders option is set, the envelope sender address must be in the + set of addresses that it defines. + + * If the require_files option is set, the existence or non-existence of + specified files is tested. + + * If the condition option is set, it is evaluated and tested. This option + uses an expanded string to allow you to set up your own custom + preconditions. Expanded strings are described in chapter 11. + +Note that require_files comes near the end of the list, so you cannot use it to +check for the existence of a file in which to lookup up a domain, local part, +or sender. However, as these options are all expanded, you can use the exists +expansion condition to make such tests within each condition. The require_files +option is intended for checking files that the router may be going to use +internally, or which are needed by a specific transport (for example, +.procmailrc). + + +3.13 Delivery in detail +----------------------- + +When a message is to be delivered, the sequence of events is as follows: + + * If a system-wide filter file is specified, the message is passed to it. The + filter may add recipients to the message, replace the recipients, discard + the message, cause a new message to be generated, or cause the message + delivery to fail. The format of the system filter file is the same as for + Exim user filter files, described in the separate document entitled Exim's + interfaces to mail filtering. (Note: Sieve cannot be used for system filter + files.) + + Some additional features are available in system filters - see chapter 46 + for details. Note that a message is passed to the system filter only once + per delivery attempt, however many recipients it has. However, if there are + several delivery attempts because one or more addresses could not be + immediately delivered, the system filter is run each time. The filter + condition first_delivery can be used to detect the first run of the system + filter. + + * Each recipient address is offered to each configured router, in turn, + subject to its preconditions, until one is able to handle it. If no router + can handle the address, that is, if they all decline, the address is + failed. Because routers can be targeted at particular domains, several + locally handled domains can be processed entirely independently of each + other. + + * A router that accepts an address may assign it to a local or a remote + transport. However, the transport is not run at this time. Instead, the + address is placed on a list for the particular transport, which will be run + later. Alternatively, the router may generate one or more new addresses + (typically from alias, forward, or filter files). New addresses are fed + back into this process from the top, but in order to avoid loops, a router + ignores any address which has an identically-named ancestor that was + processed by itself. + + * When all the routing has been done, addresses that have been successfully + handled are passed to their assigned transports. When local transports are + doing real local deliveries, they handle only one address at a time, but if + a local transport is being used as a pseudo-remote transport (for example, + to collect batched SMTP messages for transmission by some other means) + multiple addresses can be handled. Remote transports can always handle more + than one address at a time, but can be configured not to do so, or to + restrict multiple addresses to the same domain. + + * Each local delivery to a file or a pipe runs in a separate process under a + non-privileged uid, and these deliveries are run one at a time. Remote + deliveries also run in separate processes, normally under a uid that is + private to Exim ("the Exim user"), but in this case, several remote + deliveries can be run in parallel. The maximum number of simultaneous + remote deliveries for any one message is set by the remote_max_parallel + option. The order in which deliveries are done is not defined, except that + all local deliveries happen before any remote deliveries. + + * When it encounters a local delivery during a queue run, Exim checks its + retry database to see if there has been a previous temporary delivery + failure for the address before running the local transport. If there was a + previous failure, Exim does not attempt a new delivery until the retry time + for the address is reached. However, this happens only for delivery + attempts that are part of a queue run. Local deliveries are always + attempted when delivery immediately follows message reception, even if + retry times are set for them. This makes for better behaviour if one + particular message is causing problems (for example, causing quota + overflow, or provoking an error in a filter file). + + * Remote transports do their own retry handling, since an address may be + deliverable to one of a number of hosts, each of which may have a different + retry time. If there have been previous temporary failures and no host has + reached its retry time, no delivery is attempted, whether in a queue run or + not. See chapter 32 for details of retry strategies. + + * If there were any permanent errors, a bounce message is returned to an + appropriate address (the sender in the common case), with details of the + error for each failing address. Exim can be configured to send copies of + bounce messages to other addresses. + + * If one or more addresses suffered a temporary failure, the message is left + on the queue, to be tried again later. Delivery of these addresses is said + to be deferred. + + * When all the recipient addresses have either been delivered or bounced, + handling of the message is complete. The spool files and message log are + deleted, though the message log can optionally be preserved if required. + + +3.14 Retry mechanism +-------------------- + +Exim's mechanism for retrying messages that fail to get delivered at the first +attempt is the queue runner process. You must either run an Exim daemon that +uses the -q option with a time interval to start queue runners at regular +intervals or use some other means (such as cron) to start them. If you do not +arrange for queue runners to be run, messages that fail temporarily at the +first attempt will remain in your queue forever. A queue runner process works +its way through the queue, one message at a time, trying each delivery that has +passed its retry time. You can run several queue runners at once. + +Exim uses a set of configured rules to determine when next to retry the failing +address (see chapter 32). These rules also specify when Exim should give up +trying to deliver to the address, at which point it generates a bounce message. +If no retry rules are set for a particular host, address, and error +combination, no retries are attempted, and temporary errors are treated as +permanent. + + +3.15 Temporary delivery failure +------------------------------- + +There are many reasons why a message may not be immediately deliverable to a +particular address. Failure to connect to a remote machine (because it, or the +connection to it, is down) is one of the most common. Temporary failures may be +detected during routing as well as during the transport stage of delivery. +Local deliveries may be delayed if NFS files are unavailable, or if a mailbox +is on a file system where the user is over quota. Exim can be configured to +impose its own quotas on local mailboxes; where system quotas are set they will +also apply. + +If a host is unreachable for a period of time, a number of messages may be +waiting for it by the time it recovers, and sending them in a single SMTP +connection is clearly beneficial. Whenever a delivery to a remote host is +deferred, Exim makes a note in its hints database, and whenever a successful +SMTP delivery has happened, it looks to see if any other messages are waiting +for the same host. If any are found, they are sent over the same SMTP +connection, subject to a configuration limit as to the maximum number in any +one connection. + + +3.16 Permanent delivery failure +------------------------------- + +When a message cannot be delivered to some or all of its intended recipients, a +bounce message is generated. Temporary delivery failures turn into permanent +errors when their timeout expires. All the addresses that fail in a given +delivery attempt are listed in a single message. If the original message has +many recipients, it is possible for some addresses to fail in one delivery +attempt and others to fail subsequently, giving rise to more than one bounce +message. The wording of bounce messages can be customized by the administrator. +See chapter 49 for details. + +Bounce messages contain an X-Failed-Recipients: header line that lists the +failed addresses, for the benefit of programs that try to analyse such messages +automatically. + +A bounce message is normally sent to the sender of the original message, as +obtained from the message's envelope. For incoming SMTP messages, this is the +address given in the MAIL command. However, when an address is expanded via a +forward or alias file, an alternative address can be specified for delivery +failures of the generated addresses. For a mailing list expansion (see section +50.2) it is common to direct bounce messages to the manager of the list. + + +3.17 Failures to deliver bounce messages +---------------------------------------- + +If a bounce message (either locally generated or received from a remote host) +itself suffers a permanent delivery failure, the message is left in the queue, +but it is frozen, awaiting the attention of an administrator. There are options +that can be used to make Exim discard such failed messages, or to keep them for +only a short time (see timeout_frozen_after and ignore_bounce_errors_after). + + + +=============================================================================== +4. BUILDING AND INSTALLING EXIM + + +4.1 Unpacking +------------- + +Exim is distributed as a gzipped or bzipped tar file which, when unpacked, +creates a directory with the name of the current release (for example, +exim-4.92) into which the following files are placed: + + ACKNOWLEDGMENTS contains some acknowledgments + CHANGES contains a reference to where changes are documented + LICENCE the GNU General Public Licence + Makefile top-level make file + NOTICE conditions for the use of Exim + README list of files, directories and simple build instructions + +Other files whose names begin with README may also be present. The following +subdirectories are created: + + Local an empty directory for local configuration files + OS OS-specific files + doc documentation files + exim_monitor source files for the Exim monitor + scripts scripts used in the build process + src remaining source files + util independent utilities + +The main utility programs are contained in the src directory and are built with +the Exim binary. The util directory contains a few optional scripts that may be +useful to some sites. + + +4.2 Multiple machine architectures and operating systems +-------------------------------------------------------- + +The building process for Exim is arranged to make it easy to build binaries for +a number of different architectures and operating systems from the same set of +source files. Compilation does not take place in the src directory. Instead, a +build directory is created for each architecture and operating system. Symbolic +links to the sources are installed in this directory, which is where the actual +building takes place. In most cases, Exim can discover the machine architecture +and operating system for itself, but the defaults can be overridden if +necessary. A C99-capable compiler will be required for the build. + + +4.3 PCRE library +---------------- + +Exim no longer has an embedded PCRE library as the vast majority of modern +systems include PCRE as a system library, although you may need to install the +PCRE package or the PCRE development package for your operating system. If your +system has a normal PCRE installation the Exim build process will need no +further configuration. If the library or the headers are in an unusual location +you will need to either set the PCRE_LIBS and INCLUDE directives appropriately, +or set PCRE_CONFIG=yes to use the installed pcre-config command. If your +operating system has no PCRE support then you will need to obtain and build the +current PCRE from ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/. More +information on PCRE is available at https://www.pcre.org/. + + +4.4 DBM libraries +----------------- + +Even if you do not use any DBM files in your configuration, Exim still needs a +DBM library in order to operate, because it uses indexed files for its hints +databases. Unfortunately, there are a number of DBM libraries in existence, and +different operating systems often have different ones installed. + +If you are using Solaris, IRIX, one of the modern BSD systems, or a modern +Linux distribution, the DBM configuration should happen automatically, and you +may be able to ignore this section. Otherwise, you may have to learn more than +you would like about DBM libraries from what follows. + +Licensed versions of Unix normally contain a library of DBM functions operating +via the ndbm interface, and this is what Exim expects by default. Free versions +of Unix seem to vary in what they contain as standard. In particular, some +early versions of Linux have no default DBM library, and different distributors +have chosen to bundle different libraries with their packaged versions. +However, the more recent releases seem to have standardized on the Berkeley DB +library. + +Different DBM libraries have different conventions for naming the files they +use. When a program opens a file called dbmfile, there are several +possibilities: + + 1. A traditional ndbm implementation, such as that supplied as part of + Solaris, operates on two files called dbmfile.dir and dbmfile.pag. + + 2. The GNU library, gdbm, operates on a single file. If used via its ndbm + compatibility interface it makes two different hard links to it with names + dbmfile.dir and dbmfile.pag, but if used via its native interface, the + filename is used unmodified. + + 3. The Berkeley DB package, if called via its ndbm compatibility interface, + operates on a single file called dbmfile.db, but otherwise looks to the + programmer exactly the same as the traditional ndbm implementation. + + 4. If the Berkeley package is used in its native mode, it operates on a single + file called dbmfile; the programmer's interface is somewhat different to + the traditional ndbm interface. + + 5. To complicate things further, there are several very different versions of + the Berkeley DB package. Version 1.85 was stable for a very long time, + releases 2.x and 3.x were current for a while, but the latest versions when + Exim last revamped support were numbered 4.x. Maintenance of some of the + earlier releases has ceased. All versions of Berkeley DB could be obtained + from http://www.sleepycat.com/, which is now a redirect to their new + owner's page with far newer versions listed. It is probably wise to plan to + move your storage configurations away from Berkeley DB format, as today + there are smaller and simpler alternatives more suited to Exim's usage + model. + + 6. Yet another DBM library, called tdb, is available from https:// + sourceforge.net/projects/tdb/files/. It has its own interface, and also + operates on a single file. + +Exim and its utilities can be compiled to use any of these interfaces. In order +to use any version of the Berkeley DB package in native mode, you must set +USE_DB in an appropriate configuration file (typically Local/Makefile). For +example: + +USE_DB=yes + +Similarly, for gdbm you set USE_GDBM, and for tdb you set USE_TDB. An error is +diagnosed if you set more than one of these. + +At the lowest level, the build-time configuration sets none of these options, +thereby assuming an interface of type (1). However, some operating system +configuration files (for example, those for the BSD operating systems and +Linux) assume type (4) by setting USE_DB as their default, and the +configuration files for Cygwin set USE_GDBM. Anything you set in Local/Makefile +, however, overrides these system defaults. + +As well as setting USE_DB, USE_GDBM, or USE_TDB, it may also be necessary to +set DBMLIB, to cause inclusion of the appropriate library, as in one of these +lines: + +DBMLIB = -ldb +DBMLIB = -ltdb + +Settings like that will work if the DBM library is installed in the standard +place. Sometimes it is not, and the library's header file may also not be in +the default path. You may need to set INCLUDE to specify where the header file +is, and to specify the path to the library more fully in DBMLIB, as in this +example: + +INCLUDE=-I/usr/local/include/db-4.1 +DBMLIB=/usr/local/lib/db-4.1/libdb.a + +There is further detailed discussion about the various DBM libraries in the +file doc/dbm.discuss.txt in the Exim distribution. + + +4.5 Pre-building configuration +------------------------------ + +Before building Exim, a local configuration file that specifies options +independent of any operating system has to be created with the name Local/ +Makefile. A template for this file is supplied as the file src/EDITME, and it +contains full descriptions of all the option settings therein. These +descriptions are therefore not repeated here. If you are building Exim for the +first time, the simplest thing to do is to copy src/EDITME to Local/Makefile, +then read it and edit it appropriately. + +There are three settings that you must supply, because Exim will not build +without them. They are the location of the runtime configuration file +(CONFIGURE_FILE), the directory in which Exim binaries will be installed +(BIN_DIRECTORY), and the identity of the Exim user (EXIM_USER and maybe +EXIM_GROUP as well). The value of CONFIGURE_FILE can in fact be a +colon-separated list of filenames; Exim uses the first of them that exists. + +There are a few other parameters that can be specified either at build time or +at runtime, to enable the same binary to be used on a number of different +machines. However, if the locations of Exim's spool directory and log file +directory (if not within the spool directory) are fixed, it is recommended that +you specify them in Local/Makefile instead of at runtime, so that errors +detected early in Exim's execution (such as a malformed configuration file) can +be logged. + +Exim's interfaces for calling virus and spam scanning software directly from +access control lists are not compiled by default. If you want to include these +facilities, you need to set + +WITH_CONTENT_SCAN=yes + +in your Local/Makefile. For details of the facilities themselves, see chapter +44. + +If you are going to build the Exim monitor, a similar configuration process is +required. The file exim_monitor/EDITME must be edited appropriately for your +installation and saved under the name Local/eximon.conf. If you are happy with +the default settings described in exim_monitor/EDITME, Local/eximon.conf can be +empty, but it must exist. + +This is all the configuration that is needed in straightforward cases for known +operating systems. However, the building process is set up so that it is easy +to override options that are set by default or by operating-system-specific +configuration files, for example, to change the C compiler, which defaults to +gcc. See section 4.13 below for details of how to do this. + + +4.6 Support for iconv() +----------------------- + +The contents of header lines in messages may be encoded according to the rules +described RFC 2047. This makes it possible to transmit characters that are not +in the ASCII character set, and to label them as being in a particular +character set. When Exim is inspecting header lines by means of the $h_ +mechanism, it decodes them, and translates them into a specified character set +(default is set at build time). The translation is possible only if the +operating system supports the iconv() function. + +However, some of the operating systems that supply iconv() do not support very +many conversions. The GNU libiconv library (available from https://www.gnu.org/ +software/libiconv/) can be installed on such systems to remedy this deficiency, +as well as on systems that do not supply iconv() at all. After installing +libiconv, you should add + +HAVE_ICONV=yes + +to your Local/Makefile and rebuild Exim. + + +4.7 Including TLS/SSL encryption support +---------------------------------------- + +Exim can be built to support encrypted SMTP connections, using the STARTTLS +command as per RFC 2487. It can also support legacy clients that expect to +start a TLS session immediately on connection to a non-standard port (see the +tls_on_connect_ports runtime option and the -tls-on-connect command line +option). + +If you want to build Exim with TLS support, you must first install either the +OpenSSL or GnuTLS library. There is no cryptographic code in Exim itself for +implementing SSL. + +If OpenSSL is installed, you should set + +SUPPORT_TLS=yes +TLS_LIBS=-lssl -lcrypto + +in Local/Makefile. You may also need to specify the locations of the OpenSSL +library and include files. For example: + +SUPPORT_TLS=yes +TLS_LIBS=-L/usr/local/openssl/lib -lssl -lcrypto +TLS_INCLUDE=-I/usr/local/openssl/include/ + +If you have pkg-config available, then instead you can just use: + +SUPPORT_TLS=yes +USE_OPENSSL_PC=openssl + +If GnuTLS is installed, you should set + +SUPPORT_TLS=yes +USE_GNUTLS=yes +TLS_LIBS=-lgnutls -ltasn1 -lgcrypt + +in Local/Makefile, and again you may need to specify the locations of the +library and include files. For example: + +SUPPORT_TLS=yes +USE_GNUTLS=yes +TLS_LIBS=-L/usr/gnu/lib -lgnutls -ltasn1 -lgcrypt +TLS_INCLUDE=-I/usr/gnu/include + +If you have pkg-config available, then instead you can just use: + +SUPPORT_TLS=yes +USE_GNUTLS=yes +USE_GNUTLS_PC=gnutls + +You do not need to set TLS_INCLUDE if the relevant directory is already +specified in INCLUDE. Details of how to configure Exim to make use of TLS are +given in chapter 42. + + +4.8 Use of tcpwrappers +---------------------- + +Exim can be linked with the tcpwrappers library in order to check incoming SMTP +calls using the tcpwrappers control files. This may be a convenient alternative +to Exim's own checking facilities for installations that are already making use +of tcpwrappers for other purposes. To do this, you should set USE_TCP_WRAPPERS +in Local/Makefile, arrange for the file tcpd.h to be available at compile time, +and also ensure that the library libwrap.a is available at link time, typically +by including -lwrap in EXTRALIBS_EXIM. For example, if tcpwrappers is installed +in /usr/local, you might have + +USE_TCP_WRAPPERS=yes +CFLAGS=-O -I/usr/local/include +EXTRALIBS_EXIM=-L/usr/local/lib -lwrap + +in Local/Makefile. The daemon name to use in the tcpwrappers control files is +"exim". For example, the line + +exim : LOCAL 192.168.1. .friendly.domain.example + +in your /etc/hosts.allow file allows connections from the local host, from the +subnet 192.168.1.0/24, and from all hosts in friendly.domain.example. All other +connections are denied. The daemon name used by tcpwrappers can be changed at +build time by setting TCP_WRAPPERS_DAEMON_NAME in Local/Makefile, or by setting +tcp_wrappers_daemon_name in the configure file. Consult the tcpwrappers +documentation for further details. + + +4.9 Including support for IPv6 +------------------------------ + +Exim contains code for use on systems that have IPv6 support. Setting +"HAVE_IPV6=YES" in Local/Makefile causes the IPv6 code to be included; it may +also be necessary to set IPV6_INCLUDE and IPV6_LIBS on systems where the IPv6 +support is not fully integrated into the normal include and library files. + +Two different types of DNS record for handling IPv6 addresses have been +defined. AAAA records (analogous to A records for IPv4) are in use, and are +currently seen as the mainstream. Another record type called A6 was proposed as +better than AAAA because it had more flexibility. However, it was felt to be +over-complex, and its status was reduced to "experimental". Exim used to have a +compile option for including A6 record support but this has now been withdrawn. + + +4.10 Dynamically loaded lookup module support +--------------------------------------------- + +On some platforms, Exim supports not compiling all lookup types directly into +the main binary, instead putting some into external modules which can be loaded +on demand. This permits packagers to build Exim with support for lookups with +extensive library dependencies without requiring all users to install all of +those dependencies. Most, but not all, lookup types can be built this way. + +Set "LOOKUP_MODULE_DIR" to the directory into which the modules will be +installed; Exim will only load modules from that directory, as a security +measure. You will need to set "CFLAGS_DYNAMIC" if not already defined for your +OS; see OS/Makefile-Linux for an example. Some other requirements for adjusting +"EXTRALIBS" may also be necessary, see src/EDITME for details. + +Then, for each module to be loaded dynamically, define the relevant "LOOKUP_"< +lookup_type> flags to have the value "2" instead of "yes". For example, this +will build in lsearch but load sqlite and mysql support on demand: + +LOOKUP_LSEARCH=yes +LOOKUP_SQLITE=2 +LOOKUP_MYSQL=2 + + +4.11 The building process +------------------------- + +Once Local/Makefile (and Local/eximon.conf, if required) have been created, run +make at the top level. It determines the architecture and operating system +types, and creates a build directory if one does not exist. For example, on a +Sun system running Solaris 8, the directory build-SunOS5-5.8-sparc is created. +Symbolic links to relevant source files are installed in the build directory. + +If this is the first time make has been run, it calls a script that builds a +make file inside the build directory, using the configuration files from the +Local directory. The new make file is then passed to another instance of make. +This does the real work, building a number of utility scripts, and then +compiling and linking the binaries for the Exim monitor (if configured), a +number of utility programs, and finally Exim itself. The command "make +makefile" can be used to force a rebuild of the make file in the build +directory, should this ever be necessary. + +If you have problems building Exim, check for any comments there may be in the +README file concerning your operating system, and also take a look at the FAQ, +where some common problems are covered. + + +4.12 Output from "make" +----------------------- + +The output produced by the make process for compile lines is often very +unreadable, because these lines can be very long. For this reason, the normal +output is suppressed by default, and instead output similar to that which +appears when compiling the 2.6 Linux kernel is generated: just a short line for +each module that is being compiled or linked. However, it is still possible to +get the full output, by calling make like this: + +FULLECHO='' make -e + +The value of FULLECHO defaults to "@", the flag character that suppresses +command reflection in make. When you ask for the full output, it is given in +addition to the short output. + + +4.13 Overriding build-time options for Exim +------------------------------------------- + +The main make file that is created at the beginning of the building process +consists of the concatenation of a number of files which set configuration +values, followed by a fixed set of make instructions. If a value is set more +than once, the last setting overrides any previous ones. This provides a +convenient way of overriding defaults. The files that are concatenated are, in +order: + +OS/Makefile-Default +OS/Makefile-<ostype> +Local/Makefile +Local/Makefile-<ostype> +Local/Makefile-<archtype> +Local/Makefile-<ostype>-<archtype> +OS/Makefile-Base + +where <ostype> is the operating system type and <archtype> is the architecture +type. Local/Makefile is required to exist, and the building process fails if it +is absent. The other three Local files are optional, and are often not needed. + +The values used for <ostype> and <archtype> are obtained from scripts called +scripts/os-type and scripts/arch-type respectively. If either of the +environment variables EXIM_OSTYPE or EXIM_ARCHTYPE is set, their values are +used, thereby providing a means of forcing particular settings. Otherwise, the +scripts try to get values from the uname command. If this fails, the shell +variables OSTYPE and ARCHTYPE are inspected. A number of ad hoc transformations +are then applied, to produce the standard names that Exim expects. You can run +these scripts directly from the shell in order to find out what values are +being used on your system. + +OS/Makefile-Default contains comments about the variables that are set therein. +Some (but not all) are mentioned below. If there is something that needs +changing, review the contents of this file and the contents of the make file +for your operating system (OS/Makefile-<ostype>) to see what the default values +are. + +If you need to change any of the values that are set in OS/Makefile-Default or +in OS/Makefile-<ostype>, or to add any new definitions, you do not need to +change the original files. Instead, you should make the changes by putting the +new values in an appropriate Local file. For example, when building Exim in +many releases of the Tru64-Unix (formerly Digital UNIX, formerly DEC-OSF1) +operating system, it is necessary to specify that the C compiler is called cc +rather than gcc. Also, the compiler must be called with the option -std1, to +make it recognize some of the features of Standard C that Exim uses. (Most +other compilers recognize Standard C by default.) To do this, you should create +a file called Local/Makefile-OSF1 containing the lines + +CC=cc +CFLAGS=-std1 + +If you are compiling for just one operating system, it may be easier to put +these lines directly into Local/Makefile. + +Keeping all your local configuration settings separate from the distributed +files makes it easy to transfer them to new versions of Exim simply by copying +the contents of the Local directory. + +Exim contains support for doing LDAP, NIS, NIS+, and other kinds of file +lookup, but not all systems have these components installed, so the default is +not to include the relevant code in the binary. All the different kinds of file +and database lookup that Exim supports are implemented as separate code modules +which are included only if the relevant compile-time options are set. In the +case of LDAP, NIS, and NIS+, the settings for Local/Makefile are: + +LOOKUP_LDAP=yes +LOOKUP_NIS=yes +LOOKUP_NISPLUS=yes + +and similar settings apply to the other lookup types. They are all listed in +src/EDITME. In many cases the relevant include files and interface libraries +need to be installed before compiling Exim. However, there are some optional +lookup types (such as cdb) for which the code is entirely contained within +Exim, and no external include files or libraries are required. When a lookup +type is not included in the binary, attempts to configure Exim to use it cause +runtime configuration errors. + +Many systems now use a tool called pkg-config to encapsulate information about +how to compile against a library; Exim has some initial support for being able +to use pkg-config for lookups and authenticators. For any given makefile +variable which starts "LOOKUP_" or "AUTH_", you can add a new variable with the +"_PC" suffix in the name and assign as the value the name of the package to be +queried. The results of querying via the pkg-config command will be added to +the appropriate Makefile variables with "+=" directives, so your version of +make will need to support that syntax. For instance: + +LOOKUP_SQLITE=yes +LOOKUP_SQLITE_PC=sqlite3 +AUTH_GSASL=yes +AUTH_GSASL_PC=libgsasl +AUTH_HEIMDAL_GSSAPI=yes +AUTH_HEIMDAL_GSSAPI_PC=heimdal-gssapi + +Exim can be linked with an embedded Perl interpreter, allowing Perl subroutines +to be called during string expansion. To enable this facility, + +EXIM_PERL=perl.o + +must be defined in Local/Makefile. Details of this facility are given in +chapter 12. + +The location of the X11 libraries is something that varies a lot between +operating systems, and there may be different versions of X11 to cope with. +Exim itself makes no use of X11, but if you are compiling the Exim monitor, the +X11 libraries must be available. The following three variables are set in OS/ +Makefile-Default: + +X11=/usr/X11R6 +XINCLUDE=-I$(X11)/include +XLFLAGS=-L$(X11)/lib + +These are overridden in some of the operating-system configuration files. For +example, in OS/Makefile-SunOS5 there is + +X11=/usr/openwin +XINCLUDE=-I$(X11)/include +XLFLAGS=-L$(X11)/lib -R$(X11)/lib + +If you need to override the default setting for your operating system, place a +definition of all three of these variables into your Local/Makefile-<ostype> +file. + +If you need to add any extra libraries to the link steps, these can be put in a +variable called EXTRALIBS, which appears in all the link commands, but by +default is not defined. In contrast, EXTRALIBS_EXIM is used only on the command +for linking the main Exim binary, and not for any associated utilities. + +There is also DBMLIB, which appears in the link commands for binaries that use +DBM functions (see also section 4.4). Finally, there is EXTRALIBS_EXIMON, which +appears only in the link step for the Exim monitor binary, and which can be +used, for example, to include additional X11 libraries. + +The make file copes with rebuilding Exim correctly if any of the configuration +files are edited. However, if an optional configuration file is deleted, it is +necessary to touch the associated non-optional file (that is, Local/Makefile or +Local/eximon.conf) before rebuilding. + + +4.14 OS-specific header files +----------------------------- + +The OS directory contains a number of files with names of the form os.h- +<ostype>. These are system-specific C header files that should not normally +need to be changed. There is a list of macro settings that are recognized in +the file OS/os.configuring, which should be consulted if you are porting Exim +to a new operating system. + + +4.15 Overriding build-time options for the monitor +-------------------------------------------------- + +A similar process is used for overriding things when building the Exim monitor, +where the files that are involved are + +OS/eximon.conf-Default +OS/eximon.conf-<ostype> +Local/eximon.conf +Local/eximon.conf-<ostype> +Local/eximon.conf-<archtype> +Local/eximon.conf-<ostype>-<archtype> + +As with Exim itself, the final three files need not exist, and in this case the +OS/eximon.conf-<ostype> file is also optional. The default values in OS/ +eximon.conf-Default can be overridden dynamically by setting environment +variables of the same name, preceded by EXIMON_. For example, setting +EXIMON_LOG_DEPTH in the environment overrides the value of LOG_DEPTH at +runtime. + + +4.16 Installing Exim binaries and scripts +----------------------------------------- + +The command "make install" runs the exim_install script with no arguments. The +script copies binaries and utility scripts into the directory whose name is +specified by the BIN_DIRECTORY setting in Local/Makefile. The install script +copies files only if they are newer than the files they are going to replace. +The Exim binary is required to be owned by root and have the setuid bit set, +for normal configurations. Therefore, you must run "make install" as root so +that it can set up the Exim binary in this way. However, in some special +situations (for example, if a host is doing no local deliveries) it may be +possible to run Exim without making the binary setuid root (see chapter 55 for +details). + +Exim's runtime configuration file is named by the CONFIGURE_FILE setting in +Local/Makefile. If this names a single file, and the file does not exist, the +default configuration file src/configure.default is copied there by the +installation script. If a runtime configuration file already exists, it is left +alone. If CONFIGURE_FILE is a colon-separated list, naming several alternative +files, no default is installed. + +One change is made to the default configuration file when it is installed: the +default configuration contains a router that references a system aliases file. +The path to this file is set to the value specified by SYSTEM_ALIASES_FILE in +Local/Makefile (/etc/aliases by default). If the system aliases file does not +exist, the installation script creates it, and outputs a comment to the user. + +The created file contains no aliases, but it does contain comments about the +aliases a site should normally have. Mail aliases have traditionally been kept +in /etc/aliases. However, some operating systems are now using /etc/mail/ +aliases. You should check if yours is one of these, and change Exim's +configuration if necessary. + +The default configuration uses the local host's name as the only local domain, +and is set up to do local deliveries into the shared directory /var/mail, +running as the local user. System aliases and .forward files in users' home +directories are supported, but no NIS or NIS+ support is configured. Domains +other than the name of the local host are routed using the DNS, with delivery +over SMTP. + +It is possible to install Exim for special purposes (such as building a binary +distribution) in a private part of the file system. You can do this by a +command such as + +make DESTDIR=/some/directory/ install + +This has the effect of pre-pending the specified directory to all the file +paths, except the name of the system aliases file that appears in the default +configuration. (If a default alias file is created, its name is modified.) For +backwards compatibility, ROOT is used if DESTDIR is not set, but this usage is +deprecated. + +Running make install does not copy the Exim 4 conversion script convert4r4. You +will probably run this only once if you are upgrading from Exim 3. None of the +documentation files in the doc directory are copied, except for the info files +when you have set INFO_DIRECTORY, as described in section 4.17 below. + +For the utility programs, old versions are renamed by adding the suffix .O to +their names. The Exim binary itself, however, is handled differently. It is +installed under a name that includes the version number and the compile number, +for example, exim-4.92-1. The script then arranges for a symbolic link called +exim to point to the binary. If you are updating a previous version of Exim, +the script takes care to ensure that the name exim is never absent from the +directory (as seen by other processes). + +If you want to see what the make install will do before running it for real, +you can pass the -n option to the installation script by this command: + +make INSTALL_ARG=-n install + +The contents of the variable INSTALL_ARG are passed to the installation script. +You do not need to be root to run this test. Alternatively, you can run the +installation script directly, but this must be from within the build directory. +For example, from the top-level Exim directory you could use this command: + +(cd build-SunOS5-5.5.1-sparc; ../scripts/exim_install -n) + +There are two other options that can be supplied to the installation script. + + * -no_chown bypasses the call to change the owner of the installed binary to + root, and the call to make it a setuid binary. + + * -no_symlink bypasses the setting up of the symbolic link exim to the + installed binary. + +INSTALL_ARG can be used to pass these options to the script. For example: + +make INSTALL_ARG=-no_symlink install + +The installation script can also be given arguments specifying which files are +to be copied. For example, to install just the Exim binary, and nothing else, +without creating the symbolic link, you could use: + +make INSTALL_ARG='-no_symlink exim' install + + +4.17 Installing info documentation +---------------------------------- + +Not all systems use the GNU info system for documentation, and for this reason, +the Texinfo source of Exim's documentation is not included in the main +distribution. Instead it is available separately from the FTP site (see section +1.5). + +If you have defined INFO_DIRECTORY in Local/Makefile and the Texinfo source of +the documentation is found in the source tree, running "make install" +automatically builds the info files and installs them. + + +4.18 Setting up the spool directory +----------------------------------- + +When it starts up, Exim tries to create its spool directory if it does not +exist. The Exim uid and gid are used for the owner and group of the spool +directory. Sub-directories are automatically created in the spool directory as +necessary. + + +4.19 Testing +------------ + +Having installed Exim, you can check that the runtime configuration file is +syntactically valid by running the following command, which assumes that the +Exim binary directory is within your PATH environment variable: + +exim -bV + +If there are any errors in the configuration file, Exim outputs error messages. +Otherwise it outputs the version number and build date, the DBM library that is +being used, and information about which drivers and other optional code modules +are included in the binary. Some simple routing tests can be done by using the +address testing option. For example, + +exim -bt <local username> + +should verify that it recognizes a local mailbox, and + +exim -bt <remote address> + +a remote one. Then try getting it to deliver mail, both locally and remotely. +This can be done by passing messages directly to Exim, without going through a +user agent. For example: + +exim -v postmaster@your.domain.example +From: user@your.domain.example +To: postmaster@your.domain.example +Subject: Testing Exim + +This is a test message. +^D + +The -v option causes Exim to output some verification of what it is doing. In +this case you should see copies of three log lines, one for the message's +arrival, one for its delivery, and one containing "Completed". + +If you encounter problems, look at Exim's log files (mainlog and paniclog) to +see if there is any relevant information there. Another source of information +is running Exim with debugging turned on, by specifying the -d option. If a +message is stuck on Exim's spool, you can force a delivery with debugging +turned on by a command of the form + +exim -d -M <exim-message-id> + +You must be root or an "admin user" in order to do this. The -d option produces +rather a lot of output, but you can cut this down to specific areas. For +example, if you use -d-all+route only the debugging information relevant to +routing is included. (See the -d option in chapter 5 for more details.) + +One specific problem that has shown up on some sites is the inability to do +local deliveries into a shared mailbox directory, because it does not have the +"sticky bit" set on it. By default, Exim tries to create a lock file before +writing to a mailbox file, and if it cannot create the lock file, the delivery +is deferred. You can get round this either by setting the "sticky bit" on the +directory, or by setting a specific group for local deliveries and allowing +that group to create files in the directory (see the comments above the +local_delivery transport in the default configuration file). Another approach +is to configure Exim not to use lock files, but just to rely on fcntl() locking +instead. However, you should do this only if all user agents also use fcntl() +locking. For further discussion of locking issues, see chapter 26. + +One thing that cannot be tested on a system that is already running an MTA is +the receipt of incoming SMTP mail on the standard SMTP port. However, the -oX +option can be used to run an Exim daemon that listens on some other port, or +inetd can be used to do this. The -bh option and the exim_checkaccess utility +can be used to check out policy controls on incoming SMTP mail. + +Testing a new version on a system that is already running Exim can most easily +be done by building a binary with a different CONFIGURE_FILE setting. From +within the runtime configuration, all other file and directory names that Exim +uses can be altered, in order to keep it entirely clear of the production +version. + + +4.20 Replacing another MTA with Exim +------------------------------------ + +Building and installing Exim for the first time does not of itself put it in +general use. The name by which the system's MTA is called by mail user agents +is either /usr/sbin/sendmail, or /usr/lib/sendmail (depending on the operating +system), and it is necessary to make this name point to the exim binary in +order to get the user agents to pass messages to Exim. This is normally done by +renaming any existing file and making /usr/sbin/sendmail or /usr/lib/sendmail a +symbolic link to the exim binary. It is a good idea to remove any setuid +privilege and executable status from the old MTA. It is then necessary to stop +and restart the mailer daemon, if one is running. + +Some operating systems have introduced alternative ways of switching MTAs. For +example, if you are running FreeBSD, you need to edit the file /etc/mail/ +mailer.conf instead of setting up a symbolic link as just described. A typical +example of the contents of this file for running Exim is as follows: + +sendmail /usr/exim/bin/exim +send-mail /usr/exim/bin/exim +mailq /usr/exim/bin/exim -bp +newaliases /usr/bin/true + +Once you have set up the symbolic link, or edited /etc/mail/mailer.conf, your +Exim installation is "live". Check it by sending a message from your favourite +user agent. + +You should consider what to tell your users about the change of MTA. Exim may +have different capabilities to what was previously running, and there are +various operational differences such as the text of messages produced by +command line options and in bounce messages. If you allow your users to make +use of Exim's filtering capabilities, you should make the document entitled +Exim's interface to mail filtering available to them. + + +4.21 Upgrading Exim +------------------- + +If you are already running Exim on your host, building and installing a new +version automatically makes it available to MUAs, or any other programs that +call the MTA directly. However, if you are running an Exim daemon, you do need +to send it a HUP signal, to make it re-execute itself, and thereby pick up the +new binary. You do not need to stop processing mail in order to install a new +version of Exim. The install script does not modify an existing runtime +configuration file. + + +4.22 Stopping the Exim daemon on Solaris +---------------------------------------- + +The standard command for stopping the mailer daemon on Solaris is + +/etc/init.d/sendmail stop + +If /usr/lib/sendmail has been turned into a symbolic link, this script fails to +stop Exim because it uses the command ps -e and greps the output for the text +"sendmail"; this is not present because the actual program name (that is, +"exim") is given by the ps command with these options. A solution is to replace +the line that finds the process id with something like + +pid=`cat /var/spool/exim/exim-daemon.pid` + +to obtain the daemon's pid directly from the file that Exim saves it in. + +Note, however, that stopping the daemon does not "stop Exim". Messages can +still be received from local processes, and if automatic delivery is configured +(the normal case), deliveries will still occur. + + + +=============================================================================== +5. THE EXIM COMMAND LINE + +Exim's command line takes the standard Unix form of a sequence of options, each +starting with a hyphen character, followed by a number of arguments. The +options are compatible with the main options of Sendmail, and there are also +some additional options, some of which are compatible with Smail 3. Certain +combinations of options do not make sense, and provoke an error if used. The +form of the arguments depends on which options are set. + + +5.1 Setting options by program name +----------------------------------- + +If Exim is called under the name mailq, it behaves as if the option -bp were +present before any other options. The -bp option requests a listing of the +contents of the mail queue on the standard output. This feature is for +compatibility with some systems that contain a command of that name in one of +the standard libraries, symbolically linked to /usr/sbin/sendmail or /usr/lib/ +sendmail. + +If Exim is called under the name rsmtp it behaves as if the option -bS were +present before any other options, for compatibility with Smail. The -bS option +is used for reading in a number of messages in batched SMTP format. + +If Exim is called under the name rmail it behaves as if the -i and -oee options +were present before any other options, for compatibility with Smail. The name +rmail is used as an interface by some UUCP systems. + +If Exim is called under the name runq it behaves as if the option -q were +present before any other options, for compatibility with Smail. The -q option +causes a single queue runner process to be started. + +If Exim is called under the name newaliases it behaves as if the option -bi +were present before any other options, for compatibility with Sendmail. This +option is used for rebuilding Sendmail's alias file. Exim does not have the +concept of a single alias file, but can be configured to run a given command if +called with the -bi option. + + +5.2 Trusted and admin users +--------------------------- + +Some Exim options are available only to trusted users and others are available +only to admin users. In the description below, the phrases "Exim user" and +"Exim group" mean the user and group defined by EXIM_USER and EXIM_GROUP in +Local/Makefile or set by the exim_user and exim_group options. These do not +necessarily have to use the name "exim". + + * The trusted users are root, the Exim user, any user listed in the + trusted_users configuration option, and any user whose current group or any + supplementary group is one of those listed in the trusted_groups + configuration option. Note that the Exim group is not automatically + trusted. + + Trusted users are always permitted to use the -f option or a leading + "From " line to specify the envelope sender of a message that is passed to + Exim through the local interface (see the -bm and -f options below). See + the untrusted_set_sender option for a way of permitting non-trusted users + to set envelope senders. + + For a trusted user, there is never any check on the contents of the From: + header line, and a Sender: line is never added. Furthermore, any existing + Sender: line in incoming local (non-TCP/IP) messages is not removed. + + Trusted users may also specify a host name, host address, interface + address, protocol name, ident value, and authentication data when + submitting a message locally. Thus, they are able to insert messages into + Exim's queue locally that have the characteristics of messages received + from a remote host. Untrusted users may in some circumstances use -f, but + can never set the other values that are available to trusted users. + + * The admin users are root, the Exim user, and any user that is a member of + the Exim group or of any group listed in the admin_groups configuration + option. The current group does not have to be one of these groups. + + Admin users are permitted to list the queue, and to carry out certain + operations on messages, for example, to force delivery failures. It is also + necessary to be an admin user in order to see the full information provided + by the Exim monitor, and full debugging output. + + By default, the use of the -M, -q, -R, and -S options to cause Exim to + attempt delivery of messages on its queue is restricted to admin users. + However, this restriction can be relaxed by setting the prod_requires_admin + option false (that is, specifying no_prod_requires_admin). + + Similarly, the use of the -bp option to list all the messages in the queue + is restricted to admin users unless queue_list_requires_admin is set false. + +Warning: If you configure your system so that admin users are able to edit +Exim's configuration file, you are giving those users an easy way of getting +root. There is further discussion of this issue at the start of chapter 6. + + +5.3 Command line options +------------------------ + +Exim's command line options are described in alphabetical order below. If none +of the options that specifies a specific action (such as starting the daemon or +a queue runner, or testing an address, or receiving a message in a specific +format, or listing the queue) are present, and there is at least one argument +on the command line, -bm (accept a local message on the standard input, with +the arguments specifying the recipients) is assumed. Otherwise, Exim outputs a +brief message about itself and exits. + +-- + + This is a pseudo-option whose only purpose is to terminate the options and + therefore to cause subsequent command line items to be treated as arguments + rather than options, even if they begin with hyphens. + +--help + + This option causes Exim to output a few sentences stating what it is. The + same output is generated if the Exim binary is called with no options and + no arguments. + +--version + + This option is an alias for -bV and causes version information to be + displayed. + +-Ac, -Am + + These options are used by Sendmail for selecting configuration files and + are ignored by Exim. + +-B<type> + + This is a Sendmail option for selecting 7 or 8 bit processing. Exim is + 8-bit clean; it ignores this option. + +-bd + + This option runs Exim as a daemon, awaiting incoming SMTP connections. + Usually the -bd option is combined with the -q<time> option, to specify + that the daemon should also initiate periodic queue runs. + + The -bd option can be used only by an admin user. If either of the -d + (debugging) or -v (verifying) options are set, the daemon does not + disconnect from the controlling terminal. When running this way, it can be + stopped by pressing ctrl-C. + + By default, Exim listens for incoming connections to the standard SMTP port + on all the host's running interfaces. However, it is possible to listen on + other ports, on multiple ports, and only on specific interfaces. Chapter 13 + contains a description of the options that control this. + + When a listening daemon is started without the use of -oX (that is, without + overriding the normal configuration), it writes its process id to a file + called exim-daemon.pid in Exim's spool directory. This location can be + overridden by setting PID_FILE_PATH in Local/Makefile. The file is written + while Exim is still running as root. + + When -oX is used on the command line to start a listening daemon, the + process id is not written to the normal pid file path. However, -oP can be + used to specify a path on the command line if a pid file is required. + + The SIGHUP signal can be used to cause the daemon to re-execute itself. + This should be done whenever Exim's configuration file, or any file that is + incorporated into it by means of the .include facility, is changed, and + also whenever a new version of Exim is installed. It is not necessary to do + this when other files that are referenced from the configuration (for + example, alias files) are changed, because these are reread each time they + are used. + +-bdf + + This option has the same effect as -bd except that it never disconnects + from the controlling terminal, even when no debugging is specified. + +-be + + Run Exim in expansion testing mode. Exim discards its root privilege, to + prevent ordinary users from using this mode to read otherwise inaccessible + files. If no arguments are given, Exim runs interactively, prompting for + lines of data. Otherwise, it processes each argument in turn. + + If Exim was built with USE_READLINE=yes in Local/Makefile, it tries to load + the libreadline library dynamically whenever the -be option is used without + command line arguments. If successful, it uses the readline() function, + which provides extensive line-editing facilities, for reading the test + data. A line history is supported. + + Long expansion expressions can be split over several lines by using + backslash continuations. As in Exim's runtime configuration, white space at + the start of continuation lines is ignored. Each argument or data line is + passed through the string expansion mechanism, and the result is output. + Variable values from the configuration file (for example, $qualify_domain) + are available, but no message-specific values (such as $message_exim_id) + are set, because no message is being processed (but see -bem and -Mset). + + Note: If you use this mechanism to test lookups, and you change the data + files or databases you are using, you must exit and restart Exim before + trying the same lookup again. Otherwise, because each Exim process caches + the results of lookups, you will just get the same result as before. + + Macro processing is done on lines before string-expansion: new macros can + be defined and macros will be expanded. Because macros in the config file + are often used for secrets, those are only available to admin users. + +-bem <filename> + + This option operates like -be except that it must be followed by the name + of a file. For example: + + exim -bem /tmp/testmessage + + The file is read as a message (as if receiving a locally-submitted non-SMTP + message) before any of the test expansions are done. Thus, message-specific + variables such as $message_size and $header_from: are available. However, + no Received: header is added to the message. If the -t option is set, + recipients are read from the headers in the normal way, and are shown in + the $recipients variable. Note that recipients cannot be given on the + command line, because further arguments are taken as strings to expand + (just like -be). + +-bF <filename> + + This option is the same as -bf except that it assumes that the filter being + tested is a system filter. The additional commands that are available only + in system filters are recognized. + +-bf <filename> + + This option runs Exim in user filter testing mode; the file is the filter + file to be tested, and a test message must be supplied on the standard + input. If there are no message-dependent tests in the filter, an empty file + can be supplied. + + If you want to test a system filter file, use -bF instead of -bf. You can + use both -bF and -bf on the same command, in order to test a system filter + and a user filter in the same run. For example: + + exim -bF /system/filter -bf /user/filter </test/message + + This is helpful when the system filter adds header lines or sets filter + variables that are used by the user filter. + + If the test filter file does not begin with one of the special lines + + # Exim filter + # Sieve filter + + it is taken to be a normal .forward file, and is tested for validity under + that interpretation. See sections 22.4 to 22.6 for a description of the + possible contents of non-filter redirection lists. + + The result of an Exim command that uses -bf, provided no errors are + detected, is a list of the actions that Exim would try to take if presented + with the message for real. More details of filter testing are given in the + separate document entitled Exim's interfaces to mail filtering. + + When testing a filter file, the envelope sender can be set by the -f + option, or by a "From " line at the start of the test message. Various + parameters that would normally be taken from the envelope recipient address + of the message can be set by means of additional command line options (see + the next four options). + +-bfd <domain> + + This sets the domain of the recipient address when a filter file is being + tested by means of the -bf option. The default is the value of + $qualify_domain. + +-bfl <local part> + + This sets the local part of the recipient address when a filter file is + being tested by means of the -bf option. The default is the username of the + process that calls Exim. A local part should be specified with any prefix + or suffix stripped, because that is how it appears to the filter when a + message is actually being delivered. + +-bfp <prefix> + + This sets the prefix of the local part of the recipient address when a + filter file is being tested by means of the -bf option. The default is an + empty prefix. + +-bfs <suffix> + + This sets the suffix of the local part of the recipient address when a + filter file is being tested by means of the -bf option. The default is an + empty suffix. + +-bh <IP address> + + This option runs a fake SMTP session as if from the given IP address, using + the standard input and output. The IP address may include a port number at + the end, after a full stop. For example: + + exim -bh 10.9.8.7.1234 + exim -bh fe80::a00:20ff:fe86:a061.5678 + + When an IPv6 address is given, it is converted into canonical form. In the + case of the second example above, the value of $sender_host_address after + conversion to the canonical form is + "fe80:0000:0000:0a00:20ff:fe86:a061.5678". + + Comments as to what is going on are written to the standard error file. + These include lines beginning with "LOG" for anything that would have been + logged. This facility is provided for testing configuration options for + incoming messages, to make sure they implement the required policy. For + example, you can test your relay controls using -bh. + + Warning 1: You can test features of the configuration that rely on ident + (RFC 1413) information by using the -oMt option. However, Exim cannot + actually perform an ident callout when testing using -bh because there is + no incoming SMTP connection. + + Warning 2: Address verification callouts (see section 43.45) are also + skipped when testing using -bh. If you want these callouts to occur, use + -bhc instead. + + Messages supplied during the testing session are discarded, and nothing is + written to any of the real log files. There may be pauses when DNS (and + other) lookups are taking place, and of course these may time out. The -oMi + option can be used to specify a specific IP interface and port if this is + important, and -oMaa and -oMai can be used to set parameters as if the SMTP + session were authenticated. + + The exim_checkaccess utility is a "packaged" version of -bh whose output + just states whether a given recipient address from a given host is + acceptable or not. See section 53.8. + + Features such as authentication and encryption, where the client input is + not plain text, cannot easily be tested with -bh. Instead, you should use a + specialized SMTP test program such as swaks. + +-bhc <IP address> + + This option operates in the same way as -bh, except that address + verification callouts are performed if required. This includes consulting + and updating the callout cache database. + +-bi + + Sendmail interprets the -bi option as a request to rebuild its alias file. + Exim does not have the concept of a single alias file, and so it cannot + mimic this behaviour. However, calls to /usr/lib/sendmail with the -bi + option tend to appear in various scripts such as NIS make files, so the + option must be recognized. + + If -bi is encountered, the command specified by the bi_command + configuration option is run, under the uid and gid of the caller of Exim. + If the -oA option is used, its value is passed to the command as an + argument. The command set by bi_command may not contain arguments. The + command can use the exim_dbmbuild utility, or some other means, to rebuild + alias files if this is required. If the bi_command option is not set, + calling Exim with -bi is a no-op. + +-bI:help + + We shall provide various options starting "-bI:" for querying Exim for + information. The output of many of these will be intended for machine + consumption. This one is not. The -bI:help option asks Exim for a synopsis + of supported options beginning "-bI:". Use of any of these options shall + cause Exim to exit after producing the requested output. + +-bI:dscp + + This option causes Exim to emit an alphabetically sorted list of all + recognised DSCP names. + +-bI:sieve + + This option causes Exim to emit an alphabetically sorted list of all + supported Sieve protocol extensions on stdout, one per line. This is + anticipated to be useful for ManageSieve (RFC 5804) implementations, in + providing that protocol's "SIEVE" capability response line. As the precise + list may depend upon compile-time build options, which this option will + adapt to, this is the only way to guarantee a correct response. + +-bm + + This option runs an Exim receiving process that accepts an incoming, + locally-generated message on the standard input. The recipients are given + as the command arguments (except when -t is also present - see below). Each + argument can be a comma-separated list of RFC 2822 addresses. This is the + default option for selecting the overall action of an Exim call; it is + assumed if no other conflicting option is present. + + If any addresses in the message are unqualified (have no domain), they are + qualified by the values of the qualify_domain or qualify_recipient options, + as appropriate. The -bnq option (see below) provides a way of suppressing + this for special cases. + + Policy checks on the contents of local messages can be enforced by means of + the non-SMTP ACL. See chapter 43 for details. + + The return code is zero if the message is successfully accepted. Otherwise, + the action is controlled by the -oex option setting - see below. + + The format of the message must be as defined in RFC 2822, except that, for + compatibility with Sendmail and Smail, a line in one of the forms + + From sender Fri Jan 5 12:55 GMT 1997 + From sender Fri, 5 Jan 97 12:55:01 + + (with the weekday optional, and possibly with additional text after the + date) is permitted to appear at the start of the message. There appears to + be no authoritative specification of the format of this line. Exim + recognizes it by matching against the regular expression defined by the + uucp_from_pattern option, which can be changed if necessary. + + The specified sender is treated as if it were given as the argument to the + -f option, but if a -f option is also present, its argument is used in + preference to the address taken from the message. The caller of Exim must + be a trusted user for the sender of a message to be set in this way. + +-bmalware <filename> + + This debugging option causes Exim to scan the given file or directory + (depending on the used scanner interface), using the malware scanning + framework. The option of av_scanner influences this option, so if + av_scanner's value is dependent upon an expansion then the expansion should + have defaults which apply to this invocation. ACLs are not invoked, so if + av_scanner references an ACL variable then that variable will never be + populated and -bmalware will fail. + + Exim will have changed working directory before resolving the filename, so + using fully qualified pathnames is advisable. Exim will be running as the + Exim user when it tries to open the file, rather than as the invoking user. + This option requires admin privileges. + + The -bmalware option will not be extended to be more generally useful, + there are better tools for file-scanning. This option exists to help + administrators verify their Exim and AV scanner configuration. + +-bnq + + By default, Exim automatically qualifies unqualified addresses (those + without domains) that appear in messages that are submitted locally (that + is, not over TCP/IP). This qualification applies both to addresses in + envelopes, and addresses in header lines. Sender addresses are qualified + using qualify_domain, and recipient addresses using qualify_recipient + (which defaults to the value of qualify_domain). + + Sometimes, qualification is not wanted. For example, if -bS (batch SMTP) is + being used to re-submit messages that originally came from remote hosts + after content scanning, you probably do not want to qualify unqualified + addresses in header lines. (Such lines will be present only if you have not + enabled a header syntax check in the appropriate ACL.) + + The -bnq option suppresses all qualification of unqualified addresses in + messages that originate on the local host. When this is used, unqualified + addresses in the envelope provoke errors (causing message rejection) and + unqualified addresses in header lines are left alone. + +-bP + + If this option is given with no arguments, it causes the values of all + Exim's main configuration options to be written to the standard output. The + values of one or more specific options can be requested by giving their + names as arguments, for example: + + exim -bP qualify_domain hold_domains + + However, any option setting that is preceded by the word "hide" in the + configuration file is not shown in full, except to an admin user. For other + users, the output is as in this example: + + mysql_servers = <value not displayable> + + If config is given as an argument, the config is output, as it was parsed, + any include file resolved, any comment removed. + + If config_file is given as an argument, the name of the runtime + configuration file is output. (configure_file works too, for backward + compatibility.) If a list of configuration files was supplied, the value + that is output here is the name of the file that was actually used. + + If the -n flag is given, then for most modes of -bP operation the name will + not be output. + + If log_file_path or pid_file_path are given, the names of the directories + where log files and daemon pid files are written are output, respectively. + If these values are unset, log files are written in a sub-directory of the + spool directory called log, and the pid file is written directly into the + spool directory. + + If -bP is followed by a name preceded by "+", for example, + + exim -bP +local_domains + + it searches for a matching named list of any type (domain, host, address, + or local part) and outputs what it finds. + + If one of the words router, transport, or authenticator is given, followed + by the name of an appropriate driver instance, the option settings for that + driver are output. For example: + + exim -bP transport local_delivery + + The generic driver options are output first, followed by the driver's + private options. A list of the names of drivers of a particular type can be + obtained by using one of the words router_list, transport_list, or + authenticator_list, and a complete list of all drivers with their option + settings can be obtained by using routers, transports, or authenticators. + + If environment is given as an argument, the set of environment variables is + output, line by line. Using the -n flag suppresses the value of the + variables. + + If invoked by an admin user, then macro, macro_list and macros are + available, similarly to the drivers. Because macros are sometimes used for + storing passwords, this option is restricted. The output format is one item + per line. For the "-bP macro <name>" form, if no such macro is found the + exit status will be nonzero. + +-bp + + This option requests a listing of the contents of the mail queue on the + standard output. If the -bp option is followed by a list of message ids, + just those messages are listed. By default, this option can be used only by + an admin user. However, the queue_list_requires_admin option can be set + false to allow any user to see the queue. + + Each message in the queue is displayed as in the following example: + + 25m 2.9K 0t5C6f-0000c8-00 <alice@wonderland.fict.example> + red.king@looking-glass.fict.example + <other addresses> + + The first line contains the length of time the message has been in the + queue (in this case 25 minutes), the size of the message (2.9K), the unique + local identifier for the message, and the message sender, as contained in + the envelope. For bounce messages, the sender address is empty, and appears + as "<>". If the message was submitted locally by an untrusted user who + overrode the default sender address, the user's login name is shown in + parentheses before the sender address. + + If the message is frozen (attempts to deliver it are suspended) then the + text "*** frozen ***" is displayed at the end of this line. + + The recipients of the message (taken from the envelope, not the headers) + are displayed on subsequent lines. Those addresses to which the message has + already been delivered are marked with the letter D. If an original address + gets expanded into several addresses via an alias or forward file, the + original is displayed with a D only when deliveries for all of its child + addresses are complete. + +-bpa + + This option operates like -bp, but in addition it shows delivered addresses + that were generated from the original top level address(es) in each message + by alias or forwarding operations. These addresses are flagged with "+D" + instead of just "D". + +-bpc + + This option counts the number of messages in the queue, and writes the + total to the standard output. It is restricted to admin users, unless + queue_list_requires_admin is set false. + +-bpr + + This option operates like -bp, but the output is not sorted into + chronological order of message arrival. This can speed it up when there are + lots of messages in the queue, and is particularly useful if the output is + going to be post-processed in a way that doesn't need the sorting. + +-bpra + + This option is a combination of -bpr and -bpa. + +-bpru + + This option is a combination of -bpr and -bpu. + +-bpu + + This option operates like -bp but shows only undelivered top-level + addresses for each message displayed. Addresses generated by aliasing or + forwarding are not shown, unless the message was deferred after processing + by a router with the one_time option set. + +-brt + + This option is for testing retry rules, and it must be followed by up to + three arguments. It causes Exim to look for a retry rule that matches the + values and to write it to the standard output. For example: + + exim -brt bach.comp.mus.example + Retry rule: *.comp.mus.example F,2h,15m; F,4d,30m; + + See chapter 32 for a description of Exim's retry rules. The first argument, + which is required, can be a complete address in the form local_part@domain, + or it can be just a domain name. If the second argument contains a dot, it + is interpreted as an optional second domain name; if no retry rule is found + for the first argument, the second is tried. This ties in with Exim's + behaviour when looking for retry rules for remote hosts - if no rule is + found that matches the host, one that matches the mail domain is sought. + Finally, an argument that is the name of a specific delivery error, as used + in setting up retry rules, can be given. For example: + + exim -brt haydn.comp.mus.example quota_3d + Retry rule: *@haydn.comp.mus.example quota_3d F,1h,15m + +-brw + + This option is for testing address rewriting rules, and it must be followed + by a single argument, consisting of either a local part without a domain, + or a complete address with a fully qualified domain. Exim outputs how this + address would be rewritten for each possible place it might appear. See + chapter 31 for further details. + +-bS + + This option is used for batched SMTP input, which is an alternative + interface for non-interactive local message submission. A number of + messages can be submitted in a single run. However, despite its name, this + is not really SMTP input. Exim reads each message's envelope from SMTP + commands on the standard input, but generates no responses. If the caller + is trusted, or untrusted_set_sender is set, the senders in the SMTP MAIL + commands are believed; otherwise the sender is always the caller of Exim. + + The message itself is read from the standard input, in SMTP format (leading + dots doubled), terminated by a line containing just a single dot. An error + is provoked if the terminating dot is missing. A further message may then + follow. + + As for other local message submissions, the contents of incoming batch SMTP + messages can be checked using the non-SMTP ACL (see chapter 43). + Unqualified addresses are automatically qualified using qualify_domain and + qualify_recipient, as appropriate, unless the -bnq option is used. + + Some other SMTP commands are recognized in the input. HELO and EHLO act as + RSET; VRFY, EXPN, ETRN, and HELP act as NOOP; QUIT quits, ignoring the rest + of the standard input. + + If any error is encountered, reports are written to the standard output and + error streams, and Exim gives up immediately. The return code is 0 if no + error was detected; it is 1 if one or more messages were accepted before + the error was detected; otherwise it is 2. + + More details of input using batched SMTP are given in section 48.11. + +-bs + + This option causes Exim to accept one or more messages by reading SMTP + commands on the standard input, and producing SMTP replies on the standard + output. SMTP policy controls, as defined in ACLs (see chapter 43) are + applied. Some user agents use this interface as a way of passing + locally-generated messages to the MTA. + + In this usage, if the caller of Exim is trusted, or untrusted_set_sender is + set, the senders of messages are taken from the SMTP MAIL commands. + Otherwise the content of these commands is ignored and the sender is set up + as the calling user. Unqualified addresses are automatically qualified + using qualify_domain and qualify_recipient, as appropriate, unless the -bnq + option is used. + + The -bs option is also used to run Exim from inetd, as an alternative to + using a listening daemon. Exim can distinguish the two cases by checking + whether the standard input is a TCP/IP socket. When Exim is called from + inetd, the source of the mail is assumed to be remote, and the comments + above concerning senders and qualification do not apply. In this situation, + Exim behaves in exactly the same way as it does when receiving a message + via the listening daemon. + +-bt + + This option runs Exim in address testing mode, in which each argument is + taken as a recipient address to be tested for deliverability. The results + are written to the standard output. If a test fails, and the caller is not + an admin user, no details of the failure are output, because these might + contain sensitive information such as usernames and passwords for database + lookups. + + If no arguments are given, Exim runs in an interactive manner, prompting + with a right angle bracket for addresses to be tested. + + Unlike the -be test option, you cannot arrange for Exim to use the readline + () function, because it is running as root and there are security issues. + + Each address is handled as if it were the recipient address of a message + (compare the -bv option). It is passed to the routers and the result is + written to the standard output. However, any router that has + no_address_test set is bypassed. This can make -bt easier to use for + genuine routing tests if your first router passes everything to a scanner + program. + + The return code is 2 if any address failed outright; it is 1 if no address + failed outright but at least one could not be resolved for some reason. + Return code 0 is given only when all addresses succeed. + + Note: When actually delivering a message, Exim removes duplicate recipient + addresses after routing is complete, so that only one delivery takes place. + This does not happen when testing with -bt; the full results of routing are + always shown. + + Warning: -bt can only do relatively simple testing. If any of the routers + in the configuration makes any tests on the sender address of a message, + you can use the -f option to set an appropriate sender when running -bt + tests. Without it, the sender is assumed to be the calling user at the + default qualifying domain. However, if you have set up (for example) + routers whose behaviour depends on the contents of an incoming message, you + cannot test those conditions using -bt. The -N option provides a possible + way of doing such tests. + +-bV + + This option causes Exim to write the current version number, compilation + number, and compilation date of the exim binary to the standard output. It + also lists the DBM library that is being used, the optional modules (such + as specific lookup types), the drivers that are included in the binary, and + the name of the runtime configuration file that is in use. + + As part of its operation, -bV causes Exim to read and syntax check its + configuration file. However, this is a static check only. It cannot check + values that are to be expanded. For example, although a misspelt ACL verb + is detected, an error in the verb's arguments is not. You cannot rely on + -bV alone to discover (for example) all the typos in the configuration; + some realistic testing is needed. The -bh and -N options provide more + dynamic testing facilities. + +-bv + + This option runs Exim in address verification mode, in which each argument + is taken as a recipient address to be verified by the routers. (This does + not involve any verification callouts). During normal operation, + verification happens mostly as a consequence processing a verify condition + in an ACL (see chapter 43). If you want to test an entire ACL, possibly + including callouts, see the -bh and -bhc options. + + If verification fails, and the caller is not an admin user, no details of + the failure are output, because these might contain sensitive information + such as usernames and passwords for database lookups. + + If no arguments are given, Exim runs in an interactive manner, prompting + with a right angle bracket for addresses to be verified. + + Unlike the -be test option, you cannot arrange for Exim to use the readline + () function, because it is running as exim and there are security issues. + + Verification differs from address testing (the -bt option) in that routers + that have no_verify set are skipped, and if the address is accepted by a + router that has fail_verify set, verification fails. The address is + verified as a recipient if -bv is used; to test verification for a sender + address, -bvs should be used. + + If the -v option is not set, the output consists of a single line for each + address, stating whether it was verified or not, and giving a reason in the + latter case. Without -v, generating more than one address by redirection + causes verification to end successfully, without considering the generated + addresses. However, if just one address is generated, processing continues, + and the generated address must verify successfully for the overall + verification to succeed. + + When -v is set, more details are given of how the address has been handled, + and in the case of address redirection, all the generated addresses are + also considered. Verification may succeed for some and fail for others. + + The return code is 2 if any address failed outright; it is 1 if no address + failed outright but at least one could not be resolved for some reason. + Return code 0 is given only when all addresses succeed. + + If any of the routers in the configuration makes any tests on the sender + address of a message, you should use the -f option to set an appropriate + sender when running -bv tests. Without it, the sender is assumed to be the + calling user at the default qualifying domain. + +-bvs + + This option acts like -bv, but verifies the address as a sender rather than + a recipient address. This affects any rewriting and qualification that + might happen. + +-bw + + This option runs Exim as a daemon, awaiting incoming SMTP connections, + similarly to the -bd option. All port specifications on the command-line + and in the configuration file are ignored. Queue-running may not be + specified. + + In this mode, Exim expects to be passed a socket as fd 0 (stdin) which is + listening for connections. This permits the system to start up and have + inetd (or equivalent) listen on the SMTP ports, starting an Exim daemon for + each port only when the first connection is received. + + If the option is given as -bw<time> then the time is a timeout, after which + the daemon will exit, which should cause inetd to listen once more. + +-C <filelist> + + This option causes Exim to find the runtime configuration file from the + given list instead of from the list specified by the CONFIGURE_FILE + compile-time setting. Usually, the list will consist of just a single + filename, but it can be a colon-separated list of names. In this case, the + first file that exists is used. Failure to open an existing file stops Exim + from proceeding any further along the list, and an error is generated. + + When this option is used by a caller other than root, and the list is + different from the compiled-in list, Exim gives up its root privilege + immediately, and runs with the real and effective uid and gid set to those + of the caller. However, if a TRUSTED_CONFIG_LIST file is defined in Local/ + Makefile, that file contains a list of full pathnames, one per line, for + configuration files which are trusted. Root privilege is retained for any + configuration file so listed, as long as the caller is the Exim user (or + the user specified in the CONFIGURE_OWNER option, if any), and as long as + the configuration file is not writeable by inappropriate users or groups. + + Leaving TRUSTED_CONFIG_LIST unset precludes the possibility of testing a + configuration using -C right through message reception and delivery, even + if the caller is root. The reception works, but by that time, Exim is + running as the Exim user, so when it re-executes to regain privilege for + the delivery, the use of -C causes privilege to be lost. However, root can + test reception and delivery using two separate commands (one to put a + message in the queue, using -odq, and another to do the delivery, using -M + ). + + If ALT_CONFIG_PREFIX is defined in Local/Makefile, it specifies a prefix + string with which any file named in a -C command line option must start. In + addition, the filename must not contain the sequence "/../". However, if + the value of the -C option is identical to the value of CONFIGURE_FILE in + Local/Makefile, Exim ignores -C and proceeds as usual. There is no default + setting for ALT_CONFIG_PREFIX; when it is unset, any filename can be used + with -C. + + ALT_CONFIG_PREFIX can be used to confine alternative configuration files to + a directory to which only root has access. This prevents someone who has + broken into the Exim account from running a privileged Exim with an + arbitrary configuration file. + + The -C facility is useful for ensuring that configuration files are + syntactically correct, but cannot be used for test deliveries, unless the + caller is privileged, or unless it is an exotic configuration that does not + require privilege. No check is made on the owner or group of the files + specified by this option. + +-D<macro>=<value> + + This option can be used to override macro definitions in the configuration + file (see section 6.4). However, like -C, if it is used by an unprivileged + caller, it causes Exim to give up its root privilege. If DISABLE_D_OPTION + is defined in Local/Makefile, the use of -D is completely disabled, and its + use causes an immediate error exit. + + If WHITELIST_D_MACROS is defined in Local/Makefile then it should be a + colon-separated list of macros which are considered safe and, if -D only + supplies macros from this list, and the values are acceptable, then Exim + will not give up root privilege if the caller is root, the Exim run-time + user, or the CONFIGURE_OWNER, if set. This is a transition mechanism and is + expected to be removed in the future. Acceptable values for the macros + satisfy the regexp: "^[A-Za-z0-9_/.-]*$" + + The entire option (including equals sign if present) must all be within one + command line item. -D can be used to set the value of a macro to the empty + string, in which case the equals sign is optional. These two commands are + synonymous: + + exim -DABC ... + exim -DABC= ... + + To include spaces in a macro definition item, quotes must be used. If you + use quotes, spaces are permitted around the macro name and the equals sign. + For example: + + exim '-D ABC = something' ... + + -D may be repeated up to 10 times on a command line. Only macro names up to + 22 letters long can be set. + +-d<debug options> + + This option causes debugging information to be written to the standard + error stream. It is restricted to admin users because debugging output may + show database queries that contain password information. Also, the details + of users' filter files should be protected. If a non-admin user uses -d, + Exim writes an error message to the standard error stream and exits with a + non-zero return code. + + When -d is used, -v is assumed. If -d is given on its own, a lot of + standard debugging data is output. This can be reduced, or increased to + include some more rarely needed information, by directly following -d with + a string made up of names preceded by plus or minus characters. These add + or remove sets of debugging data, respectively. For example, -d+filter adds + filter debugging, whereas -d-all+filter selects only filter debugging. Note + that no spaces are allowed in the debug setting. The available debugging + categories are: + + acl ACL interpretation + auth authenticators + deliver general delivery logic + dns DNS lookups (see also resolver) + dnsbl DNS black list (aka RBL) code + exec arguments for execv() calls + expand detailed debugging for string expansions + filter filter handling + hints_lookup hints data lookups + host_lookup all types of name-to-IP address handling + ident ident lookup + interface lists of local interfaces + lists matching things in lists + load system load checks + local_scan can be used by local_scan() (see chapter 45) + lookup general lookup code and all lookups + memory memory handling + noutf8 modifier: avoid UTF-8 line-drawing + pid modifier: add pid to debug output lines + process_info setting info for the process log + queue_run queue runs + receive general message reception logic + resolver turn on the DNS resolver's debugging output + retry retry handling + rewrite address rewriting + route address routing + timestamp modifier: add timestamp to debug output lines + tls TLS logic + transport transports + uid changes of uid/gid and looking up uid/gid + verify address verification logic + all almost all of the above (see below), and also -v + + The "all" option excludes "memory" when used as "+all", but includes it for + "-all". The reason for this is that "+all" is something that people tend to + use when generating debug output for Exim maintainers. If "+memory" is + included, an awful lot of output that is very rarely of interest is + generated, so it now has to be explicitly requested. However, "-all" does + turn everything off. + + The "resolver" option produces output only if the DNS resolver was compiled + with DEBUG enabled. This is not the case in some operating systems. Also, + unfortunately, debugging output from the DNS resolver is written to stdout + rather than stderr. + + The default (-d with no argument) omits "expand", "filter", "interface", + "load", "memory", "pid", "resolver", and "timestamp". However, the "pid" + selector is forced when debugging is turned on for a daemon, which then + passes it on to any re-executed Exims. Exim also automatically adds the pid + to debug lines when several remote deliveries are run in parallel. + + The "timestamp" selector causes the current time to be inserted at the + start of all debug output lines. This can be useful when trying to track + down delays in processing. + + The "noutf8" selector disables the use of UTF-8 line-drawing characters to + group related information. When disabled. ascii-art is used instead. Using + the "+all" option does not set this modifier, + + If the debug_print option is set in any driver, it produces output whenever + any debugging is selected, or if -v is used. + +-dd<debug options> + + This option behaves exactly like -d except when used on a command that + starts a daemon process. In that case, debugging is turned off for the + subprocesses that the daemon creates. Thus, it is useful for monitoring the + behaviour of the daemon without creating as much output as full debugging + does. + +-dropcr + + This is an obsolete option that is now a no-op. It used to affect the way + Exim handled CR and LF characters in incoming messages. What happens now is + described in section 47.2. + +-E + + This option specifies that an incoming message is a locally-generated + delivery failure report. It is used internally by Exim when handling + delivery failures and is not intended for external use. Its only effect is + to stop Exim generating certain messages to the postmaster, as otherwise + message cascades could occur in some situations. As part of the same + option, a message id may follow the characters -E. If it does, the log + entry for the receipt of the new message contains the id, following "R=", + as a cross-reference. + +-ex + + There are a number of Sendmail options starting with -oe which seem to be + called by various programs without the leading o in the option. For + example, the vacation program uses -eq. Exim treats all options of the form + -ex as synonymous with the corresponding -oex options. + +-F <string> + + This option sets the sender's full name for use when a locally-generated + message is being accepted. In the absence of this option, the user's gecos + entry from the password data is used. As users are generally permitted to + alter their gecos entries, no security considerations are involved. White + space between -F and the <string> is optional. + +-f <address> + + This option sets the address of the envelope sender of a locally-generated + message (also known as the return path). The option can normally be used + only by a trusted user, but untrusted_set_sender can be set to allow + untrusted users to use it. + + Processes running as root or the Exim user are always trusted. Other + trusted users are defined by the trusted_users or trusted_groups options. + In the absence of -f, or if the caller is not trusted, the sender of a + local message is set to the caller's login name at the default qualify + domain. + + There is one exception to the restriction on the use of -f: an empty sender + can be specified by any user, trusted or not, to create a message that can + never provoke a bounce. An empty sender can be specified either as an empty + string, or as a pair of angle brackets with nothing between them, as in + these examples of shell commands: + + exim -f '<>' user@domain + exim -f "" user@domain + + In addition, the use of -f is not restricted when testing a filter file + with -bf or when testing or verifying addresses using the -bt or -bv + options. + + Allowing untrusted users to change the sender address does not of itself + make it possible to send anonymous mail. Exim still checks that the From: + header refers to the local user, and if it does not, it adds a Sender: + header, though this can be overridden by setting no_local_from_check. + + White space between -f and the <address> is optional (that is, they can be + given as two arguments or one combined argument). The sender of a + locally-generated message can also be set (when permitted) by an initial + "From " line in the message - see the description of -bm above - but if -f + is also present, it overrides "From ". + +-G + + This option is equivalent to an ACL applying: + + control = suppress_local_fixups + + for every message received. Note that Sendmail will complain about such bad + formatting, where Exim silently just does not fix it up. This may change in + future. + + As this affects audit information, the caller must be a trusted user to use + this option. + +-h <number> + + This option is accepted for compatibility with Sendmail, but has no effect. + (In Sendmail it overrides the "hop count" obtained by counting Received: + headers.) + +-i + + This option, which has the same effect as -oi, specifies that a dot on a + line by itself should not terminate an incoming, non-SMTP message. I can + find no documentation for this option in Solaris 2.4 Sendmail, but the + mailx command in Solaris 2.4 uses it. See also -ti. + +-L <tag> + + This option is equivalent to setting syslog_processname in the config file + and setting log_file_path to "syslog". Its use is restricted to + administrators. The configuration file has to be read and parsed, to + determine access rights, before this is set and takes effect, so early + configuration file errors will not honour this flag. + + The tag should not be longer than 32 characters. + +-M <message id> <message id> ... + + This option requests Exim to run a delivery attempt on each message in + turn. If any of the messages are frozen, they are automatically thawed + before the delivery attempt. The settings of queue_domains, + queue_smtp_domains, and hold_domains are ignored. + + Retry hints for any of the addresses are overridden - Exim tries to deliver + even if the normal retry time has not yet been reached. This option + requires the caller to be an admin user. However, there is an option called + prod_requires_admin which can be set false to relax this restriction (and + also the same requirement for the -q, -R, and -S options). + + The deliveries happen synchronously, that is, the original Exim process + does not terminate until all the delivery attempts have finished. No output + is produced unless there is a serious error. If you want to see what is + happening, use the -v option as well, or inspect Exim's main log. + +-Mar <message id> <address> <address> ... + + This option requests Exim to add the addresses to the list of recipients of + the message ("ar" for "add recipients"). The first argument must be a + message id, and the remaining ones must be email addresses. However, if the + message is active (in the middle of a delivery attempt), it is not altered. + This option can be used only by an admin user. + +-MC <transport> <hostname> <sequence number> <message id> + + This option is not intended for use by external callers. It is used + internally by Exim to invoke another instance of itself to deliver a + waiting message using an existing SMTP connection, which is passed as the + standard input. Details are given in chapter 48. This must be the final + option, and the caller must be root or the Exim user in order to use it. + +-MCA + + This option is not intended for use by external callers. It is used + internally by Exim in conjunction with the -MC option. It signifies that + the connection to the remote host has been authenticated. + +-MCD + + This option is not intended for use by external callers. It is used + internally by Exim in conjunction with the -MC option. It signifies that + the remote host supports the ESMTP DSN extension. + +-MCG <queue name> + + This option is not intended for use by external callers. It is used + internally by Exim in conjunction with the -MC option. It signifies that an + alternate queue is used, named by the following argument. + +-MCK + + This option is not intended for use by external callers. It is used + internally by Exim in conjunction with the -MC option. It signifies that a + remote host supports the ESMTP CHUNKING extension. + +-MCP + + This option is not intended for use by external callers. It is used + internally by Exim in conjunction with the -MC option. It signifies that + the server to which Exim is connected supports pipelining. + +-MCQ <process id> <pipe fd> + + This option is not intended for use by external callers. It is used + internally by Exim in conjunction with the -MC option when the original + delivery was started by a queue runner. It passes on the process id of the + queue runner, together with the file descriptor number of an open pipe. + Closure of the pipe signals the final completion of the sequence of + processes that are passing messages through the same SMTP connection. + +-MCS + + This option is not intended for use by external callers. It is used + internally by Exim in conjunction with the -MC option, and passes on the + fact that the SMTP SIZE option should be used on messages delivered down + the existing connection. + +-MCT + + This option is not intended for use by external callers. It is used + internally by Exim in conjunction with the -MC option, and passes on the + fact that the host to which Exim is connected supports TLS encryption. + +-MCt <IP address> <port> <cipher> + + This option is not intended for use by external callers. It is used + internally by Exim in conjunction with the -MC option, and passes on the + fact that the connection is being proxied by a parent process for handling + TLS encryption. The arguments give the local address and port being + proxied, and the TLS cipher. + +-Mc <message id> <message id> ... + + This option requests Exim to run a delivery attempt on each message, in + turn, but unlike the -M option, it does check for retry hints, and respects + any that are found. This option is not very useful to external callers. It + is provided mainly for internal use by Exim when it needs to re-invoke + itself in order to regain root privilege for a delivery (see chapter 55). + However, -Mc can be useful when testing, in order to run a delivery that + respects retry times and other options such as hold_domains that are + overridden when -M is used. Such a delivery does not count as a queue run. + If you want to run a specific delivery as if in a queue run, you should use + -q with a message id argument. A distinction between queue run deliveries + and other deliveries is made in one or two places. + +-Mes <message id> <address> + + This option requests Exim to change the sender address in the message to + the given address, which must be a fully qualified address or "<>" ("es" + for "edit sender"). There must be exactly two arguments. The first argument + must be a message id, and the second one an email address. However, if the + message is active (in the middle of a delivery attempt), its status is not + altered. This option can be used only by an admin user. + +-Mf <message id> <message id> ... + + This option requests Exim to mark each listed message as "frozen". This + prevents any delivery attempts taking place until the message is "thawed", + either manually or as a result of the auto_thaw configuration option. + However, if any of the messages are active (in the middle of a delivery + attempt), their status is not altered. This option can be used only by an + admin user. + +-Mg <message id> <message id> ... + + This option requests Exim to give up trying to deliver the listed messages, + including any that are frozen. However, if any of the messages are active, + their status is not altered. For non-bounce messages, a delivery error + message is sent to the sender, containing the text "cancelled by + administrator". Bounce messages are just discarded. This option can be used + only by an admin user. + +-Mmad <message id> <message id> ... + + This option requests Exim to mark all the recipient addresses in the + messages as already delivered ("mad" for "mark all delivered"). However, if + any message is active (in the middle of a delivery attempt), its status is + not altered. This option can be used only by an admin user. + +-Mmd <message id> <address> <address> ... + + This option requests Exim to mark the given addresses as already delivered + ("md" for "mark delivered"). The first argument must be a message id, and + the remaining ones must be email addresses. These are matched to recipient + addresses in the message in a case-sensitive manner. If the message is + active (in the middle of a delivery attempt), its status is not altered. + This option can be used only by an admin user. + +-Mrm <message id> <message id> ... + + This option requests Exim to remove the given messages from the queue. No + bounce messages are sent; each message is simply forgotten. However, if any + of the messages are active, their status is not altered. This option can be + used only by an admin user or by the user who originally caused the message + to be placed in the queue. + +-Mset <message id> + + This option is useful only in conjunction with -be (that is, when testing + string expansions). Exim loads the given message from its spool before + doing the test expansions, thus setting message-specific variables such as + $message_size and the header variables. The $recipients variable is made + available. This feature is provided to make it easier to test expansions + that make use of these variables. However, this option can be used only by + an admin user. See also -bem. + +-Mt <message id> <message id> ... + + This option requests Exim to "thaw" any of the listed messages that are + "frozen", so that delivery attempts can resume. However, if any of the + messages are active, their status is not altered. This option can be used + only by an admin user. + +-Mvb <message id> + + This option causes the contents of the message body (-D) spool file to be + written to the standard output. This option can be used only by an admin + user. + +-Mvc <message id> + + This option causes a copy of the complete message (header lines plus body) + to be written to the standard output in RFC 2822 format. This option can be + used only by an admin user. + +-Mvh <message id> + + This option causes the contents of the message headers (-H) spool file to + be written to the standard output. This option can be used only by an admin + user. + +-Mvl <message id> + + This option causes the contents of the message log spool file to be written + to the standard output. This option can be used only by an admin user. + +-m + + This is apparently a synonym for -om that is accepted by Sendmail, so Exim + treats it that way too. + +-N + + This is a debugging option that inhibits delivery of a message at the + transport level. It implies -v. Exim goes through many of the motions of + delivery - it just doesn't actually transport the message, but instead + behaves as if it had successfully done so. However, it does not make any + updates to the retry database, and the log entries for deliveries are + flagged with "*>" rather than "=>". + + Because -N discards any message to which it applies, only root or the Exim + user are allowed to use it with -bd, -q, -R or -M. In other words, an + ordinary user can use it only when supplying an incoming message to which + it will apply. Although transportation never fails when -N is set, an + address may be deferred because of a configuration problem on a transport, + or a routing problem. Once -N has been used for a delivery attempt, it + sticks to the message, and applies to any subsequent delivery attempts that + may happen for that message. + +-n + + This option is interpreted by Sendmail to mean "no aliasing". For normal + modes of operation, it is ignored by Exim. When combined with -bP it makes + the output more terse (suppresses option names, environment values and + config pretty printing). + +-O <data> + + This option is interpreted by Sendmail to mean "set option". It is ignored + by Exim. + +-oA <file name> + + This option is used by Sendmail in conjunction with -bi to specify an + alternative alias filename. Exim handles -bi differently; see the + description above. + +-oB <n> + + This is a debugging option which limits the maximum number of messages that + can be delivered down one SMTP connection, overriding the value set in any + smtp transport. If <n> is omitted, the limit is set to 1. + +-odb + + This option applies to all modes in which Exim accepts incoming messages, + including the listening daemon. It requests "background" delivery of such + messages, which means that the accepting process automatically starts a + delivery process for each message received, but does not wait for the + delivery processes to finish. + + When all the messages have been received, the reception process exits, + leaving the delivery processes to finish in their own time. The standard + output and error streams are closed at the start of each delivery process. + This is the default action if none of the -od options are present. + + If one of the queueing options in the configuration file (queue_only or + queue_only_file, for example) is in effect, -odb overrides it if + queue_only_override is set true, which is the default setting. If + queue_only_override is set false, -odb has no effect. + +-odf + + This option requests "foreground" (synchronous) delivery when Exim has + accepted a locally-generated message. (For the daemon it is exactly the + same as -odb.) A delivery process is automatically started to deliver the + message, and Exim waits for it to complete before proceeding. + + The original Exim reception process does not finish until the delivery + process for the final message has ended. The standard error stream is left + open during deliveries. + + However, like -odb, this option has no effect if queue_only_override is + false and one of the queueing options in the configuration file is in + effect. + + If there is a temporary delivery error during foreground delivery, the + message is left in the queue for later delivery, and the original reception + process exits. See chapter 51 for a way of setting up a restricted + configuration that never queues messages. + +-odi + + This option is synonymous with -odf. It is provided for compatibility with + Sendmail. + +-odq + + This option applies to all modes in which Exim accepts incoming messages, + including the listening daemon. It specifies that the accepting process + should not automatically start a delivery process for each message + received. Messages are placed in the queue, and remain there until a + subsequent queue runner process encounters them. There are several + configuration options (such as queue_only) that can be used to queue + incoming messages under certain conditions. This option overrides all of + them and also -odqs. It always forces queueing. + +-odqs + + This option is a hybrid between -odb/-odi and -odq. However, like -odb and + -odi, this option has no effect if queue_only_override is false and one of + the queueing options in the configuration file is in effect. + + When -odqs does operate, a delivery process is started for each incoming + message, in the background by default, but in the foreground if -odi is + also present. The recipient addresses are routed, and local deliveries are + done in the normal way. However, if any SMTP deliveries are required, they + are not done at this time, so the message remains in the queue until a + subsequent queue runner process encounters it. Because routing was done, + Exim knows which messages are waiting for which hosts, and so a number of + messages for the same host can be sent in a single SMTP connection. The + queue_smtp_domains configuration option has the same effect for specific + domains. See also the -qq option. + +-oee + + If an error is detected while a non-SMTP message is being received (for + example, a malformed address), the error is reported to the sender in a + mail message. + + Provided this error message is successfully sent, the Exim receiving + process exits with a return code of zero. If not, the return code is 2 if + the problem is that the original message has no recipients, or 1 for any + other error. This is the default -oex option if Exim is called as rmail. + +-oem + + This is the same as -oee, except that Exim always exits with a non-zero + return code, whether or not the error message was successfully sent. This + is the default -oex option, unless Exim is called as rmail. + +-oep + + If an error is detected while a non-SMTP message is being received, the + error is reported by writing a message to the standard error file (stderr). + The return code is 1 for all errors. + +-oeq + + This option is supported for compatibility with Sendmail, but has the same + effect as -oep. + +-oew + + This option is supported for compatibility with Sendmail, but has the same + effect as -oem. + +-oi + + This option, which has the same effect as -i, specifies that a dot on a + line by itself should not terminate an incoming, non-SMTP message. + Otherwise, a single dot does terminate, though Exim does no special + processing for other lines that start with a dot. This option is set by + default if Exim is called as rmail. See also -ti. + +-oitrue + + This option is treated as synonymous with -oi. + +-oMa <host address> + + A number of options starting with -oM can be used to set values associated + with remote hosts on locally-submitted messages (that is, messages not + received over TCP/IP). These options can be used by any caller in + conjunction with the -bh, -be, -bf, -bF, -bt, or -bv testing options. In + other circumstances, they are ignored unless the caller is trusted. + + The -oMa option sets the sender host address. This may include a port + number at the end, after a full stop (period). For example: + + exim -bs -oMa 10.9.8.7.1234 + + An alternative syntax is to enclose the IP address in square brackets, + followed by a colon and the port number: + + exim -bs -oMa [10.9.8.7]:1234 + + The IP address is placed in the $sender_host_address variable, and the + port, if present, in $sender_host_port. If both -oMa and -bh are present on + the command line, the sender host IP address is taken from whichever one is + last. + +-oMaa <name> + + See -oMa above for general remarks about the -oM options. The -oMaa option + sets the value of $sender_host_authenticated (the authenticator name). See + chapter 33 for a discussion of SMTP authentication. This option can be used + with -bh and -bs to set up an authenticated SMTP session without actually + using the SMTP AUTH command. + +-oMai <string> + + See -oMa above for general remarks about the -oM options. The -oMai option + sets the value of $authenticated_id (the id that was authenticated). This + overrides the default value (the caller's login id, except with -bh, where + there is no default) for messages from local sources. See chapter 33 for a + discussion of authenticated ids. + +-oMas <address> + + See -oMa above for general remarks about the -oM options. The -oMas option + sets the authenticated sender value in $authenticated_sender. It overrides + the sender address that is created from the caller's login id for messages + from local sources, except when -bh is used, when there is no default. For + both -bh and -bs, an authenticated sender that is specified on a MAIL + command overrides this value. See chapter 33 for a discussion of + authenticated senders. + +-oMi <interface address> + + See -oMa above for general remarks about the -oM options. The -oMi option + sets the IP interface address value. A port number may be included, using + the same syntax as for -oMa. The interface address is placed in + $received_ip_address and the port number, if present, in $received_port. + +-oMm <message reference> + + See -oMa above for general remarks about the -oM options. The -oMm option + sets the message reference, e.g. message-id, and is logged during delivery. + This is useful when some kind of audit trail is required to tie messages + together. The format of the message reference is checked and will abort if + the format is invalid. The option will only be accepted if exim is running + in trusted mode, not as any regular user. + + The best example of a message reference is when Exim sends a bounce + message. The message reference is the message-id of the original message + for which Exim is sending the bounce. + +-oMr <protocol name> + + See -oMa above for general remarks about the -oM options. The -oMr option + sets the received protocol value that is stored in $received_protocol. + However, it does not apply (and is ignored) when -bh or -bs is used. For + -bh, the protocol is forced to one of the standard SMTP protocol names (see + the description of $received_protocol in section 11.9). For -bs, the + protocol is always "local-" followed by one of those same names. For -bS + (batched SMTP) however, the protocol can be set by -oMr. Repeated use of + this option is not supported. + +-oMs <host name> + + See -oMa above for general remarks about the -oM options. The -oMs option + sets the sender host name in $sender_host_name. When this option is + present, Exim does not attempt to look up a host name from an IP address; + it uses the name it is given. + +-oMt <ident string> + + See -oMa above for general remarks about the -oM options. The -oMt option + sets the sender ident value in $sender_ident. The default setting for local + callers is the login id of the calling process, except when -bh is used, + when there is no default. + +-om + + In Sendmail, this option means "me too", indicating that the sender of a + message should receive a copy of the message if the sender appears in an + alias expansion. Exim always does this, so the option does nothing. + +-oo + + This option is ignored. In Sendmail it specifies "old style headers", + whatever that means. + +-oP <path> + + This option is useful only in conjunction with -bd or -q with a time value. + The option specifies the file to which the process id of the daemon is + written. When -oX is used with -bd, or when -q with a time is used without + -bd, this is the only way of causing Exim to write a pid file, because in + those cases, the normal pid file is not used. + +-or <time> + + This option sets a timeout value for incoming non-SMTP messages. If it is + not set, Exim will wait forever for the standard input. The value can also + be set by the receive_timeout option. The format used for specifying times + is described in section 6.16. + +-os <time> + + This option sets a timeout value for incoming SMTP messages. The timeout + applies to each SMTP command and block of data. The value can also be set + by the smtp_receive_timeout option; it defaults to 5 minutes. The format + used for specifying times is described in section 6.16. + +-ov + + This option has exactly the same effect as -v. + +-oX <number or string> + + This option is relevant only when the -bd (start listening daemon) option + is also given. It controls which ports and interfaces the daemon uses. + Details of the syntax, and how it interacts with configuration file + options, are given in chapter 13. When -oX is used to start a daemon, no + pid file is written unless -oP is also present to specify a pid filename. + +-pd + + This option applies when an embedded Perl interpreter is linked with Exim + (see chapter 12). It overrides the setting of the perl_at_start option, + forcing the starting of the interpreter to be delayed until it is needed. + +-ps + + This option applies when an embedded Perl interpreter is linked with Exim + (see chapter 12). It overrides the setting of the perl_at_start option, + forcing the starting of the interpreter to occur as soon as Exim is + started. + +-p<rval>:<sval> + + For compatibility with Sendmail, this option is equivalent to + + -oMr <rval> -oMs <sval> + + It sets the incoming protocol and host name (for trusted callers). The host + name and its colon can be omitted when only the protocol is to be set. Note + the Exim already has two private options, -pd and -ps, that refer to + embedded Perl. It is therefore impossible to set a protocol value of "d" or + "s" using this option (but that does not seem a real limitation). Repeated + use of this option is not supported. + +-q + + This option is normally restricted to admin users. However, there is a + configuration option called prod_requires_admin which can be set false to + relax this restriction (and also the same requirement for the -M, -R, and + -S options). + + If other commandline options do not specify an action, the -q option starts + one queue runner process. This scans the queue of waiting messages, and + runs a delivery process for each one in turn. It waits for each delivery + process to finish before starting the next one. A delivery process may not + actually do any deliveries if the retry times for the addresses have not + been reached. Use -qf (see below) if you want to override this. + + If the delivery process spawns other processes to deliver other messages + down passed SMTP connections, the queue runner waits for these to finish + before proceeding. + + When all the queued messages have been considered, the original queue + runner process terminates. In other words, a single pass is made over the + waiting mail, one message at a time. Use -q with a time (see below) if you + want this to be repeated periodically. + + Exim processes the waiting messages in an unpredictable order. It isn't + very random, but it is likely to be different each time, which is all that + matters. If one particular message screws up a remote MTA, other messages + to the same MTA have a chance of getting through if they get tried first. + + It is possible to cause the messages to be processed in lexical message id + order, which is essentially the order in which they arrived, by setting the + queue_run_in_order option, but this is not recommended for normal use. + +-q<qflags> + + The -q option may be followed by one or more flag letters that change its + behaviour. They are all optional, but if more than one is present, they + must appear in the correct order. Each flag is described in a separate item + below. + +-qq... + + An option starting with -qq requests a two-stage queue run. In the first + stage, the queue is scanned as if the queue_smtp_domains option matched + every domain. Addresses are routed, local deliveries happen, but no remote + transports are run. + + The hints database that remembers which messages are waiting for specific + hosts is updated, as if delivery to those hosts had been deferred. After + this is complete, a second, normal queue scan happens, with routing and + delivery taking place as normal. Messages that are routed to the same host + should mostly be delivered down a single SMTP connection because of the + hints that were set up during the first queue scan. This option may be + useful for hosts that are connected to the Internet intermittently. + +-q[q]i... + + If the i flag is present, the queue runner runs delivery processes only for + those messages that haven't previously been tried. (i stands for "initial + delivery".) This can be helpful if you are putting messages in the queue + using -odq and want a queue runner just to process the new messages. + +-q[q][i]f... + + If one f flag is present, a delivery attempt is forced for each non-frozen + message, whereas without f only those non-frozen addresses that have passed + their retry times are tried. + +-q[q][i]ff... + + If ff is present, a delivery attempt is forced for every message, whether + frozen or not. + +-q[q][i][f[f]]l + + The l (the letter "ell") flag specifies that only local deliveries are to + be done. If a message requires any remote deliveries, it remains in the + queue for later delivery. + +-q[q][i][f[f]][l][G<name>[/<time>]]] + + If the G flag and a name is present, the queue runner operates on the queue + with the given name rather than the default queue. The name should not + contain a / character. For a periodic queue run (see below) append to the + name a slash and a time value. + + If other commandline options specify an action, a -qG<name> option will + specify a queue to operate on. For example: + + exim -bp -qGquarantine + mailq -qGquarantine + exim -qGoffpeak -Rf @special.domain.example + +-q<qflags> <start id> <end id> + + When scanning the queue, Exim can be made to skip over messages whose ids + are lexically less than a given value by following the -q option with a + starting message id. For example: + + exim -q 0t5C6f-0000c8-00 + + Messages that arrived earlier than "0t5C6f-0000c8-00" are not inspected. If + a second message id is given, messages whose ids are lexically greater than + it are also skipped. If the same id is given twice, for example, + + exim -q 0t5C6f-0000c8-00 0t5C6f-0000c8-00 + + just one delivery process is started, for that message. This differs from + -M in that retry data is respected, and it also differs from -Mc in that it + counts as a delivery from a queue run. Note that the selection mechanism + does not affect the order in which the messages are scanned. There are also + other ways of selecting specific sets of messages for delivery in a queue + run - see -R and -S. + +-q<qflags><time> + + When a time value is present, the -q option causes Exim to run as a daemon, + starting a queue runner process at intervals specified by the given time + value (whose format is described in section 6.16). This form of the -q + option is commonly combined with the -bd option, in which case a single + daemon process handles both functions. A common way of starting up a + combined daemon at system boot time is to use a command such as + + /usr/exim/bin/exim -bd -q30m + + Such a daemon listens for incoming SMTP calls, and also starts a queue + runner process every 30 minutes. + + When a daemon is started by -q with a time value, but without -bd, no pid + file is written unless one is explicitly requested by the -oP option. + +-qR<rsflags> <string> + + This option is synonymous with -R. It is provided for Sendmail + compatibility. + +-qS<rsflags> <string> + + This option is synonymous with -S. + +-R<rsflags> <string> + + The <rsflags> may be empty, in which case the white space before the string + is optional, unless the string is f, ff, r, rf, or rff, which are the + possible values for <rsflags>. White space is required if <rsflags> is not + empty. + + This option is similar to -q with no time value, that is, it causes Exim to + perform a single queue run, except that, when scanning the messages on the + queue, Exim processes only those that have at least one undelivered + recipient address containing the given string, which is checked in a + case-independent way. If the <rsflags> start with r, <string> is + interpreted as a regular expression; otherwise it is a literal string. + + If you want to do periodic queue runs for messages with specific + recipients, you can combine -R with -q and a time value. For example: + + exim -q25m -R @special.domain.example + + This example does a queue run for messages with recipients in the given + domain every 25 minutes. Any additional flags that are specified with -q + are applied to each queue run. + + Once a message is selected for delivery by this mechanism, all its + addresses are processed. For the first selected message, Exim overrides any + retry information and forces a delivery attempt for each undelivered + address. This means that if delivery of any address in the first message is + successful, any existing retry information is deleted, and so delivery + attempts for that address in subsequently selected messages (which are + processed without forcing) will run. However, if delivery of any address + does not succeed, the retry information is updated, and in subsequently + selected messages, the failing address will be skipped. + + If the <rsflags> contain f or ff, the delivery forcing applies to all + selected messages, not just the first; frozen messages are included when ff + is present. + + The -R option makes it straightforward to initiate delivery of all messages + to a given domain after a host has been down for some time. When the SMTP + command ETRN is accepted by its ACL (see chapter 43), its default effect is + to run Exim with the -R option, but it can be configured to run an + arbitrary command instead. + +-r + + This is a documented (for Sendmail) obsolete alternative name for -f. + +-S<rsflags> <string> + + This option acts like -R except that it checks the string against each + message's sender instead of against the recipients. If -R is also set, both + conditions must be met for a message to be selected. If either of the + options has f or ff in its flags, the associated action is taken. + +-Tqt <times> + + This is an option that is exclusively for use by the Exim testing suite. It + is not recognized when Exim is run normally. It allows for the setting up + of explicit "queue times" so that various warning/retry features can be + tested. + +-t + + When Exim is receiving a locally-generated, non-SMTP message on its + standard input, the -t option causes the recipients of the message to be + obtained from the To:, Cc:, and Bcc: header lines in the message instead of + from the command arguments. The addresses are extracted before any + rewriting takes place and the Bcc: header line, if present, is then + removed. + + If the command has any arguments, they specify addresses to which the + message is not to be delivered. That is, the argument addresses are removed + from the recipients list obtained from the headers. This is compatible with + Smail 3 and in accordance with the documented behaviour of several versions + of Sendmail, as described in man pages on a number of operating systems + (e.g. Solaris 8, IRIX 6.5, HP-UX 11). However, some versions of Sendmail + add argument addresses to those obtained from the headers, and the O'Reilly + Sendmail book documents it that way. Exim can be made to add argument + addresses instead of subtracting them by setting the option + extract_addresses_remove_arguments false. + + If there are any Resent- header lines in the message, Exim extracts + recipients from all Resent-To:, Resent-Cc:, and Resent-Bcc: header lines + instead of from To:, Cc:, and Bcc:. This is for compatibility with Sendmail + and other MTAs. (Prior to release 4.20, Exim gave an error if -t was used + in conjunction with Resent- header lines.) + + RFC 2822 talks about different sets of Resent- header lines (for when a + message is resent several times). The RFC also specifies that they should + be added at the front of the message, and separated by Received: lines. It + is not at all clear how -t should operate in the present of multiple sets, + nor indeed exactly what constitutes a "set". In practice, it seems that + MUAs do not follow the RFC. The Resent- lines are often added at the end of + the header, and if a message is resent more than once, it is common for the + original set of Resent- headers to be renamed as X-Resent- when a new set + is added. This removes any possible ambiguity. + +-ti + + This option is exactly equivalent to -t -i. It is provided for + compatibility with Sendmail. + +-tls-on-connect + + This option is available when Exim is compiled with TLS support. It forces + all incoming SMTP connections to behave as if the incoming port is listed + in the tls_on_connect_ports option. See section 13.4 and chapter 42 for + further details. + +-U + + Sendmail uses this option for "initial message submission", and its + documentation states that in future releases, it may complain about + syntactically invalid messages rather than fixing them when this flag is + not set. Exim ignores this option. + +-v + + This option causes Exim to write information to the standard error stream, + describing what it is doing. In particular, it shows the log lines for + receiving and delivering a message, and if an SMTP connection is made, the + SMTP dialogue is shown. Some of the log lines shown may not actually be + written to the log if the setting of log_selector discards them. Any + relevant selectors are shown with each log line. If none are shown, the + logging is unconditional. + +-x + + AIX uses -x for a private purpose ("mail from a local mail program has + National Language Support extended characters in the body of the mail + item"). It sets -x when calling the MTA from its mail command. Exim ignores + this option. + +-X <logfile> + + This option is interpreted by Sendmail to cause debug information to be + sent to the named file. It is ignored by Exim. + +-z <log-line> + + This option writes its argument to Exim's logfile. Use is restricted to + administrators; the intent is for operational notes. Quotes should be used + to maintain a multi-word item as a single argument, under most shells. + + + +=============================================================================== +6. THE EXIM RUNTIME CONFIGURATION FILE + +Exim uses a single runtime configuration file that is read whenever an Exim +binary is executed. Note that in normal operation, this happens frequently, +because Exim is designed to operate in a distributed manner, without central +control. + +If a syntax error is detected while reading the configuration file, Exim writes +a message on the standard error, and exits with a non-zero return code. The +message is also written to the panic log. Note: Only simple syntax errors can +be detected at this time. The values of any expanded options are not checked +until the expansion happens, even when the expansion does not actually alter +the string. + +The name of the configuration file is compiled into the binary for security +reasons, and is specified by the CONFIGURE_FILE compilation option. In most +configurations, this specifies a single file. However, it is permitted to give +a colon-separated list of filenames, in which case Exim uses the first existing +file in the list. + +The runtime configuration file must be owned by root or by the user that is +specified at compile time by the CONFIGURE_OWNER option (if set). The +configuration file must not be world-writeable, or group-writeable unless its +group is the root group or the one specified at compile time by the +CONFIGURE_GROUP option. + +Warning: In a conventional configuration, where the Exim binary is setuid to +root, anybody who is able to edit the runtime configuration file has an easy +way to run commands as root. If you specify a user or group in the +CONFIGURE_OWNER or CONFIGURE_GROUP options, then that user and/or any users who +are members of that group will trivially be able to obtain root privileges. + +Up to Exim version 4.72, the runtime configuration file was also permitted to +be writeable by the Exim user and/or group. That has been changed in Exim 4.73 +since it offered a simple privilege escalation for any attacker who managed to +compromise the Exim user account. + +A default configuration file, which will work correctly in simple situations, +is provided in the file src/configure.default. If CONFIGURE_FILE defines just +one filename, the installation process copies the default configuration to a +new file of that name if it did not previously exist. If CONFIGURE_FILE is a +list, no default is automatically installed. Chapter 7 is a "walk-through" +discussion of the default configuration. + + +6.1 Using a different configuration file +---------------------------------------- + +A one-off alternate configuration can be specified by the -C command line +option, which may specify a single file or a list of files. However, when -C is +used, Exim gives up its root privilege, unless called by root (or unless the +argument for -C is identical to the built-in value from CONFIGURE_FILE), or is +listed in the TRUSTED_CONFIG_LIST file and the caller is the Exim user or the +user specified in the CONFIGURE_OWNER setting. -C is useful mainly for checking +the syntax of configuration files before installing them. No owner or group +checks are done on a configuration file specified by -C, if root privilege has +been dropped. + +Even the Exim user is not trusted to specify an arbitrary configuration file +with the -C option to be used with root privileges, unless that file is listed +in the TRUSTED_CONFIG_LIST file. This locks out the possibility of testing a +configuration using -C right through message reception and delivery, even if +the caller is root. The reception works, but by that time, Exim is running as +the Exim user, so when it re-execs to regain privilege for the delivery, the +use of -C causes privilege to be lost. However, root can test reception and +delivery using two separate commands (one to put a message in the queue, using +-odq, and another to do the delivery, using -M). + +If ALT_CONFIG_PREFIX is defined in Local/Makefile, it specifies a prefix string +with which any file named in a -C command line option must start. In addition, +the filename must not contain the sequence "/../". There is no default setting +for ALT_CONFIG_PREFIX; when it is unset, any filename can be used with -C. + +One-off changes to a configuration can be specified by the -D command line +option, which defines and overrides values for macros used inside the +configuration file. However, like -C, the use of this option by a +non-privileged user causes Exim to discard its root privilege. If +DISABLE_D_OPTION is defined in Local/Makefile, the use of -D is completely +disabled, and its use causes an immediate error exit. + +The WHITELIST_D_MACROS option in Local/Makefile permits the binary builder to +declare certain macro names trusted, such that root privilege will not +necessarily be discarded. WHITELIST_D_MACROS defines a colon-separated list of +macros which are considered safe and, if -D only supplies macros from this +list, and the values are acceptable, then Exim will not give up root privilege +if the caller is root, the Exim run-time user, or the CONFIGURE_OWNER, if set. +This is a transition mechanism and is expected to be removed in the future. +Acceptable values for the macros satisfy the regexp: "^[A-Za-z0-9_/.-]*$" + +Some sites may wish to use the same Exim binary on different machines that +share a file system, but to use different configuration files on each machine. +If CONFIGURE_FILE_USE_NODE is defined in Local/Makefile, Exim first looks for a +file whose name is the configuration filename followed by a dot and the +machine's node name, as obtained from the uname() function. If this file does +not exist, the standard name is tried. This processing occurs for each filename +in the list given by CONFIGURE_FILE or -C. + +In some esoteric situations different versions of Exim may be run under +different effective uids and the CONFIGURE_FILE_USE_EUID is defined to help +with this. See the comments in src/EDITME for details. + + +6.2 Configuration file format +----------------------------- + +Exim's configuration file is divided into a number of different parts. General +option settings must always appear at the start of the file. The other parts +are all optional, and may appear in any order. Each part other than the first +is introduced by the word "begin" followed by at least one literal space, and +the name of the part. The optional parts are: + + * ACL: Access control lists for controlling incoming SMTP mail (see chapter + 43). + + * authenticators: Configuration settings for the authenticator drivers. These + are concerned with the SMTP AUTH command (see chapter 33). + + * routers: Configuration settings for the router drivers. Routers process + addresses and determine how the message is to be delivered (see chapters 15 + -22). + + * transports: Configuration settings for the transport drivers. Transports + define mechanisms for copying messages to destinations (see chapters 24-30 + ). + + * retry: Retry rules, for use when a message cannot be delivered immediately. + If there is no retry section, or if it is empty (that is, no retry rules + are defined), Exim will not retry deliveries. In this situation, temporary + errors are treated the same as permanent errors. Retry rules are discussed + in chapter 32. + + * rewrite: Global address rewriting rules, for use when a message arrives and + when new addresses are generated during delivery. Rewriting is discussed in + chapter 31. + + * local_scan: Private options for the local_scan() function. If you want to + use this feature, you must set + + LOCAL_SCAN_HAS_OPTIONS=yes + + in Local/Makefile before building Exim. Details of the local_scan() + facility are given in chapter 45. + +Leading and trailing white space in configuration lines is always ignored. + +Blank lines in the file, and lines starting with a # character (ignoring +leading white space) are treated as comments and are ignored. Note: A # +character other than at the beginning of a line is not treated specially, and +does not introduce a comment. + +Any non-comment line can be continued by ending it with a backslash. Note that +the general rule for white space means that trailing white space after the +backslash and leading white space at the start of continuation lines is +ignored. Comment lines beginning with # (but not empty lines) may appear in the +middle of a sequence of continuation lines. + +A convenient way to create a configuration file is to start from the default, +which is supplied in src/configure.default, and add, delete, or change settings +as required. + +The ACLs, retry rules, and rewriting rules have their own syntax which is +described in chapters 43, 32, and 31, respectively. The other parts of the +configuration file have some syntactic items in common, and these are described +below, from section 6.11 onwards. Before that, the inclusion, macro, and +conditional facilities are described. + + +6.3 File inclusions in the configuration file +--------------------------------------------- + +You can include other files inside Exim's runtime configuration file by using +this syntax: + +.include <filename> +.include_if_exists <filename> + +on a line by itself. Double quotes round the filename are optional. If you use +the first form, a configuration error occurs if the file does not exist; the +second form does nothing for non-existent files. The first form allows a +relative name. It is resolved relative to the directory of the including file. +For the second form an absolute filename is required. + +Includes may be nested to any depth, but remember that Exim reads its +configuration file often, so it is a good idea to keep them to a minimum. If +you change the contents of an included file, you must HUP the daemon, because +an included file is read only when the configuration itself is read. + +The processing of inclusions happens early, at a physical line level, so, like +comment lines, an inclusion can be used in the middle of an option setting, for +example: + +hosts_lookup = a.b.c \ + .include /some/file + +Include processing happens after macro processing (see below). Its effect is to +process the lines of the included file as if they occurred inline where the +inclusion appears. + + +6.4 Macros in the configuration file +------------------------------------ + +If a line in the main part of the configuration (that is, before the first +"begin" line) begins with an upper case letter, it is taken as a macro +definition, and must be of the form + +<name> = <rest of line> + +The name must consist of letters, digits, and underscores, and need not all be +in upper case, though that is recommended. The rest of the line, including any +continuations, is the replacement text, and has leading and trailing white +space removed. Quotes are not removed. The replacement text can never end with +a backslash character, but this doesn't seem to be a serious limitation. + +Macros may also be defined between router, transport, authenticator, or ACL +definitions. They may not, however, be defined within an individual driver or +ACL, or in the local_scan, retry, or rewrite sections of the configuration. + + +6.5 Macro substitution +---------------------- + +Once a macro is defined, all subsequent lines in the file (and any included +files) are scanned for the macro name; if there are several macros, the line is +scanned for each, in turn, in the order in which the macros are defined. The +replacement text is not re-scanned for the current macro, though it is scanned +for subsequently defined macros. For this reason, a macro name may not contain +the name of a previously defined macro as a substring. You could, for example, +define + +ABCD_XYZ = <something> +ABCD = <something else> + +but putting the definitions in the opposite order would provoke a configuration +error. Macro expansion is applied to individual physical lines from the file, +before checking for line continuation or file inclusion (see above). If a line +consists solely of a macro name, and the expansion of the macro is empty, the +line is ignored. A macro at the start of a line may turn the line into a +comment line or a ".include" line. + + +6.6 Redefining macros +--------------------- + +Once defined, the value of a macro can be redefined later in the configuration +(or in an included file). Redefinition is specified by using == instead of =. +For example: + +MAC = initial value +... +MAC == updated value + +Redefinition does not alter the order in which the macros are applied to the +subsequent lines of the configuration file. It is still the same order in which +the macros were originally defined. All that changes is the macro's value. +Redefinition makes it possible to accumulate values. For example: + +MAC = initial value +... +MAC == MAC and something added + +This can be helpful in situations where the configuration file is built from a +number of other files. + + +6.7 Overriding macro values +--------------------------- + +The values set for macros in the configuration file can be overridden by the -D +command line option, but Exim gives up its root privilege when -D is used, +unless called by root or the Exim user. A definition on the command line using +the -D option causes all definitions and redefinitions within the file to be +ignored. + + +6.8 Example of macro usage +-------------------------- + +As an example of macro usage, consider a configuration where aliases are looked +up in a MySQL database. It helps to keep the file less cluttered if long +strings such as SQL statements are defined separately as macros, for example: + +ALIAS_QUERY = select mailbox from user where \ + login='${quote_mysql:$local_part}'; + +This can then be used in a redirect router setting like this: + +data = ${lookup mysql{ALIAS_QUERY}} + +In earlier versions of Exim macros were sometimes used for domain, host, or +address lists. In Exim 4 these are handled better by named lists - see section +10.5. + + +6.9 Builtin macros +------------------ + +Exim defines some macros depending on facilities available, which may differ +due to build-time definitions and from one release to another. All of these +macros start with an underscore. They can be used to conditionally include +parts of a configuration (see below). + +The following classes of macros are defined: + + _HAVE_* build-time defines + _DRIVER_ROUTER_* router drivers + _DRIVER_TRANSPORT_* transport drivers + _DRIVER_AUTHENTICATOR_* authenticator drivers + _LOG_* log_selector values + _OPT_MAIN_* main config options + _OPT_ROUTERS_* generic router options + _OPT_TRANSPORTS_* generic transport options + _OPT_AUTHENTICATORS_* generic authenticator options + _OPT_ROUTER_*_* private router options + _OPT_TRANSPORT_*_* private transport options + _OPT_AUTHENTICATOR_*_* private authenticator options + +Use an "exim -bP macros" command to get the list of macros. + + +6.10 Conditional skips in the configuration file +------------------------------------------------ + +You can use the directives ".ifdef", ".ifndef", ".elifdef", ".elifndef", +".else", and ".endif" to dynamically include or exclude portions of the +configuration file. The processing happens whenever the file is read (that is, +when an Exim binary starts to run). + +The implementation is very simple. Instances of the first four directives must +be followed by text that includes the names of one or macros. The condition +that is tested is whether or not any macro substitution has taken place in the +line. Thus: + +.ifdef AAA +message_size_limit = 50M +.else +message_size_limit = 100M +.endif + +sets a message size limit of 50M if the macro "AAA" is defined (or "A" or +"AA"), and 100M otherwise. If there is more than one macro named on the line, +the condition is true if any of them are defined. That is, it is an "or" +condition. To obtain an "and" condition, you need to use nested ".ifdef"s. + +Although you can use a macro expansion to generate one of these directives, it +is not very useful, because the condition "there was a macro substitution in +this line" will always be true. + +Text following ".else" and ".endif" is ignored, and can be used as comment to +clarify complicated nestings. + + +6.11 Common option syntax +------------------------- + +For the main set of options, driver options, and local_scan() options, each +setting is on a line by itself, and starts with a name consisting of lower-case +letters and underscores. Many options require a data value, and in these cases +the name must be followed by an equals sign (with optional white space) and +then the value. For example: + +qualify_domain = mydomain.example.com + +Some option settings may contain sensitive data, for example, passwords for +accessing databases. To stop non-admin users from using the -bP command line +option to read these values, you can precede the option settings with the word +"hide". For example: + +hide mysql_servers = localhost/users/admin/secret-password + +For non-admin users, such options are displayed like this: + +mysql_servers = <value not displayable> + +If "hide" is used on a driver option, it hides the value of that option on all +instances of the same driver. + +The following sections describe the syntax used for the different data types +that are found in option settings. + + +6.12 Boolean options +-------------------- + +Options whose type is given as boolean are on/off switches. There are two +different ways of specifying such options: with and without a data value. If +the option name is specified on its own without data, the switch is turned on; +if it is preceded by "no_" or "not_" the switch is turned off. However, boolean +options may be followed by an equals sign and one of the words "true", "false", +"yes", or "no", as an alternative syntax. For example, the following two +settings have exactly the same effect: + +queue_only +queue_only = true + +The following two lines also have the same (opposite) effect: + +no_queue_only +queue_only = false + +You can use whichever syntax you prefer. + + +6.13 Integer values +------------------- + +If an option's type is given as "integer", the value can be given in decimal, +hexadecimal, or octal. If it starts with a digit greater than zero, a decimal +number is assumed. Otherwise, it is treated as an octal number unless it starts +with the characters "0x", in which case the remainder is interpreted as a +hexadecimal number. + +If an integer value is followed by the letter K, it is multiplied by 1024; if +it is followed by the letter M, it is multiplied by 1024x1024; if by the letter +G, 1024x1024x1024. When the values of integer option settings are output, +values which are an exact multiple of 1024 or 1024x1024 are sometimes, but not +always, printed using the letters K and M. The printing style is independent of +the actual input format that was used. + + +6.14 Octal integer values +------------------------- + +If an option's type is given as "octal integer", its value is always +interpreted as an octal number, whether or not it starts with the digit zero. +Such options are always output in octal. + + +6.15 Fixed point numbers +------------------------ + +If an option's type is given as "fixed-point", its value must be a decimal +integer, optionally followed by a decimal point and up to three further digits. + + +6.16 Time intervals +------------------- + +A time interval is specified as a sequence of numbers, each followed by one of +the following letters, with no intervening white space: + + s seconds + m minutes + h hours + d days + w weeks + +For example, "3h50m" specifies 3 hours and 50 minutes. The values of time +intervals are output in the same format. Exim does not restrict the values; it +is perfectly acceptable, for example, to specify "90m" instead of "1h30m". + + +6.17 String values +------------------ + +If an option's type is specified as "string", the value can be specified with +or without double-quotes. If it does not start with a double-quote, the value +consists of the remainder of the line plus any continuation lines, starting at +the first character after any leading white space, with trailing white space +removed, and with no interpretation of the characters in the string. Because +Exim removes comment lines (those beginning with #) at an early stage, they can +appear in the middle of a multi-line string. The following two settings are +therefore equivalent: + +trusted_users = uucp:mail +trusted_users = uucp:\ + # This comment line is ignored + mail + +If a string does start with a double-quote, it must end with a closing +double-quote, and any backslash characters other than those used for line +continuation are interpreted as escape characters, as follows: + + "\\" single backslash + "\n" newline + "\r" carriage return + "\t" tab + "\"<octal digits> up to 3 octal digits specify one character + "\x"<hex digits> up to 2 hexadecimal digits specify one character + +If a backslash is followed by some other character, including a double-quote +character, that character replaces the pair. + +Quoting is necessary only if you want to make use of the backslash escapes to +insert special characters, or if you need to specify a value with leading or +trailing spaces. These cases are rare, so quoting is almost never needed in +current versions of Exim. In versions of Exim before 3.14, quoting was required +in order to continue lines, so you may come across older configuration files +and examples that apparently quote unnecessarily. + + +6.18 Expanded strings +--------------------- + +Some strings in the configuration file are subjected to string expansion, by +which means various parts of the string may be changed according to the +circumstances (see chapter 11). The input syntax for such strings is as just +described; in particular, the handling of backslashes in quoted strings is done +as part of the input process, before expansion takes place. However, backslash +is also an escape character for the expander, so any backslashes that are +required for that reason must be doubled if they are within a quoted +configuration string. + + +6.19 User and group names +------------------------- + +User and group names are specified as strings, using the syntax described +above, but the strings are interpreted specially. A user or group name must +either consist entirely of digits, or be a name that can be looked up using the +getpwnam() or getgrnam() function, as appropriate. + + +6.20 List construction +---------------------- + +The data for some configuration options is a list of items, with colon as the +default separator. Many of these options are shown with type "string list" in +the descriptions later in this document. Others are listed as "domain list", +"host list", "address list", or "local part list". Syntactically, they are all +the same; however, those other than "string list" are subject to particular +kinds of interpretation, as described in chapter 10. + +In all these cases, the entire list is treated as a single string as far as the +input syntax is concerned. The trusted_users setting in section 6.17 above is +an example. If a colon is actually needed in an item in a list, it must be +entered as two colons. Leading and trailing white space on each item in a list +is ignored. This makes it possible to include items that start with a colon, +and in particular, certain forms of IPv6 address. For example, the list + +local_interfaces = 127.0.0.1 : ::::1 + +contains two IP addresses, the IPv4 address 127.0.0.1 and the IPv6 address ::1. + +Note: Although leading and trailing white space is ignored in individual list +items, it is not ignored when parsing the list. The space after the first colon +in the example above is necessary. If it were not there, the list would be +interpreted as the two items 127.0.0.1:: and 1. + + +6.21 Changing list separators +----------------------------- + +Doubling colons in IPv6 addresses is an unwelcome chore, so a mechanism was +introduced to allow the separator character to be changed. If a list begins +with a left angle bracket, followed by any punctuation character, that +character is used instead of colon as the list separator. For example, the list +above can be rewritten to use a semicolon separator like this: + +local_interfaces = <; 127.0.0.1 ; ::1 + +This facility applies to all lists, with the exception of the list in +log_file_path. It is recommended that the use of non-colon separators be +confined to circumstances where they really are needed. + +It is also possible to use newline and other control characters (those with +code values less than 32, plus DEL) as separators in lists. Such separators +must be provided literally at the time the list is processed. For options that +are string-expanded, you can write the separator using a normal escape +sequence. This will be processed by the expander before the string is +interpreted as a list. For example, if a newline-separated list of domains is +generated by a lookup, you can process it directly by a line such as this: + +domains = <\n ${lookup mysql{.....}} + +This avoids having to change the list separator in such data. You are unlikely +to want to use a control character as a separator in an option that is not +expanded, because the value is literal text. However, it can be done by giving +the value in quotes. For example: + +local_interfaces = "<\n 127.0.0.1 \n ::1" + +Unlike printing character separators, which can be included in list items by +doubling, it is not possible to include a control character as data when it is +set as the separator. Two such characters in succession are interpreted as +enclosing an empty list item. + + +6.22 Empty items in lists +------------------------- + +An empty item at the end of a list is always ignored. In other words, trailing +separator characters are ignored. Thus, the list in + +senders = user@domain : + +contains only a single item. If you want to include an empty string as one item +in a list, it must not be the last item. For example, this list contains three +items, the second of which is empty: + +senders = user1@domain : : user2@domain + +Note: There must be white space between the two colons, as otherwise they are +interpreted as representing a single colon data character (and the list would +then contain just one item). If you want to specify a list that contains just +one, empty item, you can do it as in this example: + +senders = : + +In this case, the first item is empty, and the second is discarded because it +is at the end of the list. + + +6.23 Format of driver configurations +------------------------------------ + +There are separate parts in the configuration for defining routers, transports, +and authenticators. In each part, you are defining a number of driver +instances, each with its own set of options. Each driver instance is defined by +a sequence of lines like this: + +<instance name>: + <option> + ... + <option> + +In the following example, the instance name is localuser, and it is followed by +three options settings: + +localuser: + driver = accept + check_local_user + transport = local_delivery + +For each driver instance, you specify which Exim code module it uses - by the +setting of the driver option - and (optionally) some configuration settings. +For example, in the case of transports, if you want a transport to deliver with +SMTP you would use the smtp driver; if you want to deliver to a local file you +would use the appendfile driver. Each of the drivers is described in detail in +its own separate chapter later in this manual. + +You can have several routers, transports, or authenticators that are based on +the same underlying driver (each must have a different instance name). + +The order in which routers are defined is important, because addresses are +passed to individual routers one by one, in order. The order in which +transports are defined does not matter at all. The order in which +authenticators are defined is used only when Exim, as a client, is searching +them to find one that matches an authentication mechanism offered by the +server. + +Within a driver instance definition, there are two kinds of option: generic and +private. The generic options are those that apply to all drivers of the same +type (that is, all routers, all transports or all authenticators). The driver +option is a generic option that must appear in every definition. The private +options are special for each driver, and none need appear, because they all +have default values. + +The options may appear in any order, except that the driver option must precede +any private options, since these depend on the particular driver. For this +reason, it is recommended that driver always be the first option. + +Driver instance names, which are used for reference in log entries and +elsewhere, can be any sequence of letters, digits, and underscores (starting +with a letter) and must be unique among drivers of the same type. A router and +a transport (for example) can each have the same name, but no two router +instances can have the same name. The name of a driver instance should not be +confused with the name of the underlying driver module. For example, the +configuration lines: + +remote_smtp: + driver = smtp + +create an instance of the smtp transport driver whose name is remote_smtp. The +same driver code can be used more than once, with different instance names and +different option settings each time. A second instance of the smtp transport, +with different options, might be defined thus: + +special_smtp: + driver = smtp + port = 1234 + command_timeout = 10s + +The names remote_smtp and special_smtp would be used to reference these +transport instances from routers, and these names would appear in log lines. + +Comment lines may be present in the middle of driver specifications. The full +list of option settings for any particular driver instance, including all the +defaulted values, can be extracted by making use of the -bP command line +option. + + + +=============================================================================== +7. THE DEFAULT CONFIGURATION FILE + +The default configuration file supplied with Exim as src/configure.default is +sufficient for a host with simple mail requirements. As an introduction to the +way Exim is configured, this chapter "walks through" the default configuration, +giving brief explanations of the settings. Detailed descriptions of the options +are given in subsequent chapters. The default configuration file itself +contains extensive comments about ways you might want to modify the initial +settings. However, note that there are many options that are not mentioned at +all in the default configuration. + + +7.1 Macros +---------- + +All macros should be defined before any options. + +One macro is specified, but commented out, in the default configuration: + +# ROUTER_SMARTHOST=MAIL.HOSTNAME.FOR.CENTRAL.SERVER.EXAMPLE + +If all off-site mail is expected to be delivered to a "smarthost", then set the +hostname here and uncomment the macro. This will affect which router is used +later on. If this is left commented out, then Exim will perform direct-to-MX +deliveries using a dnslookup router. + +In addition to macros defined here, Exim includes a number of built-in macros +to enable configuration to be guarded by a binary built with support for a +given feature. See section 6.9 for more details. + + +7.2 Main configuration settings +------------------------------- + +The main (global) configuration option settings section must always come first +in the file, after the macros. The first thing you'll see in the file, after +some initial comments, is the line + +# primary_hostname = + +This is a commented-out setting of the primary_hostname option. Exim needs to +know the official, fully qualified name of your host, and this is where you can +specify it. However, in most cases you do not need to set this option. When it +is unset, Exim uses the uname() system function to obtain the host name. + +The first three non-comment configuration lines are as follows: + +domainlist local_domains = @ +domainlist relay_to_domains = +hostlist relay_from_hosts = 127.0.0.1 + +These are not, in fact, option settings. They are definitions of two named +domain lists and one named host list. Exim allows you to give names to lists of +domains, hosts, and email addresses, in order to make it easier to manage the +configuration file (see section 10.5). + +The first line defines a domain list called local_domains; this is used later +in the configuration to identify domains that are to be delivered on the local +host. + +There is just one item in this list, the string "@". This is a special form of +entry which means "the name of the local host". Thus, if the local host is +called a.host.example, mail to any.user@a.host.example is expected to be +delivered locally. Because the local host's name is referenced indirectly, the +same configuration file can be used on different hosts. + +The second line defines a domain list called relay_to_domains, but the list +itself is empty. Later in the configuration we will come to the part that +controls mail relaying through the local host; it allows relaying to any +domains in this list. By default, therefore, no relaying on the basis of a mail +domain is permitted. + +The third line defines a host list called relay_from_hosts. This list is used +later in the configuration to permit relaying from any host or IP address that +matches the list. The default contains just the IP address of the IPv4 loopback +interface, which means that processes on the local host are able to submit mail +for relaying by sending it over TCP/IP to that interface. No other hosts are +permitted to submit messages for relaying. + +Just to be sure there's no misunderstanding: at this point in the configuration +we aren't actually setting up any controls. We are just defining some domains +and hosts that will be used in the controls that are specified later. + +The next two configuration lines are genuine option settings: + +acl_smtp_rcpt = acl_check_rcpt +acl_smtp_data = acl_check_data + +These options specify Access Control Lists (ACLs) that are to be used during an +incoming SMTP session for every recipient of a message (every RCPT command), +and after the contents of the message have been received, respectively. The +names of the lists are acl_check_rcpt and acl_check_data, and we will come to +their definitions below, in the ACL section of the configuration. The RCPT ACL +controls which recipients are accepted for an incoming message - if a +configuration does not provide an ACL to check recipients, no SMTP mail can be +accepted. The DATA ACL allows the contents of a message to be checked. + +Two commented-out option settings are next: + +# av_scanner = clamd:/tmp/clamd +# spamd_address = 127.0.0.1 783 + +These are example settings that can be used when Exim is compiled with the +content-scanning extension. The first specifies the interface to the virus +scanner, and the second specifies the interface to SpamAssassin. Further +details are given in chapter 44. + +Three more commented-out option settings follow: + +# tls_advertise_hosts = * +# tls_certificate = /etc/ssl/exim.crt +# tls_privatekey = /etc/ssl/exim.pem + +These are example settings that can be used when Exim is compiled with support +for TLS (aka SSL) as described in section 4.7. The first one specifies the list +of clients that are allowed to use TLS when connecting to this server; in this +case, the wildcard means all clients. The other options specify where Exim +should find its TLS certificate and private key, which together prove the +server's identity to any clients that connect. More details are given in +chapter 42. + +Another two commented-out option settings follow: + +# daemon_smtp_ports = 25 : 465 : 587 +# tls_on_connect_ports = 465 + +These options provide better support for roaming users who wish to use this +server for message submission. They are not much use unless you have turned on +TLS (as described in the previous paragraph) and authentication (about which +more in section 7.8). Mail submission from mail clients (MUAs) should be +separate from inbound mail to your domain (MX delivery) for various good +reasons (eg, ability to impose much saner TLS protocol and ciphersuite +requirements without unintended consequences). RFC 6409 (previously 4409) +specifies use of port 587 for SMTP Submission, which uses STARTTLS, so this is +the "submission" port. RFC 8314 specifies use of port 465 as the "submissions" +protocol, which should be used in preference to 587. You should also consider +deploying SRV records to help clients find these ports. Older names for +"submissions" are "smtps" and "ssmtp". + +Two more commented-out options settings follow: + +# qualify_domain = +# qualify_recipient = + +The first of these specifies a domain that Exim uses when it constructs a +complete email address from a local login name. This is often needed when Exim +receives a message from a local process. If you do not set qualify_domain, the +value of primary_hostname is used. If you set both of these options, you can +have different qualification domains for sender and recipient addresses. If you +set only the first one, its value is used in both cases. + +The following line must be uncommented if you want Exim to recognize addresses +of the form user@[10.11.12.13] that is, with a "domain literal" (an IP address +within square brackets) instead of a named domain. + +# allow_domain_literals + +The RFCs still require this form, but many people think that in the modern +Internet it makes little sense to permit mail to be sent to specific hosts by +quoting their IP addresses. This ancient format has been used by people who try +to abuse hosts by using them for unwanted relaying. However, some people +believe there are circumstances (for example, messages addressed to postmaster) +where domain literals are still useful. + +The next configuration line is a kind of trigger guard: + +never_users = root + +It specifies that no delivery must ever be run as the root user. The normal +convention is to set up root as an alias for the system administrator. This +setting is a guard against slips in the configuration. The list of users +specified by never_users is not, however, the complete list; the build-time +configuration in Local/Makefile has an option called FIXED_NEVER_USERS +specifying a list that cannot be overridden. The contents of never_users are +added to this list. By default FIXED_NEVER_USERS also specifies root. + +When a remote host connects to Exim in order to send mail, the only information +Exim has about the host's identity is its IP address. The next configuration +line, + +host_lookup = * + +specifies that Exim should do a reverse DNS lookup on all incoming connections, +in order to get a host name. This improves the quality of the logging +information, but if you feel it is too expensive, you can remove it entirely, +or restrict the lookup to hosts on "nearby" networks. Note that it is not +always possible to find a host name from an IP address, because not all DNS +reverse zones are maintained, and sometimes DNS servers are unreachable. + +The next two lines are concerned with ident callbacks, as defined by RFC 1413 +(hence their names): + +rfc1413_hosts = * +rfc1413_query_timeout = 0s + +These settings cause Exim to avoid ident callbacks for all incoming SMTP calls. +Few hosts offer RFC1413 service these days; calls have to be terminated by a +timeout and this needlessly delays the startup of an incoming SMTP connection. +If you have hosts for which you trust RFC1413 and need this information, you +can change this. + +This line enables an efficiency SMTP option. It is negotiated by clients and +not expected to cause problems but can be disabled if needed. + +prdr_enable = true + +When Exim receives messages over SMTP connections, it expects all addresses to +be fully qualified with a domain, as required by the SMTP definition. However, +if you are running a server to which simple clients submit messages, you may +find that they send unqualified addresses. The two commented-out options: + +# sender_unqualified_hosts = +# recipient_unqualified_hosts = + +show how you can specify hosts that are permitted to send unqualified sender +and recipient addresses, respectively. + +The log_selector option is used to increase the detail of logging over the +default: + +log_selector = +smtp_protocol_error +smtp_syntax_error \ + +tls_certificate_verified + +The percent_hack_domains option is also commented out: + +# percent_hack_domains = + +It provides a list of domains for which the "percent hack" is to operate. This +is an almost obsolete form of explicit email routing. If you do not know +anything about it, you can safely ignore this topic. + +The next two settings in the main part of the default configuration are +concerned with messages that have been "frozen" on Exim's queue. When a message +is frozen, Exim no longer continues to try to deliver it. Freezing occurs when +a bounce message encounters a permanent failure because the sender address of +the original message that caused the bounce is invalid, so the bounce cannot be +delivered. This is probably the most common case, but there are also other +conditions that cause freezing, and frozen messages are not always bounce +messages. + +ignore_bounce_errors_after = 2d +timeout_frozen_after = 7d + +The first of these options specifies that failing bounce messages are to be +discarded after 2 days in the queue. The second specifies that any frozen +message (whether a bounce message or not) is to be timed out (and discarded) +after a week. In this configuration, the first setting ensures that no failing +bounce message ever lasts a week. + +Exim queues it's messages in a spool directory. If you expect to have large +queues, you may consider using this option. It splits the spool directory into +subdirectories to avoid file system degradation from many files in a single +directory, resulting in better performance. Manual manipulation of queued +messages becomes more complex (though fortunately not often needed). + +# split_spool_directory = true + +In an ideal world everybody follows the standards. For non-ASCII messages RFC +2047 is a standard, allowing a maximum line length of 76 characters. Exim +adheres that standard and won't process messages which violate this standard. +(Even ${rfc2047:...} expansions will fail.) In particular, the Exim maintainers +have had multiple reports of problems from Russian administrators of issues +until they disable this check, because of some popular, yet buggy, mail +composition software. + +# check_rfc2047_length = false + +If you need to be strictly RFC compliant you may wish to disable the 8BITMIME +advertisement. Use this, if you exchange mails with systems that are not 8-bit +clean. + +# accept_8bitmime = false + +Libraries you use may depend on specific environment settings. This imposes a +security risk (e.g. PATH). There are two lists: keep_environment for the +variables to import as they are, and add_environment for variables we want to +set to a fixed value. Note that TZ is handled separately, by the $%timezone%$ +runtime option and by the TIMEZONE_DEFAULT buildtime option. + +# keep_environment = ^LDAP +# add_environment = PATH=/usr/bin::/bin + + +7.3 ACL configuration +--------------------- + +In the default configuration, the ACL section follows the main configuration. +It starts with the line + +begin acl + +and it contains the definitions of two ACLs, called acl_check_rcpt and +acl_check_data, that were referenced in the settings of acl_smtp_rcpt and +acl_smtp_data above. + +The first ACL is used for every RCPT command in an incoming SMTP message. Each +RCPT command specifies one of the message's recipients. The ACL statements are +considered in order, until the recipient address is either accepted or +rejected. The RCPT command is then accepted or rejected, according to the +result of the ACL processing. + +acl_check_rcpt: + +This line, consisting of a name terminated by a colon, marks the start of the +ACL, and names it. + +accept hosts = : + +This ACL statement accepts the recipient if the sending host matches the list. +But what does that strange list mean? It doesn't actually contain any host +names or IP addresses. The presence of the colon puts an empty item in the +list; Exim matches this only if the incoming message did not come from a remote +host, because in that case, the remote hostname is empty. The colon is +important. Without it, the list itself is empty, and can never match anything. + +What this statement is doing is to accept unconditionally all recipients in +messages that are submitted by SMTP from local processes using the standard +input and output (that is, not using TCP/IP). A number of MUAs operate in this +manner. + +deny message = Restricted characters in address + domains = +local_domains + local_parts = ^[.] : ^.*[@%!/|] + +deny message = Restricted characters in address + domains = !+local_domains + local_parts = ^[./|] : ^.*[@%!] : ^.*/\\.\\./ + +These statements are concerned with local parts that contain any of the +characters "@", "%", "!", "/", "|", or dots in unusual places. Although these +characters are entirely legal in local parts (in the case of "@" and leading +dots, only if correctly quoted), they do not commonly occur in Internet mail +addresses. + +The first three have in the past been associated with explicitly routed +addresses (percent is still sometimes used - see the percent_hack_domains +option). Addresses containing these characters are regularly tried by spammers +in an attempt to bypass relaying restrictions, and also by open relay testing +programs. Unless you really need them it is safest to reject these characters +at this early stage. This configuration is heavy-handed in rejecting these +characters for all messages it accepts from remote hosts. This is a deliberate +policy of being as safe as possible. + +The first rule above is stricter, and is applied to messages that are addressed +to one of the local domains handled by this host. This is implemented by the +first condition, which restricts it to domains that are listed in the +local_domains domain list. The "+" character is used to indicate a reference to +a named list. In this configuration, there is just one domain in local_domains, +but in general there may be many. + +The second condition on the first statement uses two regular expressions to +block local parts that begin with a dot or contain "@", "%", "!", "/", or "|". +If you have local accounts that include these characters, you will have to +modify this rule. + +Empty components (two dots in a row) are not valid in RFC 2822, but Exim allows +them because they have been encountered in practice. (Consider the common +convention of local parts constructed as " +first-initial.second-initial.family-name" when applied to someone like the +author of Exim, who has no second initial.) However, a local part starting with +a dot or containing "/../" can cause trouble if it is used as part of a +filename (for example, for a mailing list). This is also true for local parts +that contain slashes. A pipe symbol can also be troublesome if the local part +is incorporated unthinkingly into a shell command line. + +The second rule above applies to all other domains, and is less strict. This +allows your own users to send outgoing messages to sites that use slashes and +vertical bars in their local parts. It blocks local parts that begin with a +dot, slash, or vertical bar, but allows these characters within the local part. +However, the sequence "/../" is barred. The use of "@", "%", and "!" is +blocked, as before. The motivation here is to prevent your users (or your +users' viruses) from mounting certain kinds of attack on remote sites. + +accept local_parts = postmaster + domains = +local_domains + +This statement, which has two conditions, accepts an incoming address if the +local part is postmaster and the domain is one of those listed in the +local_domains domain list. The "+" character is used to indicate a reference to +a named list. In this configuration, there is just one domain in local_domains, +but in general there may be many. + +The presence of this statement means that mail to postmaster is never blocked +by any of the subsequent tests. This can be helpful while sorting out problems +in cases where the subsequent tests are incorrectly denying access. + +require verify = sender + +This statement requires the sender address to be verified before any subsequent +ACL statement can be used. If verification fails, the incoming recipient +address is refused. Verification consists of trying to route the address, to +see if a bounce message could be delivered to it. In the case of remote +addresses, basic verification checks only the domain, but callouts can be used +for more verification if required. Section 43.44 discusses the details of +address verification. + +accept hosts = +relay_from_hosts + control = submission + +This statement accepts the address if the message is coming from one of the +hosts that are defined as being allowed to relay through this host. Recipient +verification is omitted here, because in many cases the clients are dumb MUAs +that do not cope well with SMTP error responses. For the same reason, the +second line specifies "submission mode" for messages that are accepted. This is +described in detail in section 47.1; it causes Exim to fix messages that are +deficient in some way, for example, because they lack a Date: header line. If +you are actually relaying out from MTAs, you should probably add recipient +verification here, and disable submission mode. + +accept authenticated = * + control = submission + +This statement accepts the address if the client host has authenticated itself. +Submission mode is again specified, on the grounds that such messages are most +likely to come from MUAs. The default configuration does not define any +authenticators, though it does include some nearly complete commented-out +examples described in 7.8. This means that no client can in fact authenticate +until you complete the authenticator definitions. + +require message = relay not permitted + domains = +local_domains : +relay_to_domains + +This statement rejects the address if its domain is neither a local domain nor +one of the domains for which this host is a relay. + +require verify = recipient + +This statement requires the recipient address to be verified; if verification +fails, the address is rejected. + +# deny message = rejected because $sender_host_address \ +# is in a black list at $dnslist_domain\n\ +# $dnslist_text +# dnslists = black.list.example +# +# warn dnslists = black.list.example +# add_header = X-Warning: $sender_host_address is in \ +# a black list at $dnslist_domain +# log_message = found in $dnslist_domain + +These commented-out lines are examples of how you could configure Exim to check +sending hosts against a DNS black list. The first statement rejects messages +from blacklisted hosts, whereas the second just inserts a warning header line. + +# require verify = csa + +This commented-out line is an example of how you could turn on client SMTP +authorization (CSA) checking. Such checks do DNS lookups for special SRV +records. + +accept + +The final statement in the first ACL unconditionally accepts any recipient +address that has successfully passed all the previous tests. + +acl_check_data: + +This line marks the start of the second ACL, and names it. Most of the contents +of this ACL are commented out: + +# deny malware = * +# message = This message contains a virus \ +# ($malware_name). + +These lines are examples of how to arrange for messages to be scanned for +viruses when Exim has been compiled with the content-scanning extension, and a +suitable virus scanner is installed. If the message is found to contain a +virus, it is rejected with the given custom error message. + +# warn spam = nobody +# message = X-Spam_score: $spam_score\n\ +# X-Spam_score_int: $spam_score_int\n\ +# X-Spam_bar: $spam_bar\n\ +# X-Spam_report: $spam_report + +These lines are an example of how to arrange for messages to be scanned by +SpamAssassin when Exim has been compiled with the content-scanning extension, +and SpamAssassin has been installed. The SpamAssassin check is run with +"nobody" as its user parameter, and the results are added to the message as a +series of extra header line. In this case, the message is not rejected, +whatever the spam score. + +accept + +This final line in the DATA ACL accepts the message unconditionally. + + +7.4 Router configuration +------------------------ + +The router configuration comes next in the default configuration, introduced by +the line + +begin routers + +Routers are the modules in Exim that make decisions about where to send +messages. An address is passed to each router, in turn, until it is either +accepted, or failed. This means that the order in which you define the routers +matters. Each router is fully described in its own chapter later in this +manual. Here we give only brief overviews. + +# domain_literal: +# driver = ipliteral +# domains = !+local_domains +# transport = remote_smtp + +This router is commented out because the majority of sites do not want to +support domain literal addresses (those of the form user@[10.9.8.7]). If you +uncomment this router, you also need to uncomment the setting of +allow_domain_literals in the main part of the configuration. + +Which router is used next depends upon whether or not the ROUTER_SMARTHOST +macro has been defined, per + +.ifdef ROUTER_SMARTHOST +smarthost: +#... +.else +dnslookup: +#... +.endif + +If ROUTER_SMARTHOST has been defined, either at the top of the file or on the +command-line, then we route all non-local mail to that smarthost; otherwise, +we'll perform DNS lookups for direct-to-MX lookup. Any mail which is to a local +domain will skip these routers because of the domains option. + +smarthost: + driver = manualroute + domains = ! +local_domains + transport = smarthost_smtp + route_data = ROUTER_SMARTHOST + ignore_target_hosts = <; 0.0.0.0 ; 127.0.0.0/8 ; ::1 + no_more + +This router only handles mail which is not to any local domains; this is +specified by the line + +domains = ! +local_domains + +The domains option lists the domains to which this router applies, but the +exclamation mark is a negation sign, so the router is used only for domains +that are not in the domain list called local_domains (which was defined at the +start of the configuration). The plus sign before local_domains indicates that +it is referring to a named list. Addresses in other domains are passed on to +the following routers. + +The name of the router driver is manualroute because we are manually specifying +how mail should be routed onwards, instead of using DNS MX. While the name of +this router instance is arbitrary, the driver option must be one of the driver +modules that is in the Exim binary. + +With no pre-conditions other than domains, all mail for non-local domains will +be handled by this router, and the no_more setting will ensure that no other +routers will be used for messages matching the pre-conditions. See 3.12 for +more on how the pre-conditions apply. For messages which are handled by this +router, we provide a hostname to deliver to in route_data and the macro +supplies the value; the address is then queued for the smarthost_smtp +transport. + +dnslookup: + driver = dnslookup + domains = ! +local_domains + transport = remote_smtp + ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8 + no_more + +The domains option behaves as per smarthost, above. + +The name of the router driver is dnslookup, and is specified by the driver +option. Do not be confused by the fact that the name of this router instance is +the same as the name of the driver. The instance name is arbitrary, but the +name set in the driver option must be one of the driver modules that is in the +Exim binary. + +The dnslookup router routes addresses by looking up their domains in the DNS in +order to obtain a list of hosts to which the address is routed. If the router +succeeds, the address is queued for the remote_smtp transport, as specified by +the transport option. If the router does not find the domain in the DNS, no +further routers are tried because of the no_more setting, so the address fails +and is bounced. + +The ignore_target_hosts option specifies a list of IP addresses that are to be +entirely ignored. This option is present because a number of cases have been +encountered where MX records in the DNS point to host names whose IP addresses +are 0.0.0.0 or are in the 127 subnet (typically 127.0.0.1). Completely ignoring +these IP addresses causes Exim to fail to route the email address, so it +bounces. Otherwise, Exim would log a routing problem, and continue to try to +deliver the message periodically until the address timed out. + +system_aliases: + driver = redirect + allow_fail + allow_defer + data = ${lookup{$local_part}lsearch{/etc/aliases}} +# user = exim + file_transport = address_file + pipe_transport = address_pipe + +Control reaches this and subsequent routers only for addresses in the local +domains. This router checks to see whether the local part is defined as an +alias in the /etc/aliases file, and if so, redirects it according to the data +that it looks up from that file. If no data is found for the local part, the +value of the data option is empty, causing the address to be passed to the next +router. + +/etc/aliases is a conventional name for the system aliases file that is often +used. That is why it is referenced by from the default configuration file. +However, you can change this by setting SYSTEM_ALIASES_FILE in Local/Makefile +before building Exim. + +userforward: + driver = redirect + check_local_user +# local_part_suffix = +* : -* +# local_part_suffix_optional + file = $home/.forward +# allow_filter + no_verify + no_expn + check_ancestor + file_transport = address_file + pipe_transport = address_pipe + reply_transport = address_reply + +This is the most complicated router in the default configuration. It is another +redirection router, but this time it is looking for forwarding data set up by +individual users. The check_local_user setting specifies a check that the local +part of the address is the login name of a local user. If it is not, the router +is skipped. The two commented options that follow check_local_user, namely: + +# local_part_suffix = +* : -* +# local_part_suffix_optional + +show how you can specify the recognition of local part suffixes. If the first +is uncommented, a suffix beginning with either a plus or a minus sign, followed +by any sequence of characters, is removed from the local part and placed in the +variable $local_part_suffix. The second suffix option specifies that the +presence of a suffix in the local part is optional. When a suffix is present, +the check for a local login uses the local part with the suffix removed. + +When a local user account is found, the file called .forward in the user's home +directory is consulted. If it does not exist, or is empty, the router declines. +Otherwise, the contents of .forward are interpreted as redirection data (see +chapter 22 for more details). + +Traditional .forward files contain just a list of addresses, pipes, or files. +Exim supports this by default. However, if allow_filter is set (it is commented +out by default), the contents of the file are interpreted as a set of Exim or +Sieve filtering instructions, provided the file begins with "#Exim filter" or " +#Sieve filter", respectively. User filtering is discussed in the separate +document entitled Exim's interfaces to mail filtering. + +The no_verify and no_expn options mean that this router is skipped when +verifying addresses, or when running as a consequence of an SMTP EXPN command. +There are two reasons for doing this: + + 1. Whether or not a local user has a .forward file is not really relevant when + checking an address for validity; it makes sense not to waste resources + doing unnecessary work. + + 2. More importantly, when Exim is verifying addresses or handling an EXPN + command during an SMTP session, it is running as the Exim user, not as + root. The group is the Exim group, and no additional groups are set up. It + may therefore not be possible for Exim to read users' .forward files at + this time. + +The setting of check_ancestor prevents the router from generating a new address +that is the same as any previous address that was redirected. (This works round +a problem concerning a bad interaction between aliasing and forwarding - see +section 22.5). + +The final three option settings specify the transports that are to be used when +forwarding generates a direct delivery to a file, or to a pipe, or sets up an +auto-reply, respectively. For example, if a .forward file contains + +a.nother@elsewhere.example, /home/spqr/archive + +the delivery to /home/spqr/archive is done by running the address_file +transport. + +localuser: + driver = accept + check_local_user +# local_part_suffix = +* : -* +# local_part_suffix_optional + transport = local_delivery + +The final router sets up delivery into local mailboxes, provided that the local +part is the name of a local login, by accepting the address and assigning it to +the local_delivery transport. Otherwise, we have reached the end of the +routers, so the address is bounced. The commented suffix settings fulfil the +same purpose as they do for the userforward router. + + +7.5 Transport configuration +--------------------------- + +Transports define mechanisms for actually delivering messages. They operate +only when referenced from routers, so the order in which they are defined does +not matter. The transports section of the configuration starts with + +begin transports + +Two remote transports and four local transports are defined. + +remote_smtp: + driver = smtp + message_size_limit = ${if > {$max_received_linelength}{998} {1}{0}} +.ifdef _HAVE_DANE + dnssec_request_domains = * + hosts_try_dane = * +.endif +.ifdef _HAVE_PRDR + hosts_try_prdr = * +.endif + +This transport is used for delivering messages over SMTP connections. The list +of remote hosts comes from the router. The message_size_limit usage is a hack +to avoid sending on messages with over-long lines. The built-in macro +_HAVE_DANE guards configuration to try to use DNSSEC for all queries and to use +DANE for delivery; see section 42.15 for more details. + +The hosts_try_prdr option enables an efficiency SMTP option. It is negotiated +between client and server and not expected to cause problems but can be +disabled if needed. The built-in macro _HAVE_PRDR guards the use of the +hosts_try_prdr configuration option. + +The other remote transport is used when delivering to a specific smarthost with +whom there must be some kind of existing relationship, instead of the usual +federated system. + +smarthost_smtp: + driver = smtp + message_size_limit = ${if > {$max_received_linelength}{998} {1}{0}} + multi_domain + # +.ifdef _HAVE_TLS + # Comment out any of these which you have to, then file a Support + # request with your smarthost provider to get things fixed: + hosts_require_tls = * + tls_verify_hosts = * + # As long as tls_verify_hosts is enabled, this won't matter, but if you + # have to comment it out then this will at least log whether you succeed + # or not: + tls_try_verify_hosts = * + # + # The SNI name should match the name which we'll expect to verify; + # many mail systems don't use SNI and this doesn't matter, but if it does, + # we need to send a name which the remote site will recognize. + # This _should_ be the name which the smarthost operators specified as + # the hostname for sending your mail to. + tls_sni = ROUTER_SMARTHOST + # +.ifdef _HAVE_OPENSSL + tls_require_ciphers = HIGH:!aNULL:@STRENGTH +.endif +.ifdef _HAVE_GNUTLS + tls_require_ciphers = SECURE192:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1 +.endif +.endif +.ifdef _HAVE_PRDR + hosts_try_prdr = * +.endif + +After the same message_size_limit hack, we then specify that this Transport can +handle messages to multiple domains in one run. The assumption here is that +you're routing all non-local mail to the same place and that place is happy to +take all messages from you as quickly as possible. All other options depend +upon built-in macros; if Exim was built without TLS support then no other +options are defined. If TLS is available, then we configure "stronger than +default" TLS ciphersuites and versions using the tls_require_ciphers option, +where the value to be used depends upon the library providing TLS. Beyond that, +the options adopt the stance that you should have TLS support available from +your smarthost on today's Internet, so we turn on requiring TLS for the mail to +be delivered, and requiring that the certificate be valid, and match the +expected hostname. The tls_sni option can be used by service providers to +select an appropriate certificate to present to you and here we re-use the +ROUTER_SMARTHOST macro, because that is unaffected by CNAMEs present in DNS. +You want to specify the hostname which you'll expect to validate for, and that +should not be subject to insecure tampering via DNS results. + +For the hosts_try_prdr option see the previous transport. + +All other options are defaulted. + +local_delivery: + driver = appendfile + file = /var/mail/$local_part + delivery_date_add + envelope_to_add + return_path_add +# group = mail +# mode = 0660 + +This appendfile transport is used for local delivery to user mailboxes in +traditional BSD mailbox format. By default it runs under the uid and gid of the +local user, which requires the sticky bit to be set on the /var/mail directory. +Some systems use the alternative approach of running mail deliveries under a +particular group instead of using the sticky bit. The commented options show +how this can be done. + +Exim adds three headers to the message as it delivers it: Delivery-date:, +Envelope-to: and Return-path:. This action is requested by the three +similarly-named options above. + +address_pipe: + driver = pipe + return_output + +This transport is used for handling deliveries to pipes that are generated by +redirection (aliasing or users' .forward files). The return_output option +specifies that any output on stdout or stderr generated by the pipe is to be +returned to the sender. + +address_file: + driver = appendfile + delivery_date_add + envelope_to_add + return_path_add + +This transport is used for handling deliveries to files that are generated by +redirection. The name of the file is not specified in this instance of +appendfile, because it comes from the redirect router. + +address_reply: + driver = autoreply + +This transport is used for handling automatic replies generated by users' +filter files. + + +7.6 Default retry rule +---------------------- + +The retry section of the configuration file contains rules which affect the way +Exim retries deliveries that cannot be completed at the first attempt. It is +introduced by the line + +begin retry + +In the default configuration, there is just one rule, which applies to all +errors: + +* * F,2h,15m; G,16h,1h,1.5; F,4d,6h + +This causes any temporarily failing address to be retried every 15 minutes for +2 hours, then at intervals starting at one hour and increasing by a factor of +1.5 until 16 hours have passed, then every 6 hours up to 4 days. If an address +is not delivered after 4 days of temporary failure, it is bounced. The time is +measured from first failure, not from the time the message was received. + +If the retry section is removed from the configuration, or is empty (that is, +if no retry rules are defined), Exim will not retry deliveries. This turns +temporary errors into permanent errors. + + +7.7 Rewriting configuration +--------------------------- + +The rewriting section of the configuration, introduced by + +begin rewrite + +contains rules for rewriting addresses in messages as they arrive. There are no +rewriting rules in the default configuration file. + + +7.8 Authenticators configuration +-------------------------------- + +The authenticators section of the configuration, introduced by + +begin authenticators + +defines mechanisms for the use of the SMTP AUTH command. The default +configuration file contains two commented-out example authenticators which +support plaintext username/password authentication using the standard PLAIN +mechanism and the traditional but non-standard LOGIN mechanism, with Exim +acting as the server. PLAIN and LOGIN are enough to support most MUA software. + +The example PLAIN authenticator looks like this: + +#PLAIN: +# driver = plaintext +# server_set_id = $auth2 +# server_prompts = : +# server_condition = Authentication is not yet configured +# server_advertise_condition = ${if def:tls_in_cipher } + +And the example LOGIN authenticator looks like this: + +#LOGIN: +# driver = plaintext +# server_set_id = $auth1 +# server_prompts = <| Username: | Password: +# server_condition = Authentication is not yet configured +# server_advertise_condition = ${if def:tls_in_cipher } + +The server_set_id option makes Exim remember the authenticated username in +$authenticated_id, which can be used later in ACLs or routers. The +server_prompts option configures the plaintext authenticator so that it +implements the details of the specific authentication mechanism, i.e. PLAIN or +LOGIN. The server_advertise_condition setting controls when Exim offers +authentication to clients; in the examples, this is only when TLS or SSL has +been started, so to enable the authenticators you also need to add support for +TLS as described in section 7.2. + +The server_condition setting defines how to verify that the username and +password are correct. In the examples it just produces an error message. To +make the authenticators work, you can use a string expansion expression like +one of the examples in chapter 34. + +Beware that the sequence of the parameters to PLAIN and LOGIN differ; the +usercode and password are in different positions. Chapter 34 covers both. + + + +=============================================================================== +8. REGULAR EXPRESSIONS + +Exim supports the use of regular expressions in many of its options. It uses +the PCRE regular expression library; this provides regular expression matching +that is compatible with Perl 5. The syntax and semantics of regular expressions +is discussed in online Perl manpages, in many Perl reference books, and also in +Jeffrey Friedl's Mastering Regular Expressions, which is published by O'Reilly +(see http://www.oreilly.com/catalog/regex2/). + +The documentation for the syntax and semantics of the regular expressions that +are supported by PCRE is included in the PCRE distribution, and no further +description is included here. The PCRE functions are called from Exim using the +default option settings (that is, with no PCRE options set), except that the +PCRE_CASELESS option is set when the matching is required to be +case-insensitive. + +In most cases, when a regular expression is required in an Exim configuration, +it has to start with a circumflex, in order to distinguish it from plain text +or an "ends with" wildcard. In this example of a configuration setting, the +second item in the colon-separated list is a regular expression. + +domains = a.b.c : ^\\d{3} : *.y.z : ... + +The doubling of the backslash is required because of string expansion that +precedes interpretation - see section 11.1 for more discussion of this issue, +and a way of avoiding the need for doubling backslashes. The regular expression +that is eventually used in this example contains just one backslash. The +circumflex is included in the regular expression, and has the normal effect of +"anchoring" it to the start of the string that is being matched. + +There are, however, two cases where a circumflex is not required for the +recognition of a regular expression: these are the match condition in a string +expansion, and the matches condition in an Exim filter file. In these cases, +the relevant string is always treated as a regular expression; if it does not +start with a circumflex, the expression is not anchored, and can match anywhere +in the subject string. + +In all cases, if you want a regular expression to match at the end of a string, +you must code the $ metacharacter to indicate this. For example: + +domains = ^\\d{3}\\.example + +matches the domain 123.example, but it also matches 123.example.com. You need +to use: + +domains = ^\\d{3}\\.example\$ + +if you want example to be the top-level domain. The backslash before the $ is +needed because string expansion also interprets dollar characters. + + + +=============================================================================== +9. FILE AND DATABASE LOOKUPS + +Exim can be configured to look up data in files or databases as it processes +messages. Two different kinds of syntax are used: + + 1. A string that is to be expanded may contain explicit lookup requests. These + cause parts of the string to be replaced by data that is obtained from the + lookup. Lookups of this type are conditional expansion items. Different + results can be defined for the cases of lookup success and failure. See + chapter 11, where string expansions are described in detail. The key for + the lookup is specified as part of the string expansion. + + 2. Lists of domains, hosts, and email addresses can contain lookup requests as + a way of avoiding excessively long linear lists. In this case, the data + that is returned by the lookup is often (but not always) discarded; whether + the lookup succeeds or fails is what really counts. These kinds of list are + described in chapter 10. The key for the lookup is given by the context in + which the list is expanded. + +String expansions, lists, and lookups interact with each other in such a way +that there is no order in which to describe any one of them that does not +involve references to the others. Each of these three chapters makes more sense +if you have read the other two first. If you are reading this for the first +time, be aware that some of it will make a lot more sense after you have read +chapters 10 and 11. + + +9.1 Examples of different lookup syntax +--------------------------------------- + +It is easy to confuse the two different kinds of lookup, especially as the +lists that may contain the second kind are always expanded before being +processed as lists. Therefore, they may also contain lookups of the first kind. +Be careful to distinguish between the following two examples: + +domains = ${lookup{$sender_host_address}lsearch{/some/file}} +domains = lsearch;/some/file + +The first uses a string expansion, the result of which must be a domain list. +No strings have been specified for a successful or a failing lookup; the +defaults in this case are the looked-up data and an empty string, respectively. +The expansion takes place before the string is processed as a list, and the +file that is searched could contain lines like this: + +192.168.3.4: domain1:domain2:... +192.168.1.9: domain3:domain4:... + +When the lookup succeeds, the result of the expansion is a list of domains (and +possibly other types of item that are allowed in domain lists). + +In the second example, the lookup is a single item in a domain list. It causes +Exim to use a lookup to see if the domain that is being processed can be found +in the file. The file could contains lines like this: + +domain1: +domain2: + +Any data that follows the keys is not relevant when checking that the domain +matches the list item. + +It is possible, though no doubt confusing, to use both kinds of lookup at once. +Consider a file containing lines like this: + +192.168.5.6: lsearch;/another/file + +If the value of $sender_host_address is 192.168.5.6, expansion of the first +domains setting above generates the second setting, which therefore causes a +second lookup to occur. + +The rest of this chapter describes the different lookup types that are +available. Any of them can be used in any part of the configuration where a +lookup is permitted. + + +9.2 Lookup types +---------------- + +Two different types of data lookup are implemented: + + * The single-key type requires the specification of a file in which to look, + and a single key to search for. The key must be a non-empty string for the + lookup to succeed. The lookup type determines how the file is searched. + + * The query-style type accepts a generalized database query. No particular + key value is assumed by Exim for query-style lookups. You can use whichever + Exim variables you need to construct the database query. + +The code for each lookup type is in a separate source file that is included in +the binary of Exim only if the corresponding compile-time option is set. The +default settings in src/EDITME are: + +LOOKUP_DBM=yes +LOOKUP_LSEARCH=yes + +which means that only linear searching and DBM lookups are included by default. +For some types of lookup (e.g. SQL databases), you need to install appropriate +libraries and header files before building Exim. + + +9.3 Single-key lookup types +--------------------------- + +The following single-key lookup types are implemented: + + * cdb: The given file is searched as a Constant DataBase file, using the key + string without a terminating binary zero. The cdb format is designed for + indexed files that are read frequently and never updated, except by total + re-creation. As such, it is particularly suitable for large files + containing aliases or other indexed data referenced by an MTA. Information + about cdb and tools for building the files can be found in several places: + + https://cr.yp.to/cdb.html + http://www.corpit.ru/mjt/tinycdb.html + https://packages.debian.org/stable/utils/freecdb + https://github.com/philpennock/cdbtools (in Go) + + A cdb distribution is not needed in order to build Exim with cdb support, + because the code for reading cdb files is included directly in Exim itself. + However, no means of building or testing cdb files is provided with Exim, + so you need to obtain a cdb distribution in order to do this. + + * dbm: Calls to DBM library functions are used to extract data from the given + DBM file by looking up the record with the given key. A terminating binary + zero is included in the key that is passed to the DBM library. See section + 4.4 for a discussion of DBM libraries. + + For all versions of Berkeley DB, Exim uses the DB_HASH style of database + when building DBM files using the exim_dbmbuild utility. However, when + using Berkeley DB versions 3 or 4, it opens existing databases for reading + with the DB_UNKNOWN option. This enables it to handle any of the types of + database that the library supports, and can be useful for accessing DBM + files created by other applications. (For earlier DB versions, DB_HASH is + always used.) + + * dbmjz: This is the same as dbm, except that the lookup key is interpreted + as an Exim list; the elements of the list are joined together with ASCII + NUL characters to form the lookup key. An example usage would be to + authenticate incoming SMTP calls using the passwords from Cyrus SASL's /etc + /sasldb2 file with the gsasl authenticator or Exim's own cram_md5 + authenticator. + + * dbmnz: This is the same as dbm, except that a terminating binary zero is + not included in the key that is passed to the DBM library. You may need + this if you want to look up data in files that are created by or shared + with some other application that does not use terminating zeros. For + example, you need to use dbmnz rather than dbm if you want to authenticate + incoming SMTP calls using the passwords from Courier's /etc/ + userdbshadow.dat file. Exim's utility program for creating DBM files ( + exim_dbmbuild) includes the zeros by default, but has an option to omit + them (see section 53.9). + + * dsearch: The given file must be a directory; this is searched for an entry + whose name is the key by calling the lstat() function. The key may not + contain any forward slash characters. If lstat() succeeds, the result of + the lookup is the name of the entry, which may be a file, directory, + symbolic link, or any other kind of directory entry. An example of how this + lookup can be used to support virtual domains is given in section 50.7. + + * iplsearch: The given file is a text file containing keys and data. A key is + terminated by a colon or white space or the end of the line. The keys in + the file must be IP addresses, or IP addresses with CIDR masks. Keys that + involve IPv6 addresses must be enclosed in quotes to prevent the first + internal colon being interpreted as a key terminator. For example: + + 1.2.3.4: data for 1.2.3.4 + 192.168.0.0/16: data for 192.168.0.0/16 + "abcd::cdab": data for abcd::cdab + "abcd:abcd::/32" data for abcd:abcd::/32 + + The key for an iplsearch lookup must be an IP address (without a mask). The + file is searched linearly, using the CIDR masks where present, until a + matching key is found. The first key that matches is used; there is no + attempt to find a "best" match. Apart from the way the keys are matched, + the processing for iplsearch is the same as for lsearch. + + Warning 1: Unlike most other single-key lookup types, a file of data for + iplsearch can not be turned into a DBM or cdb file, because those lookup + types support only literal keys. + + Warning 2: In a host list, you must always use net-iplsearch so that the + implicit key is the host's IP address rather than its name (see section + 10.12). + + * lsearch: The given file is a text file that is searched linearly for a line + beginning with the search key, terminated by a colon or white space or the + end of the line. The search is case-insensitive; that is, upper and lower + case letters are treated as the same. The first occurrence of the key that + is found in the file is used. + + White space between the key and the colon is permitted. The remainder of + the line, with leading and trailing white space removed, is the data. This + can be continued onto subsequent lines by starting them with any amount of + white space, but only a single space character is included in the data at + such a junction. If the data begins with a colon, the key must be + terminated by a colon, for example: + + baduser: :fail: + + Empty lines and lines beginning with # are ignored, even if they occur in + the middle of an item. This is the traditional textual format of alias + files. Note that the keys in an lsearch file are literal strings. There is + no wildcarding of any kind. + + In most lsearch files, keys are not required to contain colons or # + characters, or white space. However, if you need this feature, it is + available. If a key begins with a doublequote character, it is terminated + only by a matching quote (or end of line), and the normal escaping rules + apply to its contents (see section 6.17). An optional colon is permitted + after quoted keys (exactly as for unquoted keys). There is no special + handling of quotes for the data part of an lsearch line. + + * nis: The given file is the name of a NIS map, and a NIS lookup is done with + the given key, without a terminating binary zero. There is a variant called + nis0 which does include the terminating binary zero in the key. This is + reportedly needed for Sun-style alias files. Exim does not recognize NIS + aliases; the full map names must be used. + + * wildlsearch or nwildlsearch: These search a file linearly, like lsearch, + but instead of being interpreted as a literal string, each key in the file + may be wildcarded. The difference between these two lookup types is that + for wildlsearch, each key in the file is string-expanded before being used, + whereas for nwildlsearch, no expansion takes place. + + Like lsearch, the testing is done case-insensitively. However, keys in the + file that are regular expressions can be made case-sensitive by the use of + "(-i)" within the pattern. The following forms of wildcard are recognized: + + 1. The string may begin with an asterisk to mean "ends with". For example: + + *.a.b.c data for anything.a.b.c + *fish data for anythingfish + + 2. The string may begin with a circumflex to indicate a regular + expression. For example, for wildlsearch: + + ^\N\d+\.a\.b\N data for <digits>.a.b + + Note the use of "\N" to disable expansion of the contents of the + regular expression. If you are using nwildlsearch, where the keys are + not string-expanded, the equivalent entry is: + + ^\d+\.a\.b data for <digits>.a.b + + The case-insensitive flag is set at the start of compiling the regular + expression, but it can be turned off by using "(-i)" at an appropriate + point. For example, to make the entire pattern case-sensitive: + + ^(?-i)\d+\.a\.b data for <digits>.a.b + + If the regular expression contains white space or colon characters, you + must either quote it (see lsearch above), or represent these characters + in other ways. For example, "\s" can be used for white space and "\x3A" + for a colon. This may be easier than quoting, because if you quote, you + have to escape all the backslashes inside the quotes. + + Note: It is not possible to capture substrings in a regular expression + match for later use, because the results of all lookups are cached. If + a lookup is repeated, the result is taken from the cache, and no actual + pattern matching takes place. The values of all the numeric variables + are unset after a (n)wildlsearch match. + + 3. Although I cannot see it being of much use, the general matching + function that is used to implement (n)wildlsearch means that the string + may begin with a lookup name terminated by a semicolon, and followed by + lookup data. For example: + + cdb;/some/file data for keys that match the file + + The data that is obtained from the nested lookup is discarded. + + Keys that do not match any of these patterns are interpreted literally. The + continuation rules for the data are the same as for lsearch, and keys may + be followed by optional colons. + + Warning: Unlike most other single-key lookup types, a file of data for (n) + wildlsearch can not be turned into a DBM or cdb file, because those lookup + types support only literal keys. + + * If Exim is built with SPF support, manual lookups can be done (as opposed + to the standard ACL condition method. For details see section 57.4. + + +9.4 Query-style lookup types +---------------------------- + +The supported query-style lookup types are listed below. Further details about +many of them are given in later sections. + + * dnsdb: This does a DNS search for one or more records whose domain names + are given in the supplied query. The resulting data is the contents of the + records. See section 9.10. + + * ibase: This does a lookup in an InterBase database. + + * ldap: This does an LDAP lookup using a query in the form of a URL, and + returns attributes from a single entry. There is a variant called ldapm + that permits values from multiple entries to be returned. A third variant + called ldapdn returns the Distinguished Name of a single entry instead of + any attribute values. See section 9.14. + + * mysql: The format of the query is an SQL statement that is passed to a + MySQL database. See section 9.21. + + * nisplus: This does a NIS+ lookup using a query that can specify the name of + the field to be returned. See section 9.20. + + * oracle: The format of the query is an SQL statement that is passed to an + Oracle database. See section 9.21. + + * passwd is a query-style lookup with queries that are just user names. The + lookup calls getpwnam() to interrogate the system password data, and on + success, the result string is the same as you would get from an lsearch + lookup on a traditional /etc/passwd file, though with "*" for the password + value. For example: + + *:42:42:King Rat:/home/kr:/bin/bash + + * pgsql: The format of the query is an SQL statement that is passed to a + PostgreSQL database. See section 9.21. + + * redis: The format of the query is either a simple get or simple set, passed + to a Redis database. See section 9.21. + + * sqlite: The format of the query is a filename followed by an SQL statement + that is passed to an SQLite database. See section 9.26. + + * testdb: This is a lookup type that is used for testing Exim. It is not + likely to be useful in normal operation. + + * whoson: Whoson (http://whoson.sourceforge.net) is a protocol that allows a + server to check whether a particular (dynamically allocated) IP address is + currently allocated to a known (trusted) user and, optionally, to obtain + the identity of the said user. For SMTP servers, Whoson was popular at one + time for "POP before SMTP" authentication, but that approach has been + superseded by SMTP authentication. In Exim, Whoson can be used to implement + "POP before SMTP" checking using ACL statements such as + + require condition = \ + ${lookup whoson {$sender_host_address}{yes}{no}} + + The query consists of a single IP address. The value returned is the name + of the authenticated user, which is stored in the variable $value. However, + in this example, the data in $value is not used; the result of the lookup + is one of the fixed strings "yes" or "no". + + +9.5 Temporary errors in lookups +------------------------------- + +Lookup functions can return temporary error codes if the lookup cannot be +completed. For example, an SQL or LDAP database might be unavailable. For this +reason, it is not advisable to use a lookup that might do this for critical +options such as a list of local domains. + +When a lookup cannot be completed in a router or transport, delivery of the +message (to the relevant address) is deferred, as for any other temporary +error. In other circumstances Exim may assume the lookup has failed, or may +give up altogether. + + +9.6 Default values in single-key lookups +---------------------------------------- + +In this context, a "default value" is a value specified by the administrator +that is to be used if a lookup fails. + +Note: This section applies only to single-key lookups. For query-style lookups, +the facilities of the query language must be used. An attempt to specify a +default for a query-style lookup provokes an error. + +If "*" is added to a single-key lookup type (for example, lsearch*) and the +initial lookup fails, the key "*" is looked up in the file to provide a default +value. See also the section on partial matching below. + +Alternatively, if "*@" is added to a single-key lookup type (for example dbm*@) +then, if the initial lookup fails and the key contains an @ character, a second +lookup is done with everything before the last @ replaced by *. This makes it +possible to provide per-domain defaults in alias files that include the domains +in the keys. If the second lookup fails (or doesn't take place because there is +no @ in the key), "*" is looked up. For example, a redirect router might +contain: + +data = ${lookup{$local_part@$domain}lsearch*@{/etc/mix-aliases}} + +Suppose the address that is being processed is jane@eyre.example. Exim looks up +these keys, in this order: + +jane@eyre.example +*@eyre.example +* + +The data is taken from whichever key it finds first. Note: In an lsearch file, +this does not mean the first of these keys in the file. A complete scan is done +for each key, and only if it is not found at all does Exim move on to try the +next key. + + +9.7 Partial matching in single-key lookups +------------------------------------------ + +The normal operation of a single-key lookup is to search the file for an exact +match with the given key. However, in a number of situations where domains are +being looked up, it is useful to be able to do partial matching. In this case, +information in the file that has a key starting with "*." is matched by any +domain that ends with the components that follow the full stop. For example, if +a key in a DBM file is + +*.dates.fict.example + +then when partial matching is enabled this is matched by (amongst others) +2001.dates.fict.example and 1984.dates.fict.example. It is also matched by +dates.fict.example, if that does not appear as a separate key in the file. + +Note: Partial matching is not available for query-style lookups. It is also not +available for any lookup items in address lists (see section 10.19). + +Partial matching is implemented by doing a series of separate lookups using +keys constructed by modifying the original subject key. This means that it can +be used with any of the single-key lookup types, provided that partial matching +keys beginning with a special prefix (default "*.") are included in the data +file. Keys in the file that do not begin with the prefix are matched only by +unmodified subject keys when partial matching is in use. + +Partial matching is requested by adding the string "partial-" to the front of +the name of a single-key lookup type, for example, partial-dbm. When this is +done, the subject key is first looked up unmodified; if that fails, "*." is +added at the start of the subject key, and it is looked up again. If that +fails, further lookups are tried with dot-separated components removed from the +start of the subject key, one-by-one, and "*." added on the front of what +remains. + +A minimum number of two non-* components are required. This can be adjusted by +including a number before the hyphen in the search type. For example, +partial3-lsearch specifies a minimum of three non-* components in the modified +keys. Omitting the number is equivalent to "partial2-". If the subject key is +2250.dates.fict.example then the following keys are looked up when the minimum +number of non-* components is two: + +2250.dates.fict.example +*.2250.dates.fict.example +*.dates.fict.example +*.fict.example + +As soon as one key in the sequence is successfully looked up, the lookup +finishes. + +The use of "*." as the partial matching prefix is a default that can be +changed. The motivation for this feature is to allow Exim to operate with file +formats that are used by other MTAs. A different prefix can be supplied in +parentheses instead of the hyphen after "partial". For example: + +domains = partial(.)lsearch;/some/file + +In this example, if the domain is a.b.c, the sequence of lookups is "a.b.c", +".a.b.c", and ".b.c" (the default minimum of 2 non-wild components is +unchanged). The prefix may consist of any punctuation characters other than a +closing parenthesis. It may be empty, for example: + +domains = partial1()cdb;/some/file + +For this example, if the domain is a.b.c, the sequence of lookups is "a.b.c", +"b.c", and "c". + +If "partial0" is specified, what happens at the end (when the lookup with just +one non-wild component has failed, and the original key is shortened right down +to the null string) depends on the prefix: + + * If the prefix has zero length, the whole lookup fails. + + * If the prefix has length 1, a lookup for just the prefix is done. For + example, the final lookup for "partial0(.)" is for "." alone. + + * Otherwise, if the prefix ends in a dot, the dot is removed, and the + remainder is looked up. With the default prefix, therefore, the final + lookup is for "*" on its own. + + * Otherwise, the whole prefix is looked up. + +If the search type ends in "*" or "*@" (see section 9.6 above), the search for +an ultimate default that this implies happens after all partial lookups have +failed. If "partial0" is specified, adding "*" to the search type has no effect +with the default prefix, because the "*" key is already included in the +sequence of partial lookups. However, there might be a use for lookup types +such as "partial0(.)lsearch*". + +The use of "*" in lookup partial matching differs from its use as a wildcard in +domain lists and the like. Partial matching works only in terms of +dot-separated components; a key such as "*fict.example" in a database file is +useless, because the asterisk in a partial matching subject key is always +followed by a dot. + + +9.8 Lookup caching +------------------ + +Exim caches all lookup results in order to avoid needless repetition of +lookups. However, because (apart from the daemon) Exim operates as a collection +of independent, short-lived processes, this caching applies only within a +single Exim process. There is no inter-process lookup caching facility. + +For single-key lookups, Exim keeps the relevant files open in case there is +another lookup that needs them. In some types of configuration this can lead to +many files being kept open for messages with many recipients. To avoid hitting +the operating system limit on the number of simultaneously open files, Exim +closes the least recently used file when it needs to open more files than its +own internal limit, which can be changed via the lookup_open_max option. + +The single-key lookup files are closed and the lookup caches are flushed at +strategic points during delivery - for example, after all routing is complete. + + +9.9 Quoting lookup data +----------------------- + +When data from an incoming message is included in a query-style lookup, there +is the possibility of special characters in the data messing up the syntax of +the query. For example, a NIS+ query that contains + +[name=$local_part] + +will be broken if the local part happens to contain a closing square bracket. +For NIS+, data can be enclosed in double quotes like this: + +[name="$local_part"] + +but this still leaves the problem of a double quote in the data. The rule for +NIS+ is that double quotes must be doubled. Other lookup types have different +rules, and to cope with the differing requirements, an expansion operator of +the following form is provided: + +${quote_<lookup-type>:<string>} + +For example, the safest way to write the NIS+ query is + +[name="${quote_nisplus:$local_part}"] + +See chapter 11 for full coverage of string expansions. The quote operator can +be used for all lookup types, but has no effect for single-key lookups, since +no quoting is ever needed in their key strings. + + +9.10 More about dnsdb +--------------------- + +The dnsdb lookup type uses the DNS as its database. A simple query consists of +a record type and a domain name, separated by an equals sign. For example, an +expansion string could contain: + +${lookup dnsdb{mx=a.b.example}{$value}fail} + +If the lookup succeeds, the result is placed in $value, which in this case is +used on its own as the result. If the lookup does not succeed, the "fail" +keyword causes a forced expansion failure - see section 11.4 for an explanation +of what this means. + +The supported DNS record types are A, CNAME, MX, NS, PTR, SOA, SPF, SRV, TLSA +and TXT, and, when Exim is compiled with IPv6 support, AAAA. If no type is +given, TXT is assumed. + +For any record type, if multiple records are found, the data is returned as a +concatenation, with newline as the default separator. The order, of course, +depends on the DNS resolver. You can specify a different separator character +between multiple records by putting a right angle-bracket followed immediately +by the new separator at the start of the query. For example: + +${lookup dnsdb{>: a=host1.example}} + +It is permitted to specify a space as the separator character. Further white +space is ignored. For lookup types that return multiple fields per record, an +alternate field separator can be specified using a comma after the main +separator character, followed immediately by the field separator. + +When the type is PTR, the data can be an IP address, written as normal; +inversion and the addition of in-addr.arpa or ip6.arpa happens automatically. +For example: + +${lookup dnsdb{ptr=192.168.4.5}{$value}fail} + +If the data for a PTR record is not a syntactically valid IP address, it is not +altered and nothing is added. + +For an MX lookup, both the preference value and the host name are returned for +each record, separated by a space. For an SRV lookup, the priority, weight, +port, and host name are returned for each record, separated by spaces. The +field separator can be modified as above. + +For TXT records with multiple items of data, only the first item is returned, +unless a field separator is specified. To concatenate items without a +separator, use a semicolon instead. For SPF records the default behaviour is to +concatenate multiple items without using a separator. + +${lookup dnsdb{>\n,: txt=a.b.example}} +${lookup dnsdb{>\n; txt=a.b.example}} +${lookup dnsdb{spf=example.org}} + +It is permitted to specify a space as the separator character. Further white +space is ignored. + +For an SOA lookup, while no result is obtained the lookup is redone with +successively more leading components dropped from the given domain. Only the +primary-nameserver field is returned unless a field separator is specified. + +${lookup dnsdb{>:,; soa=a.b.example.com}} + + +9.11 Dnsdb lookup modifiers +--------------------------- + +Modifiers for dnsdb lookups are given by optional keywords, each followed by a +comma, that may appear before the record type. + +The dnsdb lookup fails only if all the DNS lookups fail. If there is a +temporary DNS error for any of them, the behaviour is controlled by a +defer-option modifier. The possible keywords are "defer_strict", "defer_never", +and "defer_lax". With "strict" behaviour, any temporary DNS error causes the +whole lookup to defer. With "never" behaviour, a temporary DNS error is +ignored, and the behaviour is as if the DNS lookup failed to find anything. +With "lax" behaviour, all the queries are attempted, but a temporary DNS error +causes the whole lookup to defer only if none of the other lookups succeed. The +default is "lax", so the following lookups are equivalent: + +${lookup dnsdb{defer_lax,a=one.host.com:two.host.com}} +${lookup dnsdb{a=one.host.com:two.host.com}} + +Thus, in the default case, as long as at least one of the DNS lookups yields +some data, the lookup succeeds. + +Use of DNSSEC is controlled by a dnssec modifier. The possible keywords are +"dnssec_strict", "dnssec_lax", and "dnssec_never". With "strict" or "lax" +DNSSEC information is requested with the lookup. With "strict" a response from +the DNS resolver that is not labelled as authenticated data is treated as +equivalent to a temporary DNS error. The default is "never". + +See also the $lookup_dnssec_authenticated variable. + +Timeout for the dnsdb lookup can be controlled by a retrans modifier. The form +is "retrans_VAL" where VAL is an Exim time specification (e.g. "5s"). The +default value is set by the main configuration option dns_retrans. + +Retries for the dnsdb lookup can be controlled by a retry modifier. The form if +"retry_VAL" where VAL is an integer. The default count is set by the main +configuration option dns_retry. + +Dnsdb lookup results are cached within a single process (and its children). The +cache entry lifetime is limited to the smallest time-to-live (TTL) value of the +set of returned DNS records. + + +9.12 Pseudo dnsdb record types +------------------------------ + +By default, both the preference value and the host name are returned for each +MX record, separated by a space. If you want only host names, you can use the +pseudo-type MXH: + +${lookup dnsdb{mxh=a.b.example}} + +In this case, the preference values are omitted, and just the host names are +returned. + +Another pseudo-type is ZNS (for "zone NS"). It performs a lookup for NS records +on the given domain, but if none are found, it removes the first component of +the domain name, and tries again. This process continues until NS records are +found or there are no more components left (or there is a DNS error). In other +words, it may return the name servers for a top-level domain, but it never +returns the root name servers. If there are no NS records for the top-level +domain, the lookup fails. Consider these examples: + +${lookup dnsdb{zns=xxx.quercite.com}} +${lookup dnsdb{zns=xxx.edu}} + +Assuming that in each case there are no NS records for the full domain name, +the first returns the name servers for quercite.com, and the second returns the +name servers for edu. + +You should be careful about how you use this lookup because, unless the +top-level domain does not exist, the lookup always returns some host names. The +sort of use to which this might be put is for seeing if the name servers for a +given domain are on a blacklist. You can probably assume that the name servers +for the high-level domains such as com or co.uk are not going to be on such a +list. + +A third pseudo-type is CSA (Client SMTP Authorization). This looks up SRV +records according to the CSA rules, which are described in section 43.50. +Although dnsdb supports SRV lookups directly, this is not sufficient because of +the extra parent domain search behaviour of CSA. The result of a successful +lookup such as: + +${lookup dnsdb {csa=$sender_helo_name}} + +has two space-separated fields: an authorization code and a target host name. +The authorization code can be "Y" for yes, "N" for no, "X" for explicit +authorization required but absent, or "?" for unknown. + +The pseudo-type A+ performs an AAAA and then an A lookup. All results are +returned; defer processing (see below) is handled separately for each lookup. +Example: + +${lookup dnsdb {>; a+=$sender_helo_name}} + + +9.13 Multiple dnsdb lookups +--------------------------- + +In the previous sections, dnsdb lookups for a single domain are described. +However, you can specify a list of domains or IP addresses in a single dnsdb +lookup. The list is specified in the normal Exim way, with colon as the default +separator, but with the ability to change this. For example: + +${lookup dnsdb{one.domain.com:two.domain.com}} +${lookup dnsdb{a=one.host.com:two.host.com}} +${lookup dnsdb{ptr = <; 1.2.3.4 ; 4.5.6.8}} + +In order to retain backwards compatibility, there is one special case: if the +lookup type is PTR and no change of separator is specified, Exim looks to see +if the rest of the string is precisely one IPv6 address. In this case, it does +not treat it as a list. + +The data from each lookup is concatenated, with newline separators by default, +in the same way that multiple DNS records for a single item are handled. A +different separator can be specified, as described above. + + +9.14 More about LDAP +-------------------- + +The original LDAP implementation came from the University of Michigan; this has +become "Open LDAP", and there are now two different releases. Another +implementation comes from Netscape, and Solaris 7 and subsequent releases +contain inbuilt LDAP support. Unfortunately, though these are all compatible at +the lookup function level, their error handling is different. For this reason +it is necessary to set a compile-time variable when building Exim with LDAP, to +indicate which LDAP library is in use. One of the following should appear in +your Local/Makefile: + +LDAP_LIB_TYPE=UMICHIGAN +LDAP_LIB_TYPE=OPENLDAP1 +LDAP_LIB_TYPE=OPENLDAP2 +LDAP_LIB_TYPE=NETSCAPE +LDAP_LIB_TYPE=SOLARIS + +If LDAP_LIB_TYPE is not set, Exim assumes "OPENLDAP1", which has the same +interface as the University of Michigan version. + +There are three LDAP lookup types in Exim. These behave slightly differently in +the way they handle the results of a query: + + * ldap requires the result to contain just one entry; if there are more, it + gives an error. + + * ldapdn also requires the result to contain just one entry, but it is the + Distinguished Name that is returned rather than any attribute values. + + * ldapm permits the result to contain more than one entry; the attributes + from all of them are returned. + +For ldap and ldapm, if a query finds only entries with no attributes, Exim +behaves as if the entry did not exist, and the lookup fails. The format of the +data returned by a successful lookup is described in the next section. First we +explain how LDAP queries are coded. + + +9.15 Format of LDAP queries +--------------------------- + +An LDAP query takes the form of a URL as defined in RFC 2255. For example, in +the configuration of a redirect router one might have this setting: + +data = ${lookup ldap \ + {ldap:///cn=$local_part,o=University%20of%20Cambridge,\ + c=UK?mailbox?base?}} + +The URL may begin with "ldap" or "ldaps" if your LDAP library supports secure +(encrypted) LDAP connections. The second of these ensures that an encrypted TLS +connection is used. + +With sufficiently modern LDAP libraries, Exim supports forcing TLS over regular +LDAP connections, rather than the SSL-on-connect "ldaps". See the +ldap_start_tls option. + +Starting with Exim 4.83, the initialization of LDAP with TLS is more tightly +controlled. Every part of the TLS configuration can be configured by settings +in exim.conf. Depending on the version of the client libraries installed on +your system, some of the initialization may have required setting options in / +etc/ldap.conf or ~/.ldaprc to get TLS working with self-signed certificates. +This revealed a nuance where the current UID that exim was running as could +affect which config files it read. With Exim 4.83, these methods become +optional, only taking effect if not specifically set in exim.conf. + + +9.16 LDAP quoting +----------------- + +Two levels of quoting are required in LDAP queries, the first for LDAP itself +and the second because the LDAP query is represented as a URL. Furthermore, +within an LDAP query, two different kinds of quoting are required. For this +reason, there are two different LDAP-specific quoting operators. + +The quote_ldap operator is designed for use on strings that are part of filter +specifications. Conceptually, it first does the following conversions on the +string: + +* => \2A +( => \28 +) => \29 +\ => \5C + +in accordance with RFC 2254. The resulting string is then quoted according to +the rules for URLs, that is, all non-alphanumeric characters except + +! $ ' - . _ ( ) * + + +are converted to their hex values, preceded by a percent sign. For example: + +${quote_ldap: a(bc)*, a<yz>; } + +yields + +%20a%5C28bc%5C29%5C2A%2C%20a%3Cyz%3E%3B%20 + +Removing the URL quoting, this is (with a leading and a trailing space): + +a\28bc\29\2A, a<yz>; + +The quote_ldap_dn operator is designed for use on strings that are part of base +DN specifications in queries. Conceptually, it first converts the string by +inserting a backslash in front of any of the following characters: + +, + " \ < > ; + +It also inserts a backslash before any leading spaces or # characters, and +before any trailing spaces. (These rules are in RFC 2253.) The resulting string +is then quoted according to the rules for URLs. For example: + +${quote_ldap_dn: a(bc)*, a<yz>; } + +yields + +%5C%20a(bc)*%5C%2C%20a%5C%3Cyz%5C%3E%5C%3B%5C%20 + +Removing the URL quoting, this is (with a trailing space): + +\ a(bc)*\, a\<yz\>\;\ + +There are some further comments about quoting in the section on LDAP +authentication below. + + +9.17 LDAP connections +--------------------- + +The connection to an LDAP server may either be over TCP/IP, or, when OpenLDAP +is in use, via a Unix domain socket. The example given above does not specify +an LDAP server. A server that is reached by TCP/IP can be specified in a query +by starting it with + +ldap://<hostname>:<port>/... + +If the port (and preceding colon) are omitted, the standard LDAP port (389) is +used. When no server is specified in a query, a list of default servers is +taken from the ldap_default_servers configuration option. This supplies a +colon-separated list of servers which are tried in turn until one successfully +handles a query, or there is a serious error. Successful handling either +returns the requested data, or indicates that it does not exist. Serious errors +are syntactical, or multiple values when only a single value is expected. +Errors which cause the next server to be tried are connection failures, bind +failures, and timeouts. + +For each server name in the list, a port number can be given. The standard way +of specifying a host and port is to use a colon separator (RFC 1738). Because +ldap_default_servers is a colon-separated list, such colons have to be doubled. +For example + +ldap_default_servers = ldap1.example.com::145:ldap2.example.com + +If ldap_default_servers is unset, a URL with no server name is passed to the +LDAP library with no server name, and the library's default (normally the local +host) is used. + +If you are using the OpenLDAP library, you can connect to an LDAP server using +a Unix domain socket instead of a TCP/IP connection. This is specified by using +"ldapi" instead of "ldap" in LDAP queries. What follows here applies only to +OpenLDAP. If Exim is compiled with a different LDAP library, this feature is +not available. + +For this type of connection, instead of a host name for the server, a pathname +for the socket is required, and the port number is not relevant. The pathname +can be specified either as an item in ldap_default_servers, or inline in the +query. In the former case, you can have settings such as + +ldap_default_servers = /tmp/ldap.sock : backup.ldap.your.domain + +When the pathname is given in the query, you have to escape the slashes as +"%2F" to fit in with the LDAP URL syntax. For example: + +${lookup ldap {ldapi://%2Ftmp%2Fldap.sock/o=... + +When Exim processes an LDAP lookup and finds that the "hostname" is really a +pathname, it uses the Unix domain socket code, even if the query actually +specifies "ldap" or "ldaps". In particular, no encryption is used for a socket +connection. This behaviour means that you can use a setting of +ldap_default_servers such as in the example above with traditional "ldap" or +"ldaps" queries, and it will work. First, Exim tries a connection via the Unix +domain socket; if that fails, it tries a TCP/IP connection to the backup host. + +If an explicit "ldapi" type is given in a query when a host name is specified, +an error is diagnosed. However, if there are more items in ldap_default_servers +, they are tried. In other words: + + * Using a pathname with "ldap" or "ldaps" forces the use of the Unix domain + interface. + + * Using "ldapi" with a host name causes an error. + +Using "ldapi" with no host or path in the query, and no setting of +ldap_default_servers, does whatever the library does by default. + + +9.18 LDAP authentication and control information +------------------------------------------------ + +The LDAP URL syntax provides no way of passing authentication and other control +information to the server. To make this possible, the URL in an LDAP query may +be preceded by any number of <name>=<value> settings, separated by spaces. If a +value contains spaces it must be enclosed in double quotes, and when double +quotes are used, backslash is interpreted in the usual way inside them. The +following names are recognized: + +DEREFERENCE set the dereferencing parameter +NETTIME set a timeout for a network operation +USER set the DN, for authenticating the LDAP bind +PASS set the password, likewise +REFERRALS set the referrals parameter +SERVERS set alternate server list for this query only +SIZE set the limit for the number of entries returned +TIME set the maximum waiting time for a query + +The value of the DEREFERENCE parameter must be one of the words "never", +"searching", "finding", or "always". The value of the REFERRALS parameter must +be "follow" (the default) or "nofollow". The latter stops the LDAP library from +trying to follow referrals issued by the LDAP server. + +The name CONNECT is an obsolete name for NETTIME, retained for backwards +compatibility. This timeout (specified as a number of seconds) is enforced from +the client end for operations that can be carried out over a network. +Specifically, it applies to network connections and calls to the ldap_result() +function. If the value is greater than zero, it is used if +LDAP_OPT_NETWORK_TIMEOUT is defined in the LDAP headers (OpenLDAP), or if +LDAP_X_OPT_CONNECT_TIMEOUT is defined in the LDAP headers (Netscape SDK 4.1). A +value of zero forces an explicit setting of "no timeout" for Netscape SDK; for +OpenLDAP no action is taken. + +The TIME parameter (also a number of seconds) is passed to the server to set a +server-side limit on the time taken to complete a search. + +The SERVERS parameter allows you to specify an alternate list of ldap servers +to use for an individual lookup. The global ldap_default_servers option +provides a default list of ldap servers, and a single lookup can specify a +single ldap server to use. But when you need to do a lookup with a list of +servers that is different than the default list (maybe different order, maybe a +completely different set of servers), the SERVERS parameter allows you to +specify this alternate list (colon-separated). + +Here is an example of an LDAP query in an Exim lookup that uses some of these +values. This is a single line, folded to fit on the page: + +${lookup ldap + {user="cn=manager,o=University of Cambridge,c=UK" pass=secret + ldap:///o=University%20of%20Cambridge,c=UK?sn?sub?(cn=foo)} + {$value}fail} + +The encoding of spaces as "%20" is a URL thing which should not be done for any +of the auxiliary data. Exim configuration settings that include lookups which +contain password information should be preceded by "hide" to prevent non-admin +users from using the -bP option to see their values. + +The auxiliary data items may be given in any order. The default is no +connection timeout (the system timeout is used), no user or password, no limit +on the number of entries returned, and no time limit on queries. + +When a DN is quoted in the USER= setting for LDAP authentication, Exim removes +any URL quoting that it may contain before passing it LDAP. Apparently some +libraries do this for themselves, but some do not. Removing the URL quoting has +two advantages: + + * It makes it possible to use the same quote_ldap_dn expansion for USER= DNs + as with DNs inside actual queries. + + * It permits spaces inside USER= DNs. + +For example, a setting such as + +USER=cn=${quote_ldap_dn:$1} + +should work even if $1 contains spaces. + +Expanded data for the PASS= value should be quoted using the quote expansion +operator, rather than the LDAP quote operators. The only reason this field +needs quoting is to ensure that it conforms to the Exim syntax, which does not +allow unquoted spaces. For example: + +PASS=${quote:$3} + +The LDAP authentication mechanism can be used to check passwords as part of +SMTP authentication. See the ldapauth expansion string condition in chapter 11. + + +9.19 Format of data returned by LDAP +------------------------------------ + +The ldapdn lookup type returns the Distinguished Name from a single entry as a +sequence of values, for example + +cn=manager,o=University of Cambridge,c=UK + +The ldap lookup type generates an error if more than one entry matches the +search filter, whereas ldapm permits this case, and inserts a newline in the +result between the data from different entries. It is possible for multiple +values to be returned for both ldap and ldapm, but in the former case you know +that whatever values are returned all came from a single entry in the +directory. + +In the common case where you specify a single attribute in your LDAP query, the +result is not quoted, and does not contain the attribute name. If the attribute +has multiple values, they are separated by commas. Any comma that is part of an +attribute's value is doubled. + +If you specify multiple attributes, the result contains space-separated, quoted +strings, each preceded by the attribute name and an equals sign. Within the +quotes, the quote character, backslash, and newline are escaped with +backslashes, and commas are used to separate multiple values for the attribute. +Any commas in attribute values are doubled (permitting treatment of the values +as a comma-separated list). Apart from the escaping, the string within quotes +takes the same form as the output when a single attribute is requested. +Specifying no attributes is the same as specifying all of an entry's +attributes. + +Here are some examples of the output format. The first line of each pair is an +LDAP query, and the second is the data that is returned. The attribute called +attr1 has two values, one of them with an embedded comma, whereas attr2 has +only one value. Both attributes are derived from attr (they have SUP attr in +their schema definitions). + +ldap:///o=base?attr1?sub?(uid=fred) +value1.1,value1,,2 + +ldap:///o=base?attr2?sub?(uid=fred) +value two + +ldap:///o=base?attr?sub?(uid=fred) +value1.1,value1,,2,value two + +ldap:///o=base?attr1,attr2?sub?(uid=fred) +attr1="value1.1,value1,,2" attr2="value two" + +ldap:///o=base??sub?(uid=fred) +objectClass="top" attr1="value1.1,value1,,2" attr2="value two" + +You can make use of Exim's -be option to run expansion tests and thereby check +the results of LDAP lookups. The extract operator in string expansions can be +used to pick out individual fields from data that consists of key=value pairs. +The listextract operator should be used to pick out individual values of +attributes, even when only a single value is expected. The doubling of embedded +commas allows you to use the returned data as a comma separated list (using the +"<," syntax for changing the input list separator). + + +9.20 More about NIS+ +-------------------- + +NIS+ queries consist of a NIS+ indexed name followed by an optional colon and +field name. If this is given, the result of a successful query is the contents +of the named field; otherwise the result consists of a concatenation of +field-name=field-value pairs, separated by spaces. Empty values and values +containing spaces are quoted. For example, the query + +[name=mg1456],passwd.org_dir + +might return the string + +name=mg1456 passwd="" uid=999 gid=999 gcos="Martin Guerre" +home=/home/mg1456 shell=/bin/bash shadow="" + +(split over two lines here to fit on the page), whereas + +[name=mg1456],passwd.org_dir:gcos + +would just return + +Martin Guerre + +with no quotes. A NIS+ lookup fails if NIS+ returns more than one table entry +for the given indexed key. The effect of the quote_nisplus expansion operator +is to double any quote characters within the text. + + +9.21 SQL lookups +---------------- + +Exim can support lookups in InterBase, MySQL, Oracle, PostgreSQL, Redis, and +SQLite databases. Queries for these databases contain SQL statements, so an +example might be + +${lookup mysql{select mailbox from users where id='userx'}\ + {$value}fail} + +If the result of the query contains more than one field, the data for each +field in the row is returned, preceded by its name, so the result of + +${lookup pgsql{select home,name from users where id='userx'}\ + {$value}} + +might be + +home=/home/userx name="Mister X" + +Empty values and values containing spaces are double quoted, with embedded +quotes escaped by a backslash. If the result of the query contains just one +field, the value is passed back verbatim, without a field name, for example: + +Mister X + +If the result of the query yields more than one row, it is all concatenated, +with a newline between the data for each row. + + +9.22 More about MySQL, PostgreSQL, Oracle, InterBase, and Redis +--------------------------------------------------------------- + +If any MySQL, PostgreSQL, Oracle, InterBase or Redis lookups are used, the +mysql_servers, pgsql_servers, oracle_servers, ibase_servers, or redis_servers +option (as appropriate) must be set to a colon-separated list of server +information. (For MySQL and PostgreSQL, the global option need not be set if +all queries contain their own server information - see section 9.23.) For all +but Redis each item in the list is a slash-separated list of four items: host +name, database name, user name, and password. In the case of Oracle, the host +name field is used for the "service name", and the database name field is not +used and should be empty. For example: + +hide oracle_servers = oracle.plc.example//userx/abcdwxyz + +Because password data is sensitive, you should always precede the setting with +"hide", to prevent non-admin users from obtaining the setting via the -bP +option. Here is an example where two MySQL servers are listed: + +hide mysql_servers = localhost/users/root/secret:\ + otherhost/users/root/othersecret + +For MySQL and PostgreSQL, a host may be specified as <name>:<port> but because +this is a colon-separated list, the colon has to be doubled. For each query, +these parameter groups are tried in order until a connection is made and a +query is successfully processed. The result of a query may be that no data is +found, but that is still a successful query. In other words, the list of +servers provides a backup facility, not a list of different places to look. + +For Redis the global option need not be specified if all queries contain their +own server information - see section 9.23. If specified, the option must be set +to a colon-separated list of server information. Each item in the list is a +slash-separated list of three items: host, database number, and password. + + 1. The host is required and may be either an IPv4 address and optional port + number (separated by a colon, which needs doubling due to the higher-level + list), or a Unix socket pathname enclosed in parentheses + + 2. The database number is optional; if present that number is selected in the + backend + + 3. The password is optional; if present it is used to authenticate to the + backend + +The quote_mysql, quote_pgsql, and quote_oracle expansion operators convert +newline, tab, carriage return, and backspace to \n, \t, \r, and \b +respectively, and the characters single-quote, double-quote, and backslash +itself are escaped with backslashes. + +The quote_redis expansion operator escapes whitespace and backslash characters +with a backslash. + + +9.23 Specifying the server in the query +--------------------------------------- + +For MySQL, PostgreSQL and Redis lookups (but not currently for Oracle and +InterBase), it is possible to specify a list of servers with an individual +query. This is done by starting the query with + +servers=server1:server2:server3:...; + +Each item in the list may take one of two forms: + + 1. If it contains no slashes it is assumed to be just a host name. The + appropriate global option (mysql_servers or pgsql_servers) is searched for + a host of the same name, and the remaining parameters (database, user, + password) are taken from there. + + 2. If it contains any slashes, it is taken as a complete parameter set. + +The list of servers is used in exactly the same way as the global list. Once a +connection to a server has happened and a query has been successfully executed, +processing of the lookup ceases. + +This feature is intended for use in master/slave situations where updates are +occurring and you want to update the master rather than a slave. If the master +is in the list as a backup for reading, you might have a global setting like +this: + +mysql_servers = slave1/db/name/pw:\ + slave2/db/name/pw:\ + master/db/name/pw + +In an updating lookup, you could then write: + +${lookup mysql{servers=master; UPDATE ...} } + +That query would then be sent only to the master server. If, on the other hand, +the master is not to be used for reading, and so is not present in the global +option, you can still update it by a query of this form: + +${lookup pgsql{servers=master/db/name/pw; UPDATE ...} } + + +9.24 Special MySQL features +--------------------------- + +For MySQL, an empty host name or the use of "localhost" in mysql_servers causes +a connection to the server on the local host by means of a Unix domain socket. +An alternate socket can be specified in parentheses. An option group name for +MySQL option files can be specified in square brackets; the default value is +"exim". The full syntax of each item in mysql_servers is: + +<hostname>::<port>(<socket name>)[<option group>]/<database>/<user>/<password> + +Any of the four sub-parts of the first field can be omitted. For normal use on +the local host it can be left blank or set to just "localhost". + +No database need be supplied - but if it is absent here, it must be given in +the queries. + +If a MySQL query is issued that does not request any data (an insert, update, +or delete command), the result of the lookup is the number of rows affected. + +Warning: This can be misleading. If an update does not actually change anything +(for example, setting a field to the value it already has), the result is zero +because no rows are affected. + + +9.25 Special PostgreSQL features +-------------------------------- + +PostgreSQL lookups can also use Unix domain socket connections to the database. +This is usually faster and costs less CPU time than a TCP/IP connection. +However it can be used only if the mail server runs on the same machine as the +database server. A configuration line for PostgreSQL via Unix domain sockets +looks like this: + +hide pgsql_servers = (/tmp/.s.PGSQL.5432)/db/user/password : ... + +In other words, instead of supplying a host name, a path to the socket is +given. The path name is enclosed in parentheses so that its slashes aren't +visually confused with the delimiters for the other server parameters. + +If a PostgreSQL query is issued that does not request any data (an insert, +update, or delete command), the result of the lookup is the number of rows +affected. + + +9.26 More about SQLite +---------------------- + +SQLite is different to the other SQL lookups because a filename is required in +addition to the SQL query. An SQLite database is a single file, and there is no +daemon as in the other SQL databases. The interface to Exim requires the name +of the file, as an absolute path, to be given at the start of the query. It is +separated from the query by white space. This means that the path name cannot +contain white space. Here is a lookup expansion example: + +${lookup sqlite {/some/thing/sqlitedb \ + select name from aliases where id='userx';}} + +In a list, the syntax is similar. For example: + +domainlist relay_to_domains = sqlite;/some/thing/sqlitedb \ + select * from relays where ip='$sender_host_address'; + +The only character affected by the quote_sqlite operator is a single quote, +which it doubles. + +The SQLite library handles multiple simultaneous accesses to the database +internally. Multiple readers are permitted, but only one process can update at +once. Attempts to access the database while it is being updated are rejected +after a timeout period, during which the SQLite library waits for the lock to +be released. In Exim, the default timeout is set to 5 seconds, but it can be +changed by means of the sqlite_lock_timeout option. + + +9.27 More about Redis +--------------------- + +Redis is a non-SQL database. Commands are simple get and set. Examples: + +${lookup redis{set keyname ${quote_redis:objvalue plus}}} +${lookup redis{get keyname}} + +As of release 4.91, "lightweight" support for Redis Cluster is available. +Requires redis_servers list to contain all the servers in the cluster, all of +which must be reachable from the running exim instance. If the cluster has +master/slave replication, the list must contain all the master and slave +servers. + +When the Redis Cluster returns a "MOVED" response to a query, Exim does not +immediately follow the redirection but treats the response as a DEFER, moving +on to the next server in the redis_servers list until the correct server is +reached. + + + +=============================================================================== +10. DOMAIN, HOST, ADDRESS, AND LOCAL PART LISTS + +A number of Exim configuration options contain lists of domains, hosts, email +addresses, or local parts. For example, the hold_domains option contains a list +of domains whose delivery is currently suspended. These lists are also used as +data in ACL statements (see chapter 43), and as arguments to expansion +conditions such as match_domain. + +Each item in one of these lists is a pattern to be matched against a domain, +host, email address, or local part, respectively. In the sections below, the +different types of pattern for each case are described, but first we cover some +general facilities that apply to all four kinds of list. + +Note that other parts of Exim use a string list which does not support all the +complexity available in domain, host, address and local part lists. + + +10.1 Expansion of lists +----------------------- + +Each list is expanded as a single string before it is used. + +Exception: the router headers_remove option, where list-item splitting is done +before string-expansion. + +The result of expansion must be a list, possibly containing empty items, which +is split up into separate items for matching. By default, colon is the +separator character, but this can be varied if necessary. See sections 6.20 and +6.22 for details of the list syntax; the second of these discusses the way to +specify empty list items. + +If the string expansion is forced to fail, Exim behaves as if the item it is +testing (domain, host, address, or local part) is not in the list. Other +expansion failures cause temporary errors. + +If an item in a list is a regular expression, backslashes, dollars and possibly +other special characters in the expression must be protected against +misinterpretation by the string expander. The easiest way to do this is to use +the "\N" expansion feature to indicate that the contents of the regular +expression should not be expanded. For example, in an ACL you might have: + +deny senders = \N^\d{8}\w@.*\.baddomain\.example$\N : \ + ${lookup{$domain}lsearch{/badsenders/bydomain}} + +The first item is a regular expression that is protected from expansion by "\ +N", whereas the second uses the expansion to obtain a list of unwanted senders +based on the receiving domain. + + +10.2 Negated items in lists +--------------------------- + +Items in a list may be positive or negative. Negative items are indicated by a +leading exclamation mark, which may be followed by optional white space. A list +defines a set of items (domains, etc). When Exim processes one of these lists, +it is trying to find out whether a domain, host, address, or local part +(respectively) is in the set that is defined by the list. It works like this: + +The list is scanned from left to right. If a positive item is matched, the +subject that is being checked is in the set; if a negative item is matched, the +subject is not in the set. If the end of the list is reached without the +subject having matched any of the patterns, it is in the set if the last item +was a negative one, but not if it was a positive one. For example, the list in + +domainlist relay_to_domains = !a.b.c : *.b.c + +matches any domain ending in .b.c except for a.b.c. Domains that match neither +a.b.c nor *.b.c do not match, because the last item in the list is positive. +However, if the setting were + +domainlist relay_to_domains = !a.b.c + +then all domains other than a.b.c would match because the last item in the list +is negative. In other words, a list that ends with a negative item behaves as +if it had an extra item ":*" on the end. + +Another way of thinking about positive and negative items in lists is to read +the connector as "or" after a positive item and as "and" after a negative item. + + +10.3 File names in lists +------------------------ + +If an item in a domain, host, address, or local part list is an absolute +filename (beginning with a slash character), each line of the file is read and +processed as if it were an independent item in the list, except that further +filenames are not allowed, and no expansion of the data from the file takes +place. Empty lines in the file are ignored, and the file may also contain +comment lines: + + * For domain and host lists, if a # character appears anywhere in a line of + the file, it and all following characters are ignored. + + * Because local parts may legitimately contain # characters, a comment in an + address list or local part list file is recognized only if # is preceded by + white space or the start of the line. For example: + + not#comment@x.y.z # but this is a comment + +Putting a filename in a list has the same effect as inserting each line of the +file as an item in the list (blank lines and comments excepted). However, there +is one important difference: the file is read each time the list is processed, +so if its contents vary over time, Exim's behaviour changes. + +If a filename is preceded by an exclamation mark, the sense of any match within +the file is inverted. For example, if + +hold_domains = !/etc/nohold-domains + +and the file contains the lines + +!a.b.c +*.b.c + +then a.b.c is in the set of domains defined by hold_domains, whereas any domain +matching "*.b.c" is not. + + +10.4 An lsearch file is not an out-of-line list +----------------------------------------------- + +As will be described in the sections that follow, lookups can be used in lists +to provide indexed methods of checking list membership. There has been some +confusion about the way lsearch lookups work in lists. Because an lsearch file +contains plain text and is scanned sequentially, it is sometimes thought that +it is allowed to contain wild cards and other kinds of non-constant pattern. +This is not the case. The keys in an lsearch file are always fixed strings, +just as for any other single-key lookup type. + +If you want to use a file to contain wild-card patterns that form part of a +list, just give the filename on its own, without a search type, as described in +the previous section. You could also use the wildlsearch or nwildlsearch, but +there is no advantage in doing this. + + +10.5 Named lists +---------------- + +A list of domains, hosts, email addresses, or local parts can be given a name +which is then used to refer to the list elsewhere in the configuration. This is +particularly convenient if the same list is required in several different +places. It also allows lists to be given meaningful names, which can improve +the readability of the configuration. For example, it is conventional to define +a domain list called local_domains for all the domains that are handled locally +on a host, using a configuration line such as + +domainlist local_domains = localhost:my.dom.example + +Named lists are referenced by giving their name preceded by a plus sign, so, +for example, a router that is intended to handle local domains would be +configured with the line + +domains = +local_domains + +The first router in a configuration is often one that handles all domains +except the local ones, using a configuration with a negated item like this: + +dnslookup: + driver = dnslookup + domains = ! +local_domains + transport = remote_smtp + no_more + +The four kinds of named list are created by configuration lines starting with +the words domainlist, hostlist, addresslist, or localpartlist, respectively. +Then there follows the name that you are defining, followed by an equals sign +and the list itself. For example: + +hostlist relay_from_hosts = 192.168.23.0/24 : my.friend.example +addresslist bad_senders = cdb;/etc/badsenders + +A named list may refer to other named lists: + +domainlist dom1 = first.example : second.example +domainlist dom2 = +dom1 : third.example +domainlist dom3 = fourth.example : +dom2 : fifth.example + +Warning: If the last item in a referenced list is a negative one, the effect +may not be what you intended, because the negation does not propagate out to +the higher level. For example, consider: + +domainlist dom1 = !a.b +domainlist dom2 = +dom1 : *.b + +The second list specifies "either in the dom1 list or *.b". The first list +specifies just "not a.b", so the domain x.y matches it. That means it matches +the second list as well. The effect is not the same as + +domainlist dom2 = !a.b : *.b + +where x.y does not match. It's best to avoid negation altogether in referenced +lists if you can. + +Named lists may have a performance advantage. When Exim is routing an address +or checking an incoming message, it caches the result of tests on named lists. +So, if you have a setting such as + +domains = +local_domains + +on several of your routers or in several ACL statements, the actual test is +done only for the first one. However, the caching works only if there are no +expansions within the list itself or any sublists that it references. In other +words, caching happens only for lists that are known to be the same each time +they are referenced. + +By default, there may be up to 16 named lists of each type. This limit can be +extended by changing a compile-time variable. The use of domain and host lists +is recommended for concepts such as local domains, relay domains, and relay +hosts. The default configuration is set up like this. + + +10.6 Named lists compared with macros +------------------------------------- + +At first sight, named lists might seem to be no different from macros in the +configuration file. However, macros are just textual substitutions. If you +write + +ALIST = host1 : host2 +auth_advertise_hosts = !ALIST + +it probably won't do what you want, because that is exactly the same as + +auth_advertise_hosts = !host1 : host2 + +Notice that the second host name is not negated. However, if you use a host +list, and write + +hostlist alist = host1 : host2 +auth_advertise_hosts = ! +alist + +the negation applies to the whole list, and so that is equivalent to + +auth_advertise_hosts = !host1 : !host2 + + +10.7 Named list caching +----------------------- + +While processing a message, Exim caches the result of checking a named list if +it is sure that the list is the same each time. In practice, this means that +the cache operates only if the list contains no $ characters, which guarantees +that it will not change when it is expanded. Sometimes, however, you may have +an expanded list that you know will be the same each time within a given +message. For example: + +domainlist special_domains = \ + ${lookup{$sender_host_address}cdb{/some/file}} + +This provides a list of domains that depends only on the sending host's IP +address. If this domain list is referenced a number of times (for example, in +several ACL lines, or in several routers) the result of the check is not cached +by default, because Exim does not know that it is going to be the same list +each time. + +By appending "_cache" to "domainlist" you can tell Exim to go ahead and cache +the result anyway. For example: + +domainlist_cache special_domains = ${lookup{... + +If you do this, you should be absolutely sure that caching is going to do the +right thing in all cases. When in doubt, leave it out. + + +10.8 Domain lists +----------------- + +Domain lists contain patterns that are to be matched against a mail domain. The +following types of item may appear in domain lists: + + * If a pattern consists of a single @ character, it matches the local host + name, as set by the primary_hostname option (or defaulted). This makes it + possible to use the same configuration file on several different hosts that + differ only in their names. + + * If a pattern consists of the string "@[]" it matches an IP address enclosed + in square brackets (as in an email address that contains a domain literal), + but only if that IP address is recognized as local for email routing + purposes. The local_interfaces and extra_local_interfaces options can be + used to control which of a host's several IP addresses are treated as + local. In today's Internet, the use of domain literals is controversial. + + * If a pattern consists of the string "@mx_any" it matches any domain that + has an MX record pointing to the local host or to any host that is listed + in hosts_treat_as_local. The items "@mx_primary" and "@mx_secondary" are + similar, except that the first matches only when a primary MX target is the + local host, and the second only when no primary MX target is the local + host, but a secondary MX target is. "Primary" means an MX record with the + lowest preference value - there may of course be more than one of them. + + The MX lookup that takes place when matching a pattern of this type is + performed with the resolver options for widening names turned off. Thus, + for example, a single-component domain will not be expanded by adding the + resolver's default domain. See the qualify_single and search_parents + options of the dnslookup router for a discussion of domain widening. + + Sometimes you may want to ignore certain IP addresses when using one of + these patterns. You can specify this by following the pattern with "/ignore + ="<ip list>, where <ip list> is a list of IP addresses. These addresses are + ignored when processing the pattern (compare the ignore_target_hosts option + on a router). For example: + + domains = @mx_any/ignore=127.0.0.1 + + This example matches any domain that has an MX record pointing to one of + the local host's IP addresses other than 127.0.0.1. + + The list of IP addresses is in fact processed by the same code that + processes host lists, so it may contain CIDR-coded network specifications + and it may also contain negative items. + + Because the list of IP addresses is a sublist within a domain list, you + have to be careful about delimiters if there is more than one address. Like + any other list, the default delimiter can be changed. Thus, you might have: + + domains = @mx_any/ignore=<;127.0.0.1;0.0.0.0 : \ + an.other.domain : ... + + so that the sublist uses semicolons for delimiters. When IPv6 addresses are + involved, it is easiest to change the delimiter for the main list as well: + + domains = <? @mx_any/ignore=<;127.0.0.1;::1 ? \ + an.other.domain ? ... + + * If a pattern starts with an asterisk, the remaining characters of the + pattern are compared with the terminating characters of the domain. The use + of "*" in domain lists differs from its use in partial matching lookups. In + a domain list, the character following the asterisk need not be a dot, + whereas partial matching works only in terms of dot-separated components. + For example, a domain list item such as "*key.ex" matches donkey.ex as well + as cipher.key.ex. + + * If a pattern starts with a circumflex character, it is treated as a regular + expression, and matched against the domain using a regular expression + matching function. The circumflex is treated as part of the regular + expression. Email domains are case-independent, so this regular expression + match is by default case-independent, but you can make it case-dependent by + starting it with "(?-i)". References to descriptions of the syntax of + regular expressions are given in chapter 8. + + Warning: Because domain lists are expanded before being processed, you must + escape any backslash and dollar characters in the regular expression, or + use the special "\N" sequence (see chapter 11) to specify that it is not to + be expanded (unless you really do want to build a regular expression by + expansion, of course). + + * If a pattern starts with the name of a single-key lookup type followed by a + semicolon (for example, "dbm;" or "lsearch;"), the remainder of the pattern + must be a filename in a suitable format for the lookup type. For example, + for "cdb;" it must be an absolute path: + + domains = cdb;/etc/mail/local_domains.cdb + + The appropriate type of lookup is done on the file using the domain name as + the key. In most cases, the data that is looked up is not used; Exim is + interested only in whether or not the key is present in the file. However, + when a lookup is used for the domains option on a router or a domains + condition in an ACL statement, the data is preserved in the $domain_data + variable and can be referred to in other router options or other statements + in the same ACL. + + * Any of the single-key lookup type names may be preceded by "partial"<n>"-", + where the <n> is optional, for example, + + domains = partial-dbm;/partial/domains + + This causes partial matching logic to be invoked; a description of how this + works is given in section 9.7. + + * Any of the single-key lookup types may be followed by an asterisk. This + causes a default lookup for a key consisting of a single asterisk to be + done if the original lookup fails. This is not a useful feature when using + a domain list to select particular domains (because any domain would + match), but it might have value if the result of the lookup is being used + via the $domain_data expansion variable. + + * If the pattern starts with the name of a query-style lookup type followed + by a semicolon (for example, "nisplus;" or "ldap;"), the remainder of the + pattern must be an appropriate query for the lookup type, as described in + chapter 9. For example: + + hold_domains = mysql;select domain from holdlist \ + where domain = '${quote_mysql:$domain}'; + + In most cases, the data that is looked up is not used (so for an SQL query, + for example, it doesn't matter what field you select). Exim is interested + only in whether or not the query succeeds. However, when a lookup is used + for the domains option on a router, the data is preserved in the + $domain_data variable and can be referred to in other options. + + * If none of the above cases apply, a caseless textual comparison is made + between the pattern and the domain. + +Here is an example that uses several different kinds of pattern: + +domainlist funny_domains = \ + @ : \ + lib.unseen.edu : \ + *.foundation.fict.example : \ + \N^[1-2]\d{3}\.fict\.example$\N : \ + partial-dbm;/opt/data/penguin/book : \ + nis;domains.byname : \ + nisplus;[name=$domain,status=local],domains.org_dir + +There are obvious processing trade-offs among the various matching modes. Using +an asterisk is faster than a regular expression, and listing a few names +explicitly probably is too. The use of a file or database lookup is expensive, +but may be the only option if hundreds of names are required. Because the +patterns are tested in order, it makes sense to put the most commonly matched +patterns earlier. + + +10.9 Host lists +--------------- + +Host lists are used to control what remote hosts are allowed to do. For +example, some hosts may be allowed to use the local host as a relay, and some +may be permitted to use the SMTP ETRN command. Hosts can be identified in two +different ways, by name or by IP address. In a host list, some types of pattern +are matched to a host name, and some are matched to an IP address. You need to +be particularly careful with this when single-key lookups are involved, to +ensure that the right value is being used as the key. + + +10.10 Special host list patterns +-------------------------------- + +If a host list item is the empty string, it matches only when no remote host is +involved. This is the case when a message is being received from a local +process using SMTP on the standard input, that is, when a TCP/IP connection is +not used. + +The special pattern "*" in a host list matches any host or no host. Neither the +IP address nor the name is actually inspected. + + +10.11 Host list patterns that match by IP address +------------------------------------------------- + +If an IPv4 host calls an IPv6 host and the call is accepted on an IPv6 socket, +the incoming address actually appears in the IPv6 host as "::ffff:"<v4address>. +When such an address is tested against a host list, it is converted into a +traditional IPv4 address first. (Not all operating systems accept IPv4 calls on +IPv6 sockets, as there have been some security concerns.) + +The following types of pattern in a host list check the remote host by +inspecting its IP address: + + * If the pattern is a plain domain name (not a regular expression, not + starting with *, not a lookup of any kind), Exim calls the operating system + function to find the associated IP address(es). Exim uses the newer + getipnodebyname() function when available, otherwise gethostbyname(). This + typically causes a forward DNS lookup of the name. The result is compared + with the IP address of the subject host. + + If there is a temporary problem (such as a DNS timeout) with the host name + lookup, a temporary error occurs. For example, if the list is being used in + an ACL condition, the ACL gives a "defer" response, usually leading to a + temporary SMTP error code. If no IP address can be found for the host name, + what happens is described in section 10.14 below. + + * If the pattern is "@", the primary host name is substituted and used as a + domain name, as just described. + + * If the pattern is an IP address, it is matched against the IP address of + the subject host. IPv4 addresses are given in the normal "dotted-quad" + notation. IPv6 addresses can be given in colon-separated format, but the + colons have to be doubled so as not to be taken as item separators when the + default list separator is used. IPv6 addresses are recognized even when + Exim is compiled without IPv6 support. This means that if they appear in a + host list on an IPv4-only host, Exim will not treat them as host names. + They are just addresses that can never match a client host. + + * If the pattern is "@[]", it matches the IP address of any IP interface on + the local host. For example, if the local host is an IPv4 host with one + interface address 10.45.23.56, these two ACL statements have the same + effect: + + accept hosts = 127.0.0.1 : 10.45.23.56 + accept hosts = @[] + + * If the pattern is an IP address followed by a slash and a mask length (for + example 10.11.42.0/24), it is matched against the IP address of the subject + host under the given mask. This allows, an entire network of hosts to be + included (or excluded) by a single item. The mask uses CIDR notation; it + specifies the number of address bits that must match, starting from the + most significant end of the address. + + Note: The mask is not a count of addresses, nor is it the high number of a + range of addresses. It is the number of bits in the network portion of the + address. The above example specifies a 24-bit netmask, so it matches all + 256 addresses in the 10.11.42.0 network. An item such as + + 192.168.23.236/31 + + matches just two addresses, 192.168.23.236 and 192.168.23.237. A mask value + of 32 for an IPv4 address is the same as no mask at all; just a single + address matches. + + Here is another example which shows an IPv4 and an IPv6 network: + + recipient_unqualified_hosts = 192.168.0.0/16: \ + 3ffe::ffff::836f::::/48 + + The doubling of list separator characters applies only when these items + appear inline in a host list. It is not required when indirecting via a + file. For example: + + recipient_unqualified_hosts = /opt/exim/unqualnets + + could make use of a file containing + + 172.16.0.0/12 + 3ffe:ffff:836f::/48 + + to have exactly the same effect as the previous example. When listing IPv6 + addresses inline, it is usually more convenient to use the facility for + changing separator characters. This list contains the same two networks: + + recipient_unqualified_hosts = <; 172.16.0.0/12; \ + 3ffe:ffff:836f::/48 + + The separator is changed to semicolon by the leading "<;" at the start of + the list. + + +10.12 Host list patterns for single-key lookups by host address +--------------------------------------------------------------- + +When a host is to be identified by a single-key lookup of its complete IP +address, the pattern takes this form: + +net-<single-key-search-type>;<search-data> + +For example: + +hosts_lookup = net-cdb;/hosts-by-ip.db + +The text form of the IP address of the subject host is used as the lookup key. +IPv6 addresses are converted to an unabbreviated form, using lower case +letters, with dots as separators because colon is the key terminator in lsearch +files. [Colons can in fact be used in keys in lsearch files by quoting the +keys, but this is a facility that was added later.] The data returned by the +lookup is not used. + +Single-key lookups can also be performed using masked IP addresses, using +patterns of this form: + +net<number>-<single-key-search-type>;<search-data> + +For example: + +net24-dbm;/networks.db + +The IP address of the subject host is masked using <number> as the mask length. +A textual string is constructed from the masked value, followed by the mask, +and this is used as the lookup key. For example, if the host's IP address is +192.168.34.6, the key that is looked up for the above example is "192.168.34.0/ +24". + +When an IPv6 address is converted to a string, dots are normally used instead +of colons, so that keys in lsearch files need not contain colons (which +terminate lsearch keys). This was implemented some time before the ability to +quote keys was made available in lsearch files. However, the more recently +implemented iplsearch files do require colons in IPv6 keys (notated using the +quoting facility) so as to distinguish them from IPv4 keys. For this reason, +when the lookup type is iplsearch, IPv6 addresses are converted using colons +and not dots. In all cases, full, unabbreviated IPv6 addresses are always used. + +Ideally, it would be nice to tidy up this anomalous situation by changing to +colons in all cases, given that quoting is now available for lsearch. However, +this would be an incompatible change that might break some existing +configurations. + +Warning: Specifying net32- (for an IPv4 address) or net128- (for an IPv6 +address) is not the same as specifying just net- without a number. In the +former case the key strings include the mask value, whereas in the latter case +the IP address is used on its own. + + +10.13 Host list patterns that match by host name +------------------------------------------------ + +There are several types of pattern that require Exim to know the name of the +remote host. These are either wildcard patterns or lookups by name. (If a +complete hostname is given without any wildcarding, it is used to find an IP +address to match against, as described in section 10.11 above.) + +If the remote host name is not already known when Exim encounters one of these +patterns, it has to be found from the IP address. Although many sites on the +Internet are conscientious about maintaining reverse DNS data for their hosts, +there are also many that do not do this. Consequently, a name cannot always be +found, and this may lead to unwanted effects. Take care when configuring host +lists with wildcarded name patterns. Consider what will happen if a name cannot +be found. + +Because of the problems of determining host names from IP addresses, matching +against host names is not as common as matching against IP addresses. + +By default, in order to find a host name, Exim first does a reverse DNS lookup; +if no name is found in the DNS, the system function (gethostbyaddr() or +getipnodebyaddr() if available) is tried. The order in which these lookups are +done can be changed by setting the host_lookup_order option. For security, once +Exim has found one or more names, it looks up the IP addresses for these names +and compares them with the IP address that it started with. Only those names +whose IP addresses match are accepted. Any other names are discarded. If no +names are left, Exim behaves as if the host name cannot be found. In the most +common case there is only one name and one IP address. + +There are some options that control what happens if a host name cannot be +found. These are described in section 10.14 below. + +As a result of aliasing, hosts may have more than one name. When processing any +of the following types of pattern, all the host's names are checked: + + * If a pattern starts with "*" the remainder of the item must match the end + of the host name. For example, "*.b.c" matches all hosts whose names end in + .b.c. This special simple form is provided because this is a very common + requirement. Other kinds of wildcarding require the use of a regular + expression. + + * If the item starts with "^" it is taken to be a regular expression which is + matched against the host name. Host names are case-independent, so this + regular expression match is by default case-independent, but you can make + it case-dependent by starting it with "(?-i)". References to descriptions + of the syntax of regular expressions are given in chapter 8. For example, + + ^(a|b)\.c\.d$ + + is a regular expression that matches either of the two hosts a.c.d or b.c.d + . When a regular expression is used in a host list, you must take care that + backslash and dollar characters are not misinterpreted as part of the + string expansion. The simplest way to do this is to use "\N" to mark that + part of the string as non-expandable. For example: + + sender_unqualified_hosts = \N^(a|b)\.c\.d$\N : .... + + Warning: If you want to match a complete host name, you must include the + "$" terminating metacharacter in the regular expression, as in the above + example. Without it, a match at the start of the host name is all that is + required. + + +10.14 Behaviour when an IP address or name cannot be found +---------------------------------------------------------- + +While processing a host list, Exim may need to look up an IP address from a +name (see section 10.11), or it may need to look up a host name from an IP +address (see section 10.13). In either case, the behaviour when it fails to +find the information it is seeking is the same. + +Note: This section applies to permanent lookup failures. It does not apply to +temporary DNS errors, whose handling is described in the next section. + +Exim parses a host list from left to right. If it encounters a permanent lookup +failure in any item in the host list before it has found a match, Exim treats +it as a failure and the default behavior is as if the host does not match the +list. This may not always be what you want to happen. To change Exim's +behaviour, the special items "+include_unknown" or "+ignore_unknown" may appear +in the list (at top level - they are not recognized in an indirected file). + + * If any item that follows "+include_unknown" requires information that + cannot found, Exim behaves as if the host does match the list. For example, + + host_reject_connection = +include_unknown:*.enemy.ex + + rejects connections from any host whose name matches "*.enemy.ex", and also + any hosts whose name it cannot find. + + * If any item that follows "+ignore_unknown" requires information that cannot + be found, Exim ignores that item and proceeds to the rest of the list. For + example: + + accept hosts = +ignore_unknown : friend.example : \ + 192.168.4.5 + + accepts from any host whose name is friend.example and from 192.168.4.5, + whether or not its host name can be found. Without "+ignore_unknown", if no + name can be found for 192.168.4.5, it is rejected. + +Both "+include_unknown" and "+ignore_unknown" may appear in the same list. The +effect of each one lasts until the next, or until the end of the list. + + +10.15 Mixing wildcarded host names and addresses in host lists +-------------------------------------------------------------- + +This section explains the host/ip processing logic with the same concepts as +the previous section, but specifically addresses what happens when a wildcarded +hostname is one of the items in the hostlist. + + * If you have name lookups or wildcarded host names and IP addresses in the + same host list, you should normally put the IP addresses first. For + example, in an ACL you could have: + + accept hosts = 10.9.8.7 : *.friend.example + + The reason you normally would order it this way lies in the left-to-right + way that Exim processes lists. It can test IP addresses without doing any + DNS lookups, but when it reaches an item that requires a host name, it + fails if it cannot find a host name to compare with the pattern. If the + above list is given in the opposite order, the accept statement fails for a + host whose name cannot be found, even if its IP address is 10.9.8.7. + + * If you really do want to do the name check first, and still recognize the + IP address, you can rewrite the ACL like this: + + accept hosts = *.friend.example + accept hosts = 10.9.8.7 + + If the first accept fails, Exim goes on to try the second one. See chapter + 43 for details of ACLs. Alternatively, you can use "+ignore_unknown", which + was discussed in depth in the first example in this section. + + +10.16 Temporary DNS errors when looking up host information +----------------------------------------------------------- + +A temporary DNS lookup failure normally causes a defer action (except when +dns_again_means_nonexist converts it into a permanent error). However, host +lists can include "+ignore_defer" and "+include_defer", analogous to +"+ignore_unknown" and "+include_unknown", as described in the previous section. +These options should be used with care, probably only in non-critical host +lists such as whitelists. + + +10.17 Host list patterns for single-key lookups by host name +------------------------------------------------------------ + +If a pattern is of the form + +<single-key-search-type>;<search-data> + +for example + +dbm;/host/accept/list + +a single-key lookup is performed, using the host name as its key. If the lookup +succeeds, the host matches the item. The actual data that is looked up is not +used. + +Reminder: With this kind of pattern, you must have host names as keys in the +file, not IP addresses. If you want to do lookups based on IP addresses, you +must precede the search type with "net-" (see section 10.12). There is, +however, no reason why you could not use two items in the same list, one doing +an address lookup and one doing a name lookup, both using the same file. + + +10.18 Host list patterns for query-style lookups +------------------------------------------------ + +If a pattern is of the form + +<query-style-search-type>;<query> + +the query is obeyed, and if it succeeds, the host matches the item. The actual +data that is looked up is not used. The variables $sender_host_address and +$sender_host_name can be used in the query. For example: + +hosts_lookup = pgsql;\ + select ip from hostlist where ip='$sender_host_address' + +The value of $sender_host_address for an IPv6 address contains colons. You can +use the sg expansion item to change this if you need to. If you want to use +masked IP addresses in database queries, you can use the mask expansion +operator. + +If the query contains a reference to $sender_host_name, Exim automatically +looks up the host name if it has not already done so. (See section 10.13 for +comments on finding host names.) + +Historical note: prior to release 4.30, Exim would always attempt to find a +host name before running the query, unless the search type was preceded by +"net-". This is no longer the case. For backwards compatibility, "net-" is +still recognized for query-style lookups, but its presence or absence has no +effect. (Of course, for single-key lookups, "net-" is important. See section +10.12.) + + +10.19 Address lists +------------------- + +Address lists contain patterns that are matched against mail addresses. There +is one special case to be considered: the sender address of a bounce message is +always empty. You can test for this by providing an empty item in an address +list. For example, you can set up a router to process bounce messages by using +this option setting: + +senders = : + +The presence of the colon creates an empty item. If you do not provide any +data, the list is empty and matches nothing. The empty sender can also be +detected by a regular expression that matches an empty string, and by a +query-style lookup that succeeds when $sender_address is empty. + +Non-empty items in an address list can be straightforward email addresses. For +example: + +senders = jbc@askone.example : hs@anacreon.example + +A certain amount of wildcarding is permitted. If a pattern contains an @ +character, but is not a regular expression and does not begin with a +semicolon-terminated lookup type (described below), the local part of the +subject address is compared with the local part of the pattern, which may start +with an asterisk. If the local parts match, the domain is checked in exactly +the same way as for a pattern in a domain list. For example, the domain can be +wildcarded, refer to a named list, or be a lookup: + +deny senders = *@*.spamming.site:\ + *@+hostile_domains:\ + bozo@partial-lsearch;/list/of/dodgy/sites:\ + *@dbm;/bad/domains.db + +If a local part that begins with an exclamation mark is required, it has to be +specified using a regular expression, because otherwise the exclamation mark is +treated as a sign of negation, as is standard in lists. + +If a non-empty pattern that is not a regular expression or a lookup does not +contain an @ character, it is matched against the domain part of the subject +address. The only two formats that are recognized this way are a literal +domain, or a domain pattern that starts with *. In both these cases, the effect +is the same as if "*@" preceded the pattern. For example: + +deny senders = enemy.domain : *.enemy.domain + +The following kinds of more complicated address list pattern can match any +address, including the empty address that is characteristic of bounce message +senders: + + * If (after expansion) a pattern starts with "^", a regular expression match + is done against the complete address, with the pattern as the regular + expression. You must take care that backslash and dollar characters are not + misinterpreted as part of the string expansion. The simplest way to do this + is to use "\N" to mark that part of the string as non-expandable. For + example: + + deny senders = \N^.*this.*@example\.com$\N : \ + \N^\d{8}.+@spamhaus.example$\N : ... + + The "\N" sequences are removed by the expansion, so these items do indeed + start with "^" by the time they are being interpreted as address patterns. + + * Complete addresses can be looked up by using a pattern that starts with a + lookup type terminated by a semicolon, followed by the data for the lookup. + For example: + + deny senders = cdb;/etc/blocked.senders : \ + mysql;select address from blocked where \ + address='${quote_mysql:$sender_address}' + + Both query-style and single-key lookup types can be used. For a single-key + lookup type, Exim uses the complete address as the key. However, empty keys + are not supported for single-key lookups, so a match against the empty + address always fails. This restriction does not apply to query-style + lookups. + + Partial matching for single-key lookups (section 9.7) cannot be used, and + is ignored if specified, with an entry being written to the panic log. + However, you can configure lookup defaults, as described in section 9.6, + but this is useful only for the "*@" type of default. For example, with + this lookup: + + accept senders = lsearch*@;/some/file + + the file could contains lines like this: + + user1@domain1.example + *@domain2.example + + and for the sender address nimrod@jaeger.example, the sequence of keys that + are tried is: + + nimrod@jaeger.example + *@jaeger.example + * + + Warning 1: Do not include a line keyed by "*" in the file, because that + would mean that every address matches, thus rendering the test useless. + + Warning 2: Do not confuse these two kinds of item: + + deny recipients = dbm*@;/some/file + deny recipients = *@dbm;/some/file + + The first does a whole address lookup, with defaulting, as just described, + because it starts with a lookup type. The second matches the local part and + domain independently, as described in a bullet point below. + +The following kinds of address list pattern can match only non-empty addresses. +If the subject address is empty, a match against any of these pattern types +always fails. + + * If a pattern starts with "@@" followed by a single-key lookup item (for + example, "@@lsearch;/some/file"), the address that is being checked is + split into a local part and a domain. The domain is looked up in the file. + If it is not found, there is no match. If it is found, the data that is + looked up from the file is treated as a colon-separated list of local part + patterns, each of which is matched against the subject local part in turn. + + The lookup may be a partial one, and/or one involving a search for a + default keyed by "*" (see section 9.6). The local part patterns that are + looked up can be regular expressions or begin with "*", or even be further + lookups. They may also be independently negated. For example, with + + deny senders = @@dbm;/etc/reject-by-domain + + the data from which the DBM file is built could contain lines like + + baddomain.com: !postmaster : * + + to reject all senders except postmaster from that domain. + + If a local part that actually begins with an exclamation mark is required, + it has to be specified using a regular expression. In lsearch files, an + entry may be split over several lines by indenting the second and + subsequent lines, but the separating colon must still be included at line + breaks. White space surrounding the colons is ignored. For example: + + aol.com: spammer1 : spammer2 : ^[0-9]+$ : + spammer3 : spammer4 + + As in all colon-separated lists in Exim, a colon can be included in an item + by doubling. + + If the last item in the list starts with a right angle-bracket, the + remainder of the item is taken as a new key to look up in order to obtain a + continuation list of local parts. The new key can be any sequence of + characters. Thus one might have entries like + + aol.com: spammer1 : spammer 2 : >* + xyz.com: spammer3 : >* + *: ^\d{8}$ + + in a file that was searched with @@dbm*, to specify a match for 8-digit + local parts for all domains, in addition to the specific local parts listed + for each domain. Of course, using this feature costs another lookup each + time a chain is followed, but the effort needed to maintain the data is + reduced. + + It is possible to construct loops using this facility, and in order to + catch them, the chains may be no more than fifty items long. + + * The @@<lookup> style of item can also be used with a query-style lookup, + but in this case, the chaining facility is not available. The lookup can + only return a single list of local parts. + +Warning: There is an important difference between the address list items in +these two examples: + +senders = +my_list +senders = *@+my_list + +In the first one, "my_list" is a named address list, whereas in the second +example it is a named domain list. + + +10.20 Case of letters in address lists +-------------------------------------- + +Domains in email addresses are always handled caselessly, but for local parts +case may be significant on some systems (see caseful_local_part for how Exim +deals with this when routing addresses). However, RFC 2505 (Anti-Spam +Recommendations for SMTP MTAs) suggests that matching of addresses to blocking +lists should be done in a case-independent manner. Since most address lists in +Exim are used for this kind of control, Exim attempts to do this by default. + +The domain portion of an address is always lowercased before matching it to an +address list. The local part is lowercased by default, and any string +comparisons that take place are done caselessly. This means that the data in +the address list itself, in files included as plain filenames, and in any file +that is looked up using the "@@" mechanism, can be in any case. However, the +keys in files that are looked up by a search type other than lsearch (which +works caselessly) must be in lower case, because these lookups are not +case-independent. + +To allow for the possibility of caseful address list matching, if an item in an +address list is the string "+caseful", the original case of the local part is +restored for any comparisons that follow, and string comparisons are no longer +case-independent. This does not affect the domain, which remains in lower case. +However, although independent matches on the domain alone are still performed +caselessly, regular expressions that match against an entire address become +case-sensitive after "+caseful" has been seen. + + +10.21 Local part lists +---------------------- + +Case-sensitivity in local part lists is handled in the same way as for address +lists, as just described. The "+caseful" item can be used if required. In a +setting of the local_parts option in a router with caseful_local_part set +false, the subject is lowercased and the matching is initially +case-insensitive. In this case, "+caseful" will restore case-sensitive matching +in the local part list, but not elsewhere in the router. If caseful_local_part +is set true in a router, matching in the local_parts option is case-sensitive +from the start. + +If a local part list is indirected to a file (see section 10.3), comments are +handled in the same way as address lists - they are recognized only if the # is +preceded by white space or the start of the line. Otherwise, local part lists +are matched in the same way as domain lists, except that the special items that +refer to the local host ("@", "@[]", "@mx_any", "@mx_primary", and +"@mx_secondary") are not recognized. Refer to section 10.8 for details of the +other available item types. + + + +=============================================================================== +11. STRING EXPANSIONS + +Many strings in Exim's runtime configuration are expanded before use. Some of +them are expanded every time they are used; others are expanded only once. + +When a string is being expanded it is copied verbatim from left to right except +when a dollar or backslash character is encountered. A dollar specifies the +start of a portion of the string that is interpreted and replaced as described +below in section 11.5 onwards. Backslash is used as an escape character, as +described in the following section. + +Whether a string is expanded depends upon the context. Usually this is solely +dependent upon the option for which a value is sought; in this documentation, +options for which string expansion is performed are marked with * after the +data type. ACL rules always expand strings. A couple of expansion conditions do +not expand some of the brace-delimited branches, for security reasons. + + +11.1 Literal text in expanded strings +------------------------------------- + +An uninterpreted dollar can be included in an expanded string by putting a +backslash in front of it. A backslash can be used to prevent any special +character being treated specially in an expansion, including backslash itself. +If the string appears in quotes in the configuration file, two backslashes are +required because the quotes themselves cause interpretation of backslashes when +the string is read in (see section 6.17). + +A portion of the string can specified as non-expandable by placing it between +two occurrences of "\N". This is particularly useful for protecting regular +expressions, which often contain backslashes and dollar signs. For example: + +deny senders = \N^\d{8}[a-z]@some\.site\.example$\N + +On encountering the first "\N", the expander copies subsequent characters +without interpretation until it reaches the next "\N" or the end of the string. + + +11.2 Character escape sequences in expanded strings +--------------------------------------------------- + +A backslash followed by one of the letters "n", "r", or "t" in an expanded +string is recognized as an escape sequence for the character newline, carriage +return, or tab, respectively. A backslash followed by up to three octal digits +is recognized as an octal encoding for a single character, and a backslash +followed by "x" and up to two hexadecimal digits is a hexadecimal encoding. + +These escape sequences are also recognized in quoted strings when they are read +in. Their interpretation in expansions as well is useful for unquoted strings, +and for other cases such as looked-up strings that are then expanded. + + +11.3 Testing string expansions +------------------------------ + +Many expansions can be tested by calling Exim with the -be option. This takes +the command arguments, or lines from the standard input if there are no +arguments, runs them through the string expansion code, and writes the results +to the standard output. Variables based on configuration values are set up, but +since no message is being processed, variables such as $local_part have no +value. Nevertheless the -be option can be useful for checking out file and +database lookups, and the use of expansion operators such as sg, substr and +nhash. + +Exim gives up its root privilege when it is called with the -be option, and +instead runs under the uid and gid it was called with, to prevent users from +using -be for reading files to which they do not have access. + +If you want to test expansions that include variables whose values are taken +from a message, there are two other options that can be used. The -bem option +is like -be except that it is followed by a filename. The file is read as a +message before doing the test expansions. For example: + +exim -bem /tmp/test.message '$h_subject:' + +The -Mset option is used in conjunction with -be and is followed by an Exim +message identifier. For example: + +exim -be -Mset 1GrA8W-0004WS-LQ '$recipients' + +This loads the message from Exim's spool before doing the test expansions, and +is therefore restricted to admin users. + + +11.4 Forced expansion failure +----------------------------- + +A number of expansions that are described in the following section have +alternative "true" and "false" substrings, enclosed in brace characters (which +are sometimes called "curly brackets"). Which of the two strings is used +depends on some condition that is evaluated as part of the expansion. If, +instead of a "false" substring, the word "fail" is used (not in braces), the +entire string expansion fails in a way that can be detected by the code that +requested the expansion. This is called "forced expansion failure", and its +consequences depend on the circumstances. In some cases it is no different from +any other expansion failure, but in others a different action may be taken. +Such variations are mentioned in the documentation of the option that is being +expanded. + + +11.5 Expansion items +-------------------- + +The following items are recognized in expanded strings. White space may be used +between sub-items that are keywords or substrings enclosed in braces inside an +outer set of braces, to improve readability. Warning: Within braces, white +space is significant. + +$<variable name> or ${<variable name>} + + Substitute the contents of the named variable, for example: + + $local_part + ${domain} + + The second form can be used to separate the name from subsequent + alphanumeric characters. This form (using braces) is available only for + variables; it does not apply to message headers. The names of the variables + are given in section 11.9 below. If the name of a non-existent variable is + given, the expansion fails. + +${<op>:<string>} + + The string is first itself expanded, and then the operation specified by < + op> is applied to it. For example: + + ${lc:$local_part} + + The string starts with the first character after the colon, which may be + leading white space. A list of operators is given in section 11.6 below. + The operator notation is used for simple expansion items that have just one + argument, because it reduces the number of braces and therefore makes the + string easier to understand. + +$bheader_<header name>: or $bh_<header name>: + + This item inserts "basic" header lines. It is described with the header + expansion item below. + +${acl{<name>}{<arg>}...} + + The name and zero to nine argument strings are first expanded separately. + The expanded arguments are assigned to the variables $acl_arg1 to $acl_arg9 + in order. Any unused are made empty. The variable $acl_narg is set to the + number of arguments. The named ACL (see chapter 43) is called and may use + the variables; if another acl expansion is used the values are restored + after it returns. If the ACL sets a value using a "message =" modifier and + returns accept or deny, the value becomes the result of the expansion. If + no message is set and the ACL returns accept or deny the expansion result + is an empty string. If the ACL returns defer the result is a forced-fail. + Otherwise the expansion fails. + +${authresults{<authserv-id>}} + + This item returns a string suitable for insertion as an + Authentication-Results" header line. The given <authserv-id> is included in + the result; typically this will be a domain name identifying the system + performing the authentications. Methods that might be present in the result + include: + + none + iprev + auth + spf + dkim + + Example use (as an ACL modifier): + + add_header = :at_start:${authresults {$primary_hostname}} + + This is safe even if no authentication results are available. + +${certextract{<field>}{<certificate>}{<string2>}{<string3>}} + + The <certificate> must be a variable of type certificate. The field name is + expanded and used to retrieve the relevant field from the certificate. + Supported fields are: + + version + serial_number + subject RFC4514 DN + issuer RFC4514 DN + notbefore time + notafter time + sig_algorithm + signature + subj_altname tagged list + ocsp_uri list + crl_uri list + + If the field is found, <string2> is expanded, and replaces the whole item; + otherwise <string3> is used. During the expansion of <string2> the variable + $value contains the value that has been extracted. Afterwards, it is + restored to any previous value it might have had. + + If {<string3>} is omitted, the item is replaced by an empty string if the + key is not found. If {<string2>} is also omitted, the value that was + extracted is used. + + Some field names take optional modifiers, appended and separated by commas. + + The field selectors marked as "RFC4514" above output a Distinguished Name + string which is not quite parseable by Exim as a comma-separated tagged + list (the exceptions being elements containing commas). RDN elements of a + single type may be selected by a modifier of the type label; if so the + expansion result is a list (newline-separated by default). The separator + may be changed by another modifier of a right angle-bracket followed + immediately by the new separator. Recognised RDN type labels include "CN", + "O", "OU" and "DC". + + The field selectors marked as "time" above take an optional modifier of + "int" for which the result is the number of seconds since epoch. Otherwise + the result is a human-readable string in the timezone selected by the main + "timezone" option. + + The field selectors marked as "list" above return a list, newline-separated + by default, (embedded separator characters in elements are doubled). The + separator may be changed by a modifier of a right angle-bracket followed + immediately by the new separator. + + The field selectors marked as "tagged" above prefix each list element with + a type string and an equals sign. Elements of only one type may be selected + by a modifier which is one of "dns", "uri" or "mail"; if so the element + tags are omitted. + + If not otherwise noted field values are presented in human-readable form. + +${dlfunc{<file>}{<function>}{<arg>}{<arg>}...} + + This expansion dynamically loads and then calls a locally-written C + function. This functionality is available only if Exim is compiled with + + EXPAND_DLFUNC=yes + + set in Local/Makefile. Once loaded, Exim remembers the dynamically loaded + object so that it doesn't reload the same object file in the same Exim + process (but of course Exim does start new processes frequently). + + There may be from zero to eight arguments to the function. When compiling a + local function that is to be called in this way, local_scan.h should be + included. The Exim variables and functions that are defined by that API are + also available for dynamically loaded functions. The function itself must + have the following type: + + int dlfunction(uschar **yield, int argc, uschar *argv[]) + + Where "uschar" is a typedef for "unsigned char" in local_scan.h. The + function should return one of the following values: + + "OK": Success. The string that is placed in the variable yield is put into + the expanded string that is being built. + + "FAIL": A non-forced expansion failure occurs, with the error message taken + from yield, if it is set. + + "FAIL_FORCED": A forced expansion failure occurs, with the error message + taken from yield if it is set. + + "ERROR": Same as "FAIL", except that a panic log entry is written. + + When compiling a function that is to be used in this way with gcc, you need + to add -shared to the gcc command. Also, in the Exim build-time + configuration, you must add -export-dynamic to EXTRALIBS. + +${env{<key>}{<string1>}{<string2>}} + + The key is first expanded separately, and leading and trailing white space + removed. This is then searched for as a name in the environment. If a + variable is found then its value is placed in $value and <string1> is + expanded, otherwise <string2> is expanded. + + Instead of {<string2>} the word "fail" (not in curly brackets) can appear, + for example: + + ${env{USER}{$value} fail } + + This forces an expansion failure (see section 11.4); {<string1>} must be + present for "fail" to be recognized. + + If {<string2>} is omitted an empty string is substituted on search failure. + If {<string1>} is omitted the search result is substituted on search + success. + + The environment is adjusted by the keep_environment and add_environment + main section options. + +${extract{<key>}{<string1>}{<string2>}{<string3>}} + + The key and <string1> are first expanded separately. Leading and trailing + white space is removed from the key (but not from any of the strings). The + key must not be empty and must not consist entirely of digits. The expanded + <string1> must be of the form: + + <key1> = <value1> <key2> = <value2> ... + + where the equals signs and spaces (but not both) are optional. If any of + the values contain white space, they must be enclosed in double quotes, and + any values that are enclosed in double quotes are subject to escape + processing as described in section 6.17. The expanded <string1> is searched + for the value that corresponds to the key. The search is case-insensitive. + If the key is found, <string2> is expanded, and replaces the whole item; + otherwise <string3> is used. During the expansion of <string2> the variable + $value contains the value that has been extracted. Afterwards, it is + restored to any previous value it might have had. + + If {<string3>} is omitted, the item is replaced by an empty string if the + key is not found. If {<string2>} is also omitted, the value that was + extracted is used. Thus, for example, these two expansions are identical, + and yield "2001": + + ${extract{gid}{uid=1984 gid=2001}} + ${extract{gid}{uid=1984 gid=2001}{$value}} + + Instead of {<string3>} the word "fail" (not in curly brackets) can appear, + for example: + + ${extract{Z}{A=... B=...}{$value} fail } + + This forces an expansion failure (see section 11.4); {<string2>} must be + present for "fail" to be recognized. + +${extract json{<key>}{<string1>}{<string2>}{<string3>}} + + The key and <string1> are first expanded separately. Leading and trailing + white space is removed from the key (but not from any of the strings). The + key must not be empty and must not consist entirely of digits. The expanded + <string1> must be of the form: + + { <"key1"> : <value1> , <"key2"> , <value2> ... } + + The braces, commas and colons, and the quoting of the member name are + required; the spaces are optional. Matching of the key against the member + names is done case-sensitively. + + The results of matching are handled as above. + +${extract{<number>}{<separators>}{<string1>}{<string2>}{<string3>}} + + The <number> argument must consist entirely of decimal digits, apart from + leading and trailing white space, which is ignored. This is what + distinguishes this form of extract from the previous kind. It behaves in + the same way, except that, instead of extracting a named field, it extracts + from <string1> the field whose number is given as the first argument. You + can use $value in <string2> or "fail" instead of <string3> as before. + + The fields in the string are separated by any one of the characters in the + separator string. These may include space or tab characters. The first + field is numbered one. If the number is negative, the fields are counted + from the end of the string, with the rightmost one numbered -1. If the + number given is zero, the entire string is returned. If the modulus of the + number is greater than the number of fields in the string, the result is + the expansion of <string3>, or the empty string if <string3> is not + provided. For example: + + ${extract{2}{:}{x:42:99:& Mailer::/bin/bash}} + + yields "42", and + + ${extract{-4}{:}{x:42:99:& Mailer::/bin/bash}} + + yields "99". Two successive separators mean that the field between them is + empty (for example, the fifth field above). + +${extract json{<number>}}{<string1>}{<string2>}{<string3>}} + + The <number> argument must consist entirely of decimal digits, apart from + leading and trailing white space, which is ignored. + + Field selection and result handling is as above; there is no choice of + field separator. + +${filter{<string>}{<condition>}} + + After expansion, <string> is interpreted as a list, colon-separated by + default, but the separator can be changed in the usual way (6.21). For each + item in this list, its value is place in $item, and then the condition is + evaluated. If the condition is true, $item is added to the output as an + item in a new list; if the condition is false, the item is discarded. The + separator used for the output list is the same as the one used for the + input, but a separator setting is not included in the output. For example: + + ${filter{a:b:c}{!eq{$item}{b}}} + + yields "a:c". At the end of the expansion, the value of $item is restored + to what it was before. See also the map and reduce expansion items. + +${hash{<string1>}{<string2>}{<string3>}} + + This is a textual hashing function, and was the first to be implemented in + early versions of Exim. In current releases, there are other hashing + functions (numeric, MD5, and SHA-1), which are described below. + + The first two strings, after expansion, must be numbers. Call them <m> and + <n>. If you are using fixed values for these numbers, that is, if <string1> + and <string2> do not change when they are expanded, you can use the simpler + operator notation that avoids some of the braces: + + ${hash_<n>_<m>:<string>} + + The second number is optional (in both notations). If <n> is greater than + or equal to the length of the string, the expansion item returns the + string. Otherwise it computes a new string of length <n> by applying a + hashing function to the string. The new string consists of characters taken + from the first <m> characters of the string + + abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQWRSTUVWXYZ0123456789 + + If <m> is not present the value 26 is used, so that only lower case letters + appear. For example: + + $hash{3}{monty}} yields jmg + $hash{5}{monty}} yields monty + $hash{4}{62}{monty python}} yields fbWx + +$header_<header name>: or $h_<header name>:, $bheader_<header name>: or $bh_< + header name>:, $lheader_<header name>: or $lh_<header name>: + + "$rheader_<header name>: or $rh_<header name>:" Substitute the contents of + the named message header line, for example + + $header_reply-to: + + The newline that terminates a header line is not included in the expansion, + but internal newlines (caused by splitting the header line over several + physical lines) may be present. + + The difference between the four pairs of expansions is in the way the data + in the header line is interpreted. + + + rheader gives the original "raw" content of the header line, with no + processing at all, and without the removal of leading and trailing + white space. + + + lheader gives a colon-separated list, one element per header when there + are multiple headers with a given name. Any embedded colon characters + within an element are doubled, so normal Exim list-processing + facilities can be used. The terminating newline of each element is + removed; in other respects the content is "raw". + + + bheader removes leading and trailing white space, and then decodes + base64 or quoted-printable MIME "words" within the header text, but + does no character set translation. If decoding of what looks + superficially like a MIME "word" fails, the raw string is returned. If + decoding produces a binary zero character, it is replaced by a question + mark - this is what Exim does for binary zeros that are actually + received in header lines. + + + header tries to translate the string as decoded by bheader to a + standard character set. This is an attempt to produce the same string + as would be displayed on a user's MUA. If translation fails, the + bheader string is returned. Translation is attempted only on operating + systems that support the iconv() function. This is indicated by the + compile-time macro HAVE_ICONV in a system Makefile or in Local/Makefile + . + + In a filter file, the target character set for header can be specified by a + command of the following form: + + headers charset "UTF-8" + + This command affects all references to $h_ (or $header_) expansions in + subsequently obeyed filter commands. In the absence of this command, the + target character set in a filter is taken from the setting of the + headers_charset option in the runtime configuration. The value of this + option defaults to the value of HEADERS_CHARSET in Local/Makefile. The + ultimate default is ISO-8859-1. + + Header names follow the syntax of RFC 2822, which states that they may + contain any printing characters except space and colon. Consequently, curly + brackets do not terminate header names, and should not be used to enclose + them as if they were variables. Attempting to do so causes a syntax error. + + Only header lines that are common to all copies of a message are visible to + this mechanism. These are the original header lines that are received with + the message, and any that are added by an ACL statement or by a system + filter. Header lines that are added to a particular copy of a message by a + router or transport are not accessible. + + For incoming SMTP messages, no header lines are visible in ACLs that are + obeyed before the data phase completes, because the header structure is not + set up until the message is received. They are visible in DKIM, PRDR and + DATA ACLs. Header lines that are added in a RCPT ACL (for example) are + saved until the message's incoming header lines are available, at which + point they are added. When any of the above ACLs ar running, however, + header lines added by earlier ACLs are visible. + + Upper case and lower case letters are synonymous in header names. If the + following character is white space, the terminating colon may be omitted, + but this is not recommended, because you may then forget it when it is + needed. When white space terminates the header name, this white space is + included in the expanded string. If the message does not contain the given + header, the expansion item is replaced by an empty string. (See the def + condition in section 11.7 for a means of testing for the existence of a + header.) + + If there is more than one header with the same name, they are all + concatenated to form the substitution string, up to a maximum length of + 64K. Unless rheader is being used, leading and trailing white space is + removed from each header before concatenation, and a completely empty + header is ignored. A newline character is then inserted between non-empty + headers, but there is no newline at the very end. For the header and + bheader expansion, for those headers that contain lists of addresses, a + comma is also inserted at the junctions between headers. This does not + happen for the rheader expansion. + +${hmac{<hashname>}{<secret>}{<string>}} + + This function uses cryptographic hashing (either MD5 or SHA-1) to convert a + shared secret and some text into a message authentication code, as + specified in RFC 2104. This differs from "${md5:secret_text...}" or "$ + {sha1:secret_text...}" in that the hmac step adds a signature to the + cryptographic hash, allowing for authentication that is not possible with + MD5 or SHA-1 alone. The hash name must expand to either "md5" or "sha1" at + present. For example: + + ${hmac{md5}{somesecret}{$primary_hostname $tod_log}} + + For the hostname mail.example.com and time 2002-10-17 11:30:59, this + produces: + + dd97e3ba5d1a61b5006108f8c8252953 + + As an example of how this might be used, you might put in the main part of + an Exim configuration: + + SPAMSCAN_SECRET=cohgheeLei2thahw + + In a router or a transport you could then have: + + headers_add = \ + X-Spam-Scanned: ${primary_hostname} ${message_exim_id} \ + ${hmac{md5}{SPAMSCAN_SECRET}\ + {${primary_hostname},${message_exim_id},$h_message-id:}} + + Then given a message, you can check where it was scanned by looking at the + X-Spam-Scanned: header line. If you know the secret, you can check that + this header line is authentic by recomputing the authentication code from + the host name, message ID and the Message-id: header line. This can be done + using Exim's -be option, or by other means, for example, by using the + hmac_md5_hex() function in Perl. + +${if <condition> {<string1>}{<string2>}} + + If <condition> is true, <string1> is expanded and replaces the whole item; + otherwise <string2> is used. The available conditions are described in + section 11.7 below. For example: + + ${if eq {$local_part}{postmaster} {yes}{no} } + + The second string need not be present; if it is not and the condition is + not true, the item is replaced with nothing. Alternatively, the word "fail" + may be present instead of the second string (without any curly brackets). + In this case, the expansion is forced to fail if the condition is not true + (see section 11.4). + + If both strings are omitted, the result is the string "true" if the + condition is true, and the empty string if the condition is false. This + makes it less cumbersome to write custom ACL and router conditions. For + example, instead of + + condition = ${if >{$acl_m4}{3}{true}{false}} + + you can use + + condition = ${if >{$acl_m4}{3}} + +${imapfolder{<foldername>}} + + This item converts a (possibly multilevel, or with non-ASCII characters) + folder specification to a Maildir name for filesystem use. For information + on internationalisation support see 59.2. + +${length{<string1>}{<string2>}} + + The length item is used to extract the initial portion of a string. Both + strings are expanded, and the first one must yield a number, <n>, say. If + you are using a fixed value for the number, that is, if <string1> does not + change when expanded, you can use the simpler operator notation that avoids + some of the braces: + + ${length_<n>:<string>} + + The result of this item is either the first <n> bytes or the whole of < + string2>, whichever is the shorter. Do not confuse length with strlen, + which gives the length of a string. All measurement is done in bytes and is + not UTF-8 aware. + +${listextract{<number>}{<string1>}{<string2>}{<string3>}} + + The <number> argument must consist entirely of decimal digits, apart from + an optional leading minus, and leading and trailing white space (which is + ignored). + + After expansion, <string1> is interpreted as a list, colon-separated by + default, but the separator can be changed in the usual way (6.21). + + The first field of the list is numbered one. If the number is negative, the + fields are counted from the end of the list, with the rightmost one + numbered -1. The numbered element of the list is extracted and placed in + $value, then <string2> is expanded as the result. + + If the modulus of the number is zero or greater than the number of fields + in the string, the result is the expansion of <string3>. + + For example: + + ${listextract{2}{x:42:99}} + + yields "42", and + + ${listextract{-3}{<, x,42,99,& Mailer,,/bin/bash}{result: $value}} + + yields "result: 42". + + If {<string3>} is omitted, an empty string is used for string3. If {< + string2>} is also omitted, the value that was extracted is used. You can + use "fail" instead of {<string3>} as in a string extract. + +${lookup{<key>} <search type> {<file>} {<string1>} {<string2>}} + + This is the first of one of two different types of lookup item, which are + both described in the next item. + +${lookup <search type> {<query>} {<string1>} {<string2>}} + + The two forms of lookup item specify data lookups in files and databases, + as discussed in chapter 9. The first form is used for single-key lookups, + and the second is used for query-style lookups. The <key>, <file>, and < + query> strings are expanded before use. + + If there is any white space in a lookup item which is part of a filter + command, a retry or rewrite rule, a routing rule for the manualroute + router, or any other place where white space is significant, the lookup + item must be enclosed in double quotes. The use of data lookups in users' + filter files may be locked out by the system administrator. + + If the lookup succeeds, <string1> is expanded and replaces the entire item. + During its expansion, the variable $value contains the data returned by the + lookup. Afterwards it reverts to the value it had previously (at the outer + level it is empty). If the lookup fails, <string2> is expanded and replaces + the entire item. If {<string2>} is omitted, the replacement is the empty + string on failure. If <string2> is provided, it can itself be a nested + lookup, thus providing a mechanism for looking up a default value when the + original lookup fails. + + If a nested lookup is used as part of <string1>, $value contains the data + for the outer lookup while the parameters of the second lookup are + expanded, and also while <string2> of the second lookup is expanded, should + the second lookup fail. Instead of {<string2>} the word "fail" can appear, + and in this case, if the lookup fails, the entire expansion is forced to + fail (see section 11.4). If both {<string1>} and {<string2>} are omitted, + the result is the looked up value in the case of a successful lookup, and + nothing in the case of failure. + + For single-key lookups, the string "partial" is permitted to precede the + search type in order to do partial matching, and * or *@ may follow a + search type to request default lookups if the key does not match (see + sections 9.6 and 9.7 for details). + + If a partial search is used, the variables $1 and $2 contain the wild and + non-wild parts of the key during the expansion of the replacement text. + They return to their previous values at the end of the lookup item. + + This example looks up the postmaster alias in the conventional alias file: + + ${lookup {postmaster} lsearch {/etc/aliases} {$value}} + + This example uses NIS+ to look up the full name of the user corresponding + to the local part of an address, forcing the expansion to fail if it is not + found: + + ${lookup nisplus {[name=$local_part],passwd.org_dir:gcos} \ + {$value}fail} + +${map{<string1>}{<string2>}} + + After expansion, <string1> is interpreted as a list, colon-separated by + default, but the separator can be changed in the usual way (6.21). For each + item in this list, its value is place in $item, and then <string2> is + expanded and added to the output as an item in a new list. The separator + used for the output list is the same as the one used for the input, but a + separator setting is not included in the output. For example: + + ${map{a:b:c}{[$item]}} ${map{<- x-y-z}{($item)}} + + expands to "[a]:[b]:[c] (x)-(y)-(z)". At the end of the expansion, the + value of $item is restored to what it was before. See also the filter and + reduce expansion items. + +${nhash{<string1>}{<string2>}{<string3>}} + + The three strings are expanded; the first two must yield numbers. Call them + <n> and <m>. If you are using fixed values for these numbers, that is, if < + string1> and <string2> do not change when they are expanded, you can use + the simpler operator notation that avoids some of the braces: + + ${nhash_<n>_<m>:<string>} + + The second number is optional (in both notations). If there is only one + number, the result is a number in the range 0-<n>-1. Otherwise, the string + is processed by a div/mod hash function that returns two numbers, separated + by a slash, in the ranges 0 to <n>-1 and 0 to <m>-1, respectively. For + example, + + ${nhash{8}{64}{supercalifragilisticexpialidocious}} + + returns the string "6/33". + +${perl{<subroutine>}{<arg>}{<arg>}...} + + This item is available only if Exim has been built to include an embedded + Perl interpreter. The subroutine name and the arguments are first + separately expanded, and then the Perl subroutine is called with those + arguments. No additional arguments need be given; the maximum number + permitted, including the name of the subroutine, is nine. + + The return value of the subroutine is inserted into the expanded string, + unless the return value is undef. In that case, the expansion fails in the + same way as an explicit "fail" on a lookup item. The return value is a + scalar. Whatever you return is evaluated in a scalar context. For example, + if you return the name of a Perl vector, the return value is the size of + the vector, not its contents. + + If the subroutine exits by calling Perl's die function, the expansion fails + with the error message that was passed to die. More details of the embedded + Perl facility are given in chapter 12. + + The redirect router has an option called forbid_filter_perl which locks out + the use of this expansion item in filter files. + +${prvs{<address>}{<secret>}{<keynumber>}} + + The first argument is a complete email address and the second is secret + keystring. The third argument, specifying a key number, is optional. If + absent, it defaults to 0. The result of the expansion is a prvs-signed + email address, to be typically used with the return_path option on an smtp + transport as part of a bounce address tag validation (BATV) scheme. For + more discussion and an example, see section 43.51. + +${prvscheck{<address>}{<secret>}{<string>}} + + This expansion item is the complement of the prvs item. It is used for + checking prvs-signed addresses. If the expansion of the first argument does + not yield a syntactically valid prvs-signed address, the whole item expands + to the empty string. When the first argument does expand to a syntactically + valid prvs-signed address, the second argument is expanded, with the + prvs-decoded version of the address and the key number extracted from the + address in the variables $prvscheck_address and $prvscheck_keynum, + respectively. + + These two variables can be used in the expansion of the second argument to + retrieve the secret. The validity of the prvs-signed address is then + checked against the secret. The result is stored in the variable + $prvscheck_result, which is empty for failure or "1" for success. + + The third argument is optional; if it is missing, it defaults to an empty + string. This argument is now expanded. If the result is an empty string, + the result of the expansion is the decoded version of the address. This is + the case whether or not the signature was valid. Otherwise, the result of + the expansion is the expansion of the third argument. + + All three variables can be used in the expansion of the third argument. + However, once the expansion is complete, only $prvscheck_result remains + set. For more discussion and an example, see section 43.51. + +${readfile{<file name>}{<eol string>}} + + The filename and end-of-line string are first expanded separately. The file + is then read, and its contents replace the entire item. All newline + characters in the file are replaced by the end-of-line string if it is + present. Otherwise, newlines are left in the string. String expansion is + not applied to the contents of the file. If you want this, you must wrap + the item in an expand operator. If the file cannot be read, the string + expansion fails. + + The redirect router has an option called forbid_filter_readfile which locks + out the use of this expansion item in filter files. + +${readsocket{<name>}{<request>}{<options>}{<eol string>}{<fail string>}} + + This item inserts data from a Unix domain or TCP socket into the expanded + string. The minimal way of using it uses just two arguments, as in these + examples: + + ${readsocket{/socket/name}{request string}} + ${readsocket{inet:some.host:1234}{request string}} + + For a Unix domain socket, the first substring must be the path to the + socket. For an Internet socket, the first substring must contain "inet:" + followed by a host name or IP address, followed by a colon and a port, + which can be a number or the name of a TCP port in /etc/services. An IP + address may optionally be enclosed in square brackets. This is best for + IPv6 addresses. For example: + + ${readsocket{inet:[::1]:1234}{request string}} + + Only a single host name may be given, but if looking it up yields more than + one IP address, they are each tried in turn until a connection is made. For + both kinds of socket, Exim makes a connection, writes the request string + unless it is an empty string; and no terminating NUL is ever sent) and + reads from the socket until an end-of-file is read. A timeout of 5 seconds + is applied. Additional, optional arguments extend what can be done. + Firstly, you can vary the timeout. For example: + + ${readsocket{/socket/name}{request string}{3s}} + + The third argument is a list of options, of which the first element is the + timeout and must be present if the argument is given. Further elements are + options of form name=value. Two option types is currently recognised: + shutdown and tls. The first defines whether (the default) or not a shutdown + is done on the connection after sending the request. Example, to not do so + (preferred, eg. by some webservers): + + ${readsocket{/socket/name}{request string}{3s:shutdown=no}} + + The second, tls, controls the use of TLS on the connection. Example: + + ${readsocket{/socket/name}{request string}{3s:tls=yes}} + + The default is to not use TLS. If it is enabled, a shutdown as descripbed + above is never done. + + A fourth argument allows you to change any newlines that are in the data + that is read, in the same way as for readfile (see above). This example + turns them into spaces: + + ${readsocket{inet:127.0.0.1:3294}{request string}{3s}{ }} + + As with all expansions, the substrings are expanded before the processing + happens. Errors in these sub-expansions cause the expansion to fail. In + addition, the following errors can occur: + + + Failure to create a socket file descriptor; + + + Failure to connect the socket; + + + Failure to write the request string; + + + Timeout on reading from the socket. + + By default, any of these errors causes the expansion to fail. However, if + you supply a fifth substring, it is expanded and used when any of the above + errors occurs. For example: + + ${readsocket{/socket/name}{request string}{3s}{\n}\ + {socket failure}} + + You can test for the existence of a Unix domain socket by wrapping this + expansion in "${if exists", but there is a race condition between that test + and the actual opening of the socket, so it is safer to use the fifth + argument if you want to be absolutely sure of avoiding an expansion error + for a non-existent Unix domain socket, or a failure to connect to an + Internet socket. + + The redirect router has an option called forbid_filter_readsocket which + locks out the use of this expansion item in filter files. + +${reduce{<string1>}{<string2>}{<string3>}} + + This operation reduces a list to a single, scalar string. After expansion, + <string1> is interpreted as a list, colon-separated by default, but the + separator can be changed in the usual way (6.21). Then <string2> is + expanded and assigned to the $value variable. After this, each item in the + <string1> list is assigned to $item, in turn, and <string3> is expanded for + each of them. The result of that expansion is assigned to $value before the + next iteration. When the end of the list is reached, the final value of + $value is added to the expansion output. The reduce expansion item can be + used in a number of ways. For example, to add up a list of numbers: + + ${reduce {<, 1,2,3}{0}{${eval:$value+$item}}} + + The result of that expansion would be "6". The maximum of a list of numbers + can be found: + + ${reduce {3:0:9:4:6}{0}{${if >{$item}{$value}{$item}{$value}}}} + + At the end of a reduce expansion, the values of $item and $value are + restored to what they were before. See also the filter and map expansion + items. + +$rheader_<header name>: or $rh_<header name>: + + This item inserts "raw" header lines. It is described with the header + expansion item in section 11.5 above. + +${run{<command> <args>}{<string1>}{<string2>}} + + The command and its arguments are first expanded as one string. The string + is split apart into individual arguments by spaces, and then the command is + run in a separate process, but under the same uid and gid. As in other + command executions from Exim, a shell is not used by default. If the + command requires a shell, you must explicitly code it. + + Since the arguments are split by spaces, when there is a variable expansion + which has an empty result, it will cause the situation that the argument + will simply be omitted when the program is actually executed by Exim. If + the script/program requires a specific number of arguments and the expanded + variable could possibly result in this empty expansion, the variable must + be quoted. This is more difficult if the expanded variable itself could + result in a string containing quotes, because it would interfere with the + quotes around the command arguments. A possible guard against this is to + wrap the variable in the sg operator to change any quote marks to some + other character. + + The standard input for the command exists, but is empty. The standard + output and standard error are set to the same file descriptor. If the + command succeeds (gives a zero return code) <string1> is expanded and + replaces the entire item; during this expansion, the standard output/error + from the command is in the variable $value. If the command fails, <string2 + >, if present, is expanded and used. Once again, during the expansion, the + standard output/error from the command is in the variable $value. + + If <string2> is absent, the result is empty. Alternatively, <string2> can + be the word "fail" (not in braces) to force expansion failure if the + command does not succeed. If both strings are omitted, the result is + contents of the standard output/error on success, and nothing on failure. + + The standard output/error of the command is put in the variable $value. In + this ACL example, the output of a command is logged for the admin to + troubleshoot: + + warn condition = ${run{/usr/bin/id}{yes}{no}} + log_message = Output of id: $value + + If the command requires shell idioms, such as the > redirect operator, the + shell must be invoked directly, such as with: + + ${run{/bin/bash -c "/usr/bin/id >/tmp/id"}{yes}{yes}} + + The return code from the command is put in the variable $runrc, and this + remains set afterwards, so in a filter file you can do things like this: + + if "${run{x y z}{}}$runrc" is 1 then ... + elif $runrc is 2 then ... + ... + endif + + If execution of the command fails (for example, the command does not + exist), the return code is 127 - the same code that shells use for + non-existent commands. + + Warning: In a router or transport, you cannot assume the order in which + option values are expanded, except for those preconditions whose order of + testing is documented. Therefore, you cannot reliably expect to set $runrc + by the expansion of one option, and use it in another. + + The redirect router has an option called forbid_filter_run which locks out + the use of this expansion item in filter files. + +${sg{<subject>}{<regex>}{<replacement>}} + + This item works like Perl's substitution operator (s) with the global (/g) + option; hence its name. However, unlike the Perl equivalent, Exim does not + modify the subject string; instead it returns the modified string for + insertion into the overall expansion. The item takes three arguments: the + subject string, a regular expression, and a substitution string. For + example: + + ${sg{abcdefabcdef}{abc}{xyz}} + + yields "xyzdefxyzdef". Because all three arguments are expanded before use, + if any $, } or \ characters are required in the regular expression or in + the substitution string, they have to be escaped. For example: + + ${sg{abcdef}{^(...)(...)\$}{\$2\$1}} + + yields "defabc", and + + ${sg{1=A 4=D 3=C}{\N(\d+)=\N}{K\$1=}} + + yields "K1=A K4=D K3=C". Note the use of "\N" to protect the contents of + the regular expression from string expansion. + + The regular expression is compiled in 8-bit mode, working against bytes + rather than any Unicode-aware character handling. + +${sort{<string>}{<comparator>}{<extractor>}} + + After expansion, <string> is interpreted as a list, colon-separated by + default, but the separator can be changed in the usual way (6.21). The < + comparator> argument is interpreted as the operator of a two-argument + expansion condition. The numeric operators plus ge, gt, le, lt (and ~i + variants) are supported. The comparison should return true when applied to + two values if the first value should sort before the second value. The < + extractor> expansion is applied repeatedly to elements of the list, the + element being placed in $item, to give values for comparison. + + The item result is a sorted list, with the original list separator, of the + list elements (in full) of the original. + + Examples: + + ${sort{3:2:1:4}{<}{$item}} + + sorts a list of numbers, and + + ${sort {${lookup dnsdb{>:,,mx=example.com}}} {<} {${listextract{1}{<,$item}}}} + + will sort an MX lookup into priority order. + +${substr{<string1>}{<string2>}{<string3>}} + + The three strings are expanded; the first two must yield numbers. Call them + <n> and <m>. If you are using fixed values for these numbers, that is, if < + string1> and <string2> do not change when they are expanded, you can use + the simpler operator notation that avoids some of the braces: + + ${substr_<n>_<m>:<string>} + + The second number is optional (in both notations). If it is absent in the + simpler format, the preceding underscore must also be omitted. + + The substr item can be used to extract more general substrings than length. + The first number, <n>, is a starting offset, and <m> is the length + required. For example + + ${substr{3}{2}{$local_part}} + + If the starting offset is greater than the string length the result is the + null string; if the length plus starting offset is greater than the string + length, the result is the right-hand part of the string, starting from the + given offset. The first byte (character) in the string has offset zero. + + The substr expansion item can take negative offset values to count from the + right-hand end of its operand. The last byte (character) is offset -1, the + second-last is offset -2, and so on. Thus, for example, + + ${substr{-5}{2}{1234567}} + + yields "34". If the absolute value of a negative offset is greater than the + length of the string, the substring starts at the beginning of the string, + and the length is reduced by the amount of overshoot. Thus, for example, + + ${substr{-5}{2}{12}} + + yields an empty string, but + + ${substr{-3}{2}{12}} + + yields "1". + + When the second number is omitted from substr, the remainder of the string + is taken if the offset is positive. If it is negative, all bytes + (characters) in the string preceding the offset point are taken. For + example, an offset of -1 and no length, as in these semantically identical + examples: + + ${substr_-1:abcde} + ${substr{-1}{abcde}} + + yields all but the last character of the string, that is, "abcd". + + All measurement is done in bytes and is not UTF-8 aware. + +${tr{<subject>}{<characters>}{<replacements>}} + + This item does single-character (in bytes) translation on its subject + string. The second argument is a list of characters to be translated in the + subject string. Each matching character is replaced by the corresponding + character from the replacement list. For example + + ${tr{abcdea}{ac}{13}} + + yields "1b3de1". If there are duplicates in the second character string, + the last occurrence is used. If the third string is shorter than the + second, its last character is replicated. However, if it is empty, no + translation takes place. + + All character handling is done in bytes and is not UTF-8 aware. + + +11.6 Expansion operators +------------------------ + +For expansion items that perform transformations on a single argument string, +the "operator" notation is used because it is simpler and uses fewer braces. +The substring is first expanded before the operation is applied to it. The +following operations can be performed: + +${address:<string>} + + The string is interpreted as an RFC 2822 address, as it might appear in a + header line, and the effective address is extracted from it. If the string + does not parse successfully, the result is empty. + + The parsing correctly handles SMTPUTF8 Unicode in the string. + +${addresses:<string>} + + The string (after expansion) is interpreted as a list of addresses in RFC + 2822 format, such as can be found in a To: or Cc: header line. The + operative address (local-part@domain) is extracted from each item, and the + result of the expansion is a colon-separated list, with appropriate + doubling of colons should any happen to be present in the email addresses. + Syntactically invalid RFC2822 address items are omitted from the output. + + It is possible to specify a character other than colon for the output + separator by starting the string with > followed by the new separator + character. For example: + + ${addresses:>& Chief <ceo@up.stairs>, sec@base.ment (dogsbody)} + + expands to "ceo@up.stairs&sec@base.ment". The string is expanded first, so + if the expanded string starts with >, it may change the output separator + unintentionally. This can be avoided by setting the output separator + explicitly: + + ${addresses:>:$h_from:} + + Compare the address (singular) expansion item, which extracts the working + address from a single RFC2822 address. See the filter, map, and reduce + items for ways of processing lists. + + To clarify "list of addresses in RFC 2822 format" mentioned above, Exim + follows a strict interpretation of header line formatting. Exim parses the + bare, unquoted portion of an email address and if it finds a comma, treats + it as an email address separator. For the example header line: + + From: =?iso-8859-2?Q?Last=2C_First?= <user@example.com> + + The first example below demonstrates that Q-encoded email addresses are + parsed properly if it is given the raw header (in this example, + "$rheader_from:"). It does not see the comma because it's still encoded as + "=2C". The second example below is passed the contents of "$header_from:", + meaning it gets de-mimed. Exim sees the decoded "," so it treats it as two + email addresses. The third example shows that the presence of a comma is + skipped when it is quoted. The fourth example shows SMTPUTF8 handling. + + # exim -be '${addresses:From: \ + =?iso-8859-2?Q?Last=2C_First?= <user@example.com>}' + user@example.com + # exim -be '${addresses:From: Last, First <user@example.com>}' + Last:user@example.com + # exim -be '${addresses:From: "Last, First" <user@example.com>}' + user@example.com + # exim -be '${addresses:?????? <??????????@example.jp>}' + ??????????@example.jp + +${base32:<digits>} + + The string must consist entirely of decimal digits. The number is converted + to base 32 and output as a (empty, for zero) string of characters. Only + lowercase letters are used. + +${base32d:<base-32 digits>} + + The string must consist entirely of base-32 digits. The number is converted + to decimal and output as a string. + +${base62:<digits>} + + The string must consist entirely of decimal digits. The number is converted + to base 62 and output as a string of six characters, including leading + zeros. In the few operating environments where Exim uses base 36 instead of + base 62 for its message identifiers (because those systems do not have + case-sensitive filenames), base 36 is used by this operator, despite its + name. Note: Just to be absolutely clear: this is not base64 encoding. + +${base62d:<base-62 digits>} + + The string must consist entirely of base-62 digits, or, in operating + environments where Exim uses base 36 instead of base 62 for its message + identifiers, base-36 digits. The number is converted to decimal and output + as a string. + +${base64:<string>} + + This operator converts a string into one that is base64 encoded. + + If the string is a single variable of type certificate, returns the base64 + encoding of the DER form of the certificate. + +${base64d:<string>} + + This operator converts a base64-encoded string into the un-coded form. + +${domain:<string>} + + The string is interpreted as an RFC 2822 address and the domain is + extracted from it. If the string does not parse successfully, the result is + empty. + +${escape:<string>} + + If the string contains any non-printing characters, they are converted to + escape sequences starting with a backslash. Whether characters with the + most significant bit set (so-called "8-bit characters") count as printing + or not is controlled by the print_topbitchars option. + +${escape8bit:<string>} + + If the string contains and characters with the most significant bit set, + they are converted to escape sequences starting with a backslash. + Backslashes and DEL characters are also converted. + +${eval:<string>} and ${eval10:<string>} + + These items supports simple arithmetic and bitwise logical operations in + expansion strings. The string (after expansion) must be a conventional + arithmetic expression, but it is limited to basic arithmetic operators, + bitwise logical operators, and parentheses. All operations are carried out + using integer arithmetic. The operator priorities are as follows (the same + as in the C programming language): + + highest: not (~), negate (-) + multiply (*), divide (/), remainder (%) + plus (+), minus (-) + shift-left (<<), shift-right (>>) + and (&) + xor (^) + lowest: or (|) + + Binary operators with the same priority are evaluated from left to right. + White space is permitted before or after operators. + + For eval, numbers may be decimal, octal (starting with "0") or hexadecimal + (starting with "0x"). For eval10, all numbers are taken as decimal, even if + they start with a leading zero; hexadecimal numbers are not permitted. This + can be useful when processing numbers extracted from dates or times, which + often do have leading zeros. + + A number may be followed by "K", "M" or "G" to multiply it by 1024, + 1024*1024 or 1024*1024*1024, respectively. Negative numbers are supported. + The result of the computation is a decimal representation of the answer + (without "K", "M" or "G"). For example: + + ${eval:1+1} yields 2 + ${eval:1+2*3} yields 7 + ${eval:(1+2)*3} yields 9 + ${eval:2+42%5} yields 4 + ${eval:0xc&5} yields 4 + ${eval:0xc|5} yields 13 + ${eval:0xc^5} yields 9 + ${eval:0xc>>1} yields 6 + ${eval:0xc<<1} yields 24 + ${eval:~255&0x1234} yields 4608 + ${eval:-(~255&0x1234)} yields -4608 + + As a more realistic example, in an ACL you might have + + deny message = Too many bad recipients + condition = \ + ${if and { \ + {>{$rcpt_count}{10}} \ + { \ + < \ + {$recipients_count} \ + {${eval:$rcpt_count/2}} \ + } \ + }{yes}{no}} + + The condition is true if there have been more than 10 RCPT commands and + fewer than half of them have resulted in a valid recipient. + +${expand:<string>} + + The expand operator causes a string to be expanded for a second time. For + example, + + ${expand:${lookup{$domain}dbm{/some/file}{$value}}} + + first looks up a string in a file while expanding the operand for expand, + and then re-expands what it has found. + +${from_utf8:<string>} + + The world is slowly moving towards Unicode, although there are no standards + for email yet. However, other applications (including some databases) are + starting to store data in Unicode, using UTF-8 encoding. This operator + converts from a UTF-8 string to an ISO-8859-1 string. UTF-8 code values + greater than 255 are converted to underscores. The input must be a valid + UTF-8 string. If it is not, the result is an undefined sequence of bytes. + + Unicode code points with values less than 256 are compatible with ASCII and + ISO-8859-1 (also known as Latin-1). For example, character 169 is the + copyright symbol in both cases, though the way it is encoded is different. + In UTF-8, more than one byte is needed for characters with code values + greater than 127, whereas ISO-8859-1 is a single-byte encoding (but thereby + limited to 256 characters). This makes translation from UTF-8 to ISO-8859-1 + straightforward. + +${hash_<n>_<m>:<string>} + + The hash operator is a simpler interface to the hashing function that can + be used when the two parameters are fixed numbers (as opposed to strings + that change when expanded). The effect is the same as + + ${hash{<n>}{<m>}{<string>}} + + See the description of the general hash item above for details. The + abbreviation h can be used when hash is used as an operator. + +${hex2b64:<hexstring>} + + This operator converts a hex string into one that is base64 encoded. This + can be useful for processing the output of the various hashing functions. + +${hexquote:<string>} + + This operator converts non-printable characters in a string into a hex + escape form. Byte values between 33 (!) and 126 (~) inclusive are left as + is, and other byte values are converted to "\xNN", for example, a byte + value 127 is converted to "\x7f". + +${ipv6denorm:<string>} + + This expands an IPv6 address to a full eight-element colon-separated set of + hex digits including leading zeroes. A trailing ipv4-style dotted-decimal + set is converted to hex. Pure IPv4 addresses are converted to IPv4-mapped + IPv6. + +${ipv6norm:<string>} + + This converts an IPv6 address to canonical form. Leading zeroes of groups + are omitted, and the longest set of zero-valued groups is replaced with a + double colon. A trailing ipv4-style dotted-decimal set is converted to hex. + Pure IPv4 addresses are converted to IPv4-mapped IPv6. + +${lc:<string>} + + This forces the letters in the string into lower-case, for example: + + ${lc:$local_part} + + Case is defined per the system C locale. + +${length_<number>:<string>} + + The length operator is a simpler interface to the length function that can + be used when the parameter is a fixed number (as opposed to a string that + changes when expanded). The effect is the same as + + ${length{<number>}{<string>}} + + See the description of the general length item above for details. Note that + length is not the same as strlen. The abbreviation l can be used when + length is used as an operator. All measurement is done in bytes and is not + UTF-8 aware. + +${listcount:<string>} + + The string is interpreted as a list and the number of items is returned. + +${listnamed:<name>} and ${listnamed_<type>:<name>} + + The name is interpreted as a named list and the content of the list is + returned, expanding any referenced lists, re-quoting as needed for + colon-separation. If the optional type is given it must be one of "a", "d", + "h" or "l" and selects address-, domain-, host- or localpart- lists to + search among respectively. Otherwise all types are searched in an undefined + order and the first matching list is returned. + +${local_part:<string>} + + The string is interpreted as an RFC 2822 address and the local part is + extracted from it. If the string does not parse successfully, the result is + empty. The parsing correctly handles SMTPUTF8 Unicode in the string. + +${mask:<IP address>/<bit count>} + + If the form of the string to be operated on is not an IP address followed + by a slash and an integer (that is, a network address in CIDR notation), + the expansion fails. Otherwise, this operator converts the IP address to + binary, masks off the least significant bits according to the bit count, + and converts the result back to text, with mask appended. For example, + + ${mask:10.111.131.206/28} + + returns the string "10.111.131.192/28". Since this operation is expected to + be mostly used for looking up masked addresses in files, the result for an + IPv6 address uses dots to separate components instead of colons, because + colon terminates a key string in lsearch files. So, for example, + + ${mask:3ffe:ffff:836f:0a00:000a:0800:200a:c031/99} + + returns the string + + 3ffe.ffff.836f.0a00.000a.0800.2000.0000/99 + + Letters in IPv6 addresses are always output in lower case. + +${md5:<string>} + + The md5 operator computes the MD5 hash value of the string, and returns it + as a 32-digit hexadecimal number, in which any letters are in lower case. + + If the string is a single variable of type certificate, returns the MD5 + hash fingerprint of the certificate. + +${nhash_<n>_<m>:<string>} + + The nhash operator is a simpler interface to the numeric hashing function + that can be used when the two parameters are fixed numbers (as opposed to + strings that change when expanded). The effect is the same as + + ${nhash{<n>}{<m>}{<string>}} + + See the description of the general nhash item above for details. + +${quote:<string>} + + The quote operator puts its argument into double quotes if it is an empty + string or contains anything other than letters, digits, underscores, dots, + and hyphens. Any occurrences of double quotes and backslashes are escaped + with a backslash. Newlines and carriage returns are converted to "\n" and " + \r", respectively For example, + + ${quote:ab"*"cd} + + becomes + + "ab\"*\"cd" + + The place where this is useful is when the argument is a substitution from + a variable or a message header. + +${quote_local_part:<string>} + + This operator is like quote, except that it quotes the string only if + required to do so by the rules of RFC 2822 for quoting local parts. For + example, a plus sign would not cause quoting (but it would for quote). If + you are creating a new email address from the contents of $local_part (or + any other unknown data), you should always use this operator. + + This quoting determination is not SMTPUTF8-aware, thus quoting non-ASCII + data will likely use the quoting form. Thus ${quote_local_part:??????} will + always become "??????". + +${quote_<lookup-type>:<string>} + + This operator applies lookup-specific quoting rules to the string. Each + query-style lookup type has its own quoting rules which are described with + the lookups in chapter 9. For example, + + ${quote_ldap:two * two} + + returns + + two%20%5C2A%20two + + For single-key lookup types, no quoting is ever necessary and this operator + yields an unchanged string. + +${randint:<n>} + + This operator returns a somewhat random number which is less than the + supplied number and is at least 0. The quality of this randomness depends + on how Exim was built; the values are not suitable for keying material. If + Exim is linked against OpenSSL then RAND_pseudo_bytes() is used. If Exim is + linked against GnuTLS then gnutls_rnd(GNUTLS_RND_NONCE) is used, for + versions of GnuTLS with that function. Otherwise, the implementation may be + arc4random(), random() seeded by srandomdev() or srandom(), or a custom + implementation even weaker than random(). + +${reverse_ip:<ipaddr>} + + This operator reverses an IP address; for IPv4 addresses, the result is in + dotted-quad decimal form, while for IPv6 addresses the result is in + dotted-nibble hexadecimal form. In both cases, this is the "natural" form + for DNS. For example, + + ${reverse_ip:192.0.2.4} + ${reverse_ip:2001:0db8:c42:9:1:abcd:192.0.2.127} + + returns + + 4.2.0.192 + f.7.2.0.0.0.0.c.d.c.b.a.1.0.0.0.9.0.0.0.2.4.c.0.8.b.d.0.1.0.0.2 + +${rfc2047:<string>} + + This operator encodes text according to the rules of RFC 2047. This is an + encoding that is used in header lines to encode non-ASCII characters. It is + assumed that the input string is in the encoding specified by the + headers_charset option, which gets its default at build time. If the string + contains only characters in the range 33-126, and no instances of the + characters + + ? = ( ) < > @ , ; : \ " . [ ] _ + + it is not modified. Otherwise, the result is the RFC 2047 encoding of the + string, using as many "encoded words" as necessary to encode all the + characters. + +${rfc2047d:<string>} + + This operator decodes strings that are encoded as per RFC 2047. Binary zero + bytes are replaced by question marks. Characters are converted into the + character set defined by headers_charset. Overlong RFC 2047 "words" are not + recognized unless check_rfc2047_length is set false. + + Note: If you use $header_xxx: (or $h_xxx:) to access a header line, RFC + 2047 decoding is done automatically. You do not need to use this operator + as well. + +${rxquote:<string>} + + The rxquote operator inserts a backslash before any non-alphanumeric + characters in its argument. This is useful when substituting the values of + variables or headers inside regular expressions. + +${sha1:<string>} + + The sha1 operator computes the SHA-1 hash value of the string, and returns + it as a 40-digit hexadecimal number, in which any letters are in upper + case. + + If the string is a single variable of type certificate, returns the SHA-1 + hash fingerprint of the certificate. + +${sha256:<string>} + + The sha256 operator computes the SHA-256 hash value of the string and + returns it as a 64-digit hexadecimal number, in which any letters are in + upper case. + + If the string is a single variable of type certificate, returns the SHA-256 + hash fingerprint of the certificate. + +${sha3:<string>}, ${sha3_<n>:<string>} + + The sha3 operator computes the SHA3-256 hash value of the string and + returns it as a 64-digit hexadecimal number, in which any letters are in + upper case. + + If a number is appended, separated by an underbar, it specifies the output + length. Values of 224, 256, 384 and 512 are accepted; with 256 being the + default. + + The sha3 expansion item is only supported if Exim has been compiled with + GnuTLS 3.5.0 or later, or OpenSSL 1.1.1 or later. The macro + "_CRYPTO_HASH_SHA3" will be defined if it is supported. + +${stat:<string>} + + The string, after expansion, must be a file path. A call to the stat() + function is made for this path. If stat() fails, an error occurs and the + expansion fails. If it succeeds, the data from the stat replaces the item, + as a series of <name>=<value> pairs, where the values are all numerical, + except for the value of "smode". The names are: "mode" (giving the mode as + a 4-digit octal number), "smode" (giving the mode in symbolic format as a + 10-character string, as for the ls command), "inode", "device", "links", + "uid", "gid", "size", "atime", "mtime", and "ctime". You can extract + individual fields using the extract expansion item. + + The use of the stat expansion in users' filter files can be locked out by + the system administrator. Warning: The file size may be incorrect on 32-bit + systems for files larger than 2GB. + +${str2b64:<string>} + + Now deprecated, a synonym for the base64 expansion operator. + +${strlen:<string>} + + The item is replace by the length of the expanded string, expressed as a + decimal number. Note: Do not confuse strlen with length. All measurement is + done in bytes and is not UTF-8 aware. + +${substr_<start>_<length>:<string>} + + The substr operator is a simpler interface to the substr function that can + be used when the two parameters are fixed numbers (as opposed to strings + that change when expanded). The effect is the same as + + ${substr{<start>}{<length>}{<string>}} + + See the description of the general substr item above for details. The + abbreviation s can be used when substr is used as an operator. All + measurement is done in bytes and is not UTF-8 aware. + +${time_eval:<string>} + + This item converts an Exim time interval such as "2d4h5m" into a number of + seconds. + +${time_interval:<string>} + + The argument (after sub-expansion) must be a sequence of decimal digits + that represents an interval of time as a number of seconds. It is converted + into a number of larger units and output in Exim's normal time format, for + example, "1w3d4h2m6s". + +${uc:<string>} + + This forces the letters in the string into upper-case. Case is defined per + the system C locale. + +${utf8clean:<string>} + + This replaces any invalid utf-8 sequence in the string by the character "? + ". + + In versions of Exim before 4.92, this did not correctly do so for a + truncated final codepoint's encoding, and the character would be silently + dropped. If you must handle detection of this scenario across both sets of + Exim behavior, the complexity will depend upon the task. For instance, to + detect if the first character is multibyte and a 1-byte extraction can be + successfully used as a path component (as is common for dividing up + delivery folders), you might use: + + condition = ${if inlist{${utf8clean:${length_1:$local_part}}}{:?}{yes}{no}} + + (which will false-positive if the first character of the local part is a + literal question mark). + +${utf8_domain_to_alabel:<string>}, ${utf8_domain_from_alabel:<string>}, $ + {utf8_localpart_to_alabel:<string>}, ${utf8_localpart_from_alabel:<string>} + + These convert EAI mail name components between UTF-8 and a-label forms. For + information on internationalisation support see 59.1. + + +11.7 Expansion conditions +------------------------- + +The following conditions are available for testing by the ${if construct while +expanding strings: + +!<condition> + + Preceding any condition with an exclamation mark negates the result of the + condition. + +<symbolic operator> {<string1>}{<string2>} + + There are a number of symbolic operators for doing numeric comparisons. + They are: + + = equal + == equal + > greater + >= greater or equal + < less + <= less or equal + + For example: + + ${if >{$message_size}{10M} ... + + Note that the general negation operator provides for inequality testing. + The two strings must take the form of optionally signed decimal integers, + optionally followed by one of the letters "K", "M" or "G" (in either upper + or lower case), signifying multiplication by 1024, 1024*1024 or + 1024*1024*1024, respectively. As a special case, the numerical value of an + empty string is taken as zero. + + In all cases, a relative comparator OP is testing if <string1> OP <string2 + >; the above example is checking if $message_size is larger than 10M, not + if 10M is larger than $message_size. + +acl {{<name>}{<arg1>}{<arg2>}...} + + The name and zero to nine argument strings are first expanded separately. + The expanded arguments are assigned to the variables $acl_arg1 to $acl_arg9 + in order. Any unused are made empty. The variable $acl_narg is set to the + number of arguments. The named ACL (see chapter 43) is called and may use + the variables; if another acl expansion is used the values are restored + after it returns. If the ACL sets a value using a "message =" modifier the + variable $value becomes the result of the expansion, otherwise it is empty. + If the ACL returns accept the condition is true; if deny, false. If the ACL + returns defer the result is a forced-fail. + +bool {<string>} + + This condition turns a string holding a true or false representation into a + boolean state. It parses "true", "false", "yes" and "no" + (case-insensitively); also integer numbers map to true if non-zero, false + if zero. An empty string is treated as false. Leading and trailing + whitespace is ignored; thus a string consisting only of whitespace is + false. All other string values will result in expansion failure. + + When combined with ACL variables, this expansion condition will let you + make decisions in one place and act on those decisions in another place. + For example: + + ${if bool{$acl_m_privileged_sender} ... + +bool_lax {<string>} + + Like bool, this condition turns a string into a boolean state. But where + bool accepts a strict set of strings, bool_lax uses the same loose + definition that the Router condition option uses. The empty string and the + values "false", "no" and "0" map to false, all others map to true. Leading + and trailing whitespace is ignored. + + Note that where "bool{00}" is false, "bool_lax{00}" is true. + +crypteq {<string1>}{<string2>} + + This condition is included in the Exim binary if it is built to support any + authentication mechanisms (see chapter 33). Otherwise, it is necessary to + define SUPPORT_CRYPTEQ in Local/Makefile to get crypteq included in the + binary. + + The crypteq condition has two arguments. The first is encrypted and + compared against the second, which is already encrypted. The second string + may be in the LDAP form for storing encrypted strings, which starts with + the encryption type in curly brackets, followed by the data. If the second + string does not begin with "{" it is assumed to be encrypted with crypt() + or crypt16() (see below), since such strings cannot begin with "{". + Typically this will be a field from a password file. An example of an + encrypted string in LDAP form is: + + {md5}CY9rzUYh03PK3k6DJie09g== + + If such a string appears directly in an expansion, the curly brackets have + to be quoted, because they are part of the expansion syntax. For example: + + ${if crypteq {test}{\{md5\}CY9rzUYh03PK3k6DJie09g==}{yes}{no}} + + The following encryption types (whose names are matched case-independently) + are supported: + + + {md5} computes the MD5 digest of the first string, and expresses this + as printable characters to compare with the remainder of the second + string. If the length of the comparison string is 24, Exim assumes that + it is base64 encoded (as in the above example). If the length is 32, + Exim assumes that it is a hexadecimal encoding of the MD5 digest. If + the length not 24 or 32, the comparison fails. + + + {sha1} computes the SHA-1 digest of the first string, and expresses + this as printable characters to compare with the remainder of the + second string. If the length of the comparison string is 28, Exim + assumes that it is base64 encoded. If the length is 40, Exim assumes + that it is a hexadecimal encoding of the SHA-1 digest. If the length is + not 28 or 40, the comparison fails. + + + {crypt} calls the crypt() function, which traditionally used to use + only the first eight characters of the password. However, in modern + operating systems this is no longer true, and in many cases the entire + password is used, whatever its length. + + + {crypt16} calls the crypt16() function, which was originally created to + use up to 16 characters of the password in some operating systems. + Again, in modern operating systems, more characters may be used. + + Exim has its own version of crypt16(), which is just a double call to crypt + (). For operating systems that have their own version, setting HAVE_CRYPT16 + in Local/Makefile when building Exim causes it to use the operating system + version instead of its own. This option is set by default in the + OS-dependent Makefile for those operating systems that are known to support + crypt16(). + + Some years after Exim's crypt16() was implemented, a user discovered that + it was not using the same algorithm as some operating systems' versions. It + turns out that as well as crypt16() there is a function called bigcrypt() + in some operating systems. This may or may not use the same algorithm, and + both of them may be different to Exim's built-in crypt16(). + + However, since there is now a move away from the traditional crypt() + functions towards using SHA1 and other algorithms, tidying up this area of + Exim is seen as very low priority. + + If you do not put a encryption type (in curly brackets) in a crypteq + comparison, the default is usually either "{crypt}" or "{crypt16}", as + determined by the setting of DEFAULT_CRYPT in Local/Makefile. The default + default is "{crypt}". Whatever the default, you can always use either + function by specifying it explicitly in curly brackets. + +def:<variable name> + + The def condition must be followed by the name of one of the expansion + variables defined in section 11.9. The condition is true if the variable + does not contain the empty string. For example: + + ${if def:sender_ident {from $sender_ident}} + + Note that the variable name is given without a leading $ character. If the + variable does not exist, the expansion fails. + +def:header_<header name>: or def:h_<header name>: + + This condition is true if a message is being processed and the named header + exists in the message. For example, + + ${if def:header_reply-to:{$h_reply-to:}{$h_from:}} + + Note: No $ appears before header_ or h_ in the condition, and the header + name must be terminated by a colon if white space does not follow. + +eq {<string1>}{<string2>}, eqi {<string1>}{<string2>} + + The two substrings are first expanded. The condition is true if the two + resulting strings are identical. For eq the comparison includes the case of + letters, whereas for eqi the comparison is case-independent, where case is + defined per the system C locale. + +exists {<file name>} + + The substring is first expanded and then interpreted as an absolute path. + The condition is true if the named file (or directory) exists. The + existence test is done by calling the stat() function. The use of the + exists test in users' filter files may be locked out by the system + administrator. + +first_delivery + + This condition, which has no data, is true during a message's first + delivery attempt. It is false during any subsequent delivery attempts. + +forall{<a list>}{<a condition>}, forany{<a list>}{<a condition>} + + These conditions iterate over a list. The first argument is expanded to + form the list. By default, the list separator is a colon, but it can be + changed by the normal method (6.21). The second argument is interpreted as + a condition that is to be applied to each item in the list in turn. During + the interpretation of the condition, the current list item is placed in a + variable called $item. + + + For forany, interpretation stops if the condition is true for any item, + and the result of the whole condition is true. If the condition is + false for all items in the list, the overall condition is false. + + + For forall, interpretation stops if the condition is false for any + item, and the result of the whole condition is false. If the condition + is true for all items in the list, the overall condition is true. + + Note that negation of forany means that the condition must be false for all + items for the overall condition to succeed, and negation of forall means + that the condition must be false for at least one item. In this example, + the list separator is changed to a comma: + + ${if forany{<, $recipients}{match{$item}{^user3@}}{yes}{no}} + + The value of $item is saved and restored while forany or forall is being + processed, to enable these expansion items to be nested. + + To scan a named list, expand it with the listnamed operator. + +ge {<string1>}{<string2>}, gei {<string1>}{<string2>} + + The two substrings are first expanded. The condition is true if the first + string is lexically greater than or equal to the second string. For ge the + comparison includes the case of letters, whereas for gei the comparison is + case-independent. Case and collation order are defined per the system C + locale. + +gt {<string1>}{<string2>}, gti {<string1>}{<string2>} + + The two substrings are first expanded. The condition is true if the first + string is lexically greater than the second string. For gt the comparison + includes the case of letters, whereas for gti the comparison is + case-independent. Case and collation order are defined per the system C + locale. + +inlist {<string1>}{<string2>}, inlisti {<string1>}{<string2>} + + Both strings are expanded; the second string is treated as a list of simple + strings; if the first string is a member of the second, then the condition + is true. For the case-independent inlisti condition, case is defined per + the system C locale. + + These are simpler to use versions of the more powerful forany condition. + Examples, and the forany equivalents: + + ${if inlist{needle}{foo:needle:bar}} + ${if forany{foo:needle:bar}{eq{$item}{needle}}} + ${if inlisti{Needle}{fOo:NeeDLE:bAr}} + ${if forany{fOo:NeeDLE:bAr}{eqi{$item}{Needle}}} + +isip {<string>}, isip4 {<string>}, isip6 {<string>} + + The substring is first expanded, and then tested to see if it has the form + of an IP address. Both IPv4 and IPv6 addresses are valid for isip, whereas + isip4 and isip6 test specifically for IPv4 or IPv6 addresses. + + For an IPv4 address, the test is for four dot-separated components, each of + which consists of from one to three digits. For an IPv6 address, up to + eight colon-separated components are permitted, each containing from one to + four hexadecimal digits. There may be fewer than eight components if an + empty component (adjacent colons) is present. Only one empty component is + permitted. + + Note: The checks used to be just on the form of the address; actual + numerical values were not considered. Thus, for example, 999.999.999.999 + passed the IPv4 check. This is no longer the case. + + The main use of these tests is to distinguish between IP addresses and host + names, or between IPv4 and IPv6 addresses. For example, you could use + + ${if isip4{$sender_host_address}... + + to test which IP version an incoming SMTP connection is using. + +ldapauth {<ldap query>} + + This condition supports user authentication using LDAP. See section 9.14 + for details of how to use LDAP in lookups and the syntax of queries. For + this use, the query must contain a user name and password. The query itself + is not used, and can be empty. The condition is true if the password is not + empty, and the user name and password are accepted by the LDAP server. An + empty password is rejected without calling LDAP because LDAP binds with an + empty password are considered anonymous regardless of the username, and + will succeed in most configurations. See chapter 33 for details of SMTP + authentication, and chapter 34 for an example of how this can be used. + +le {<string1>}{<string2>}, lei {<string1>}{<string2>} + + The two substrings are first expanded. The condition is true if the first + string is lexically less than or equal to the second string. For le the + comparison includes the case of letters, whereas for lei the comparison is + case-independent. Case and collation order are defined per the system C + locale. + +lt {<string1>}{<string2>}, lti {<string1>}{<string2>} + + The two substrings are first expanded. The condition is true if the first + string is lexically less than the second string. For lt the comparison + includes the case of letters, whereas for lti the comparison is + case-independent. Case and collation order are defined per the system C + locale. + +match {<string1>}{<string2>} + + The two substrings are first expanded. The second is then treated as a + regular expression and applied to the first. Because of the pre-expansion, + if the regular expression contains dollar, or backslash characters, they + must be escaped. Care must also be taken if the regular expression contains + braces (curly brackets). A closing brace must be escaped so that it is not + taken as a premature termination of <string2>. The easiest approach is to + use the "\N" feature to disable expansion of the regular expression. For + example, + + ${if match {$local_part}{\N^\d{3}\N} ... + + If the whole expansion string is in double quotes, further escaping of + backslashes is also required. + + The condition is true if the regular expression match succeeds. The regular + expression is not required to begin with a circumflex metacharacter, but if + there is no circumflex, the expression is not anchored, and it may match + anywhere in the subject, not just at the start. If you want the pattern to + match at the end of the subject, you must include the "$" metacharacter at + an appropriate point. All character handling is done in bytes and is not + UTF-8 aware, but we might change this in a future Exim release. + + At the start of an if expansion the values of the numeric variable + substitutions $1 etc. are remembered. Obeying a match condition that + succeeds causes them to be reset to the substrings of that condition and + they will have these values during the expansion of the success string. At + the end of the if expansion, the previous values are restored. After + testing a combination of conditions using or, the subsequent values of the + numeric variables are those of the condition that succeeded. + +match_address {<string1>}{<string2>} + + See match_local_part. + +match_domain {<string1>}{<string2>} + + See match_local_part. + +match_ip {<string1>}{<string2>} + + This condition matches an IP address to a list of IP address patterns. It + must be followed by two argument strings. The first (after expansion) must + be an IP address or an empty string. The second (not expanded) is a + restricted host list that can match only an IP address, not a host name. + For example: + + ${if match_ip{$sender_host_address}{1.2.3.4:5.6.7.8}{...}{...}} + + The specific types of host list item that are permitted in the list are: + + + An IP address, optionally with a CIDR mask. + + + A single asterisk, which matches any IP address. + + + An empty item, which matches only if the IP address is empty. This + could be useful for testing for a locally submitted message or one from + specific hosts in a single test such as + + ${if match_ip{$sender_host_address}{:4.3.2.1:...}{...}{...}} + + where the first item in the list is the empty string. + + + The item @[] matches any of the local host's interface addresses. + + + Single-key lookups are assumed to be like "net-" style lookups in host + lists, even if "net-" is not specified. There is never any attempt to + turn the IP address into a host name. The most common type of linear + search for match_ip is likely to be iplsearch, in which the file can + contain CIDR masks. For example: + + ${if match_ip{$sender_host_address}{iplsearch;/some/file}... + + It is of course possible to use other kinds of lookup, and in such a + case, you do need to specify the "net-" prefix if you want to specify a + specific address mask, for example: + + ${if match_ip{$sender_host_address}{net24-dbm;/some/file}... + + However, unless you are combining a match_ip condition with others, it + is just as easy to use the fact that a lookup is itself a condition, + and write: + + ${lookup{${mask:$sender_host_address/24}}dbm{/a/file}... + + Note that <string2> is not itself subject to string expansion, unless Exim + was built with the EXPAND_LISTMATCH_RHS option. + + Consult section 10.11 for further details of these patterns. + +match_local_part {<string1>}{<string2>} + + This condition, together with match_address and match_domain, make it + possible to test domain, address, and local part lists within expansions. + Each condition requires two arguments: an item and a list to match. A + trivial example is: + + ${if match_domain{a.b.c}{x.y.z:a.b.c:p.q.r}{yes}{no}} + + In each case, the second argument may contain any of the allowable items + for a list of the appropriate type. Also, because the second argument is a + standard form of list, it is possible to refer to a named list. Thus, you + can use conditions like this: + + ${if match_domain{$domain}{+local_domains}{... + + For address lists, the matching starts off caselessly, but the "+caseful" + item can be used, as in all address lists, to cause subsequent items to + have their local parts matched casefully. Domains are always matched + caselessly. + + Note that <string2> is not itself subject to string expansion, unless Exim + was built with the EXPAND_LISTMATCH_RHS option. + + Note: Host lists are not supported in this way. This is because hosts have + two identities: a name and an IP address, and it is not clear how to + specify cleanly how such a test would work. However, IP addresses can be + matched using match_ip. + +pam {<string1>:<string2>:...} + + Pluggable Authentication Modules (https://mirrors.edge.kernel.org/pub/linux + /libs/pam/) are a facility that is available in the latest releases of + Solaris and in some GNU/Linux distributions. The Exim support, which is + intended for use in conjunction with the SMTP AUTH command, is available + only if Exim is compiled with + + SUPPORT_PAM=yes + + in Local/Makefile. You probably need to add -lpam to EXTRALIBS, and in some + releases of GNU/Linux -ldl is also needed. + + The argument string is first expanded, and the result must be a + colon-separated list of strings. Leading and trailing white space is + ignored. The PAM module is initialized with the service name "exim" and the + user name taken from the first item in the colon-separated data string (< + string1>). The remaining items in the data string are passed over in + response to requests from the authentication function. In the simple case + there will only be one request, for a password, so the data consists of + just two strings. + + There can be problems if any of the strings are permitted to contain colon + characters. In the usual way, these have to be doubled to avoid being taken + as separators. If the data is being inserted from a variable, the sg + expansion item can be used to double any existing colons. For example, the + configuration of a LOGIN authenticator might contain this setting: + + server_condition = ${if pam{$auth1:${sg{$auth2}{:}{::}}}} + + For a PLAIN authenticator you could use: + + server_condition = ${if pam{$auth2:${sg{$auth3}{:}{::}}}} + + In some operating systems, PAM authentication can be done only from a + process running as root. Since Exim is running as the Exim user when + receiving messages, this means that PAM cannot be used directly in those + systems. + +pwcheck {<string1>:<string2>} + + This condition supports user authentication using the Cyrus pwcheck daemon. + This is one way of making it possible for passwords to be checked by a + process that is not running as root. Note: The use of pwcheck is now + deprecated. Its replacement is saslauthd (see below). + + The pwcheck support is not included in Exim by default. You need to specify + the location of the pwcheck daemon's socket in Local/Makefile before + building Exim. For example: + + CYRUS_PWCHECK_SOCKET=/var/pwcheck/pwcheck + + You do not need to install the full Cyrus software suite in order to use + the pwcheck daemon. You can compile and install just the daemon alone from + the Cyrus SASL library. Ensure that exim is the only user that has access + to the /var/pwcheck directory. + + The pwcheck condition takes one argument, which must be the user name and + password, separated by a colon. For example, in a LOGIN authenticator + configuration, you might have this: + + server_condition = ${if pwcheck{$auth1:$auth2}} + + Again, for a PLAIN authenticator configuration, this would be: + + server_condition = ${if pwcheck{$auth2:$auth3}} + +queue_running + + This condition, which has no data, is true during delivery attempts that + are initiated by queue runner processes, and false otherwise. + +radius {<authentication string>} + + Radius authentication (RFC 2865) is supported in a similar way to PAM. You + must set RADIUS_CONFIG_FILE in Local/Makefile to specify the location of + the Radius client configuration file in order to build Exim with Radius + support. + + With just that one setting, Exim expects to be linked with the radiusclient + library, using the original API. If you are using release 0.4.0 or later of + this library, you need to set + + RADIUS_LIB_TYPE=RADIUSCLIENTNEW + + in Local/Makefile when building Exim. You can also link Exim with the + libradius library that comes with FreeBSD. To do this, set + + RADIUS_LIB_TYPE=RADLIB + + in Local/Makefile, in addition to setting RADIUS_CONFIGURE_FILE. You may + also have to supply a suitable setting in EXTRALIBS so that the Radius + library can be found when Exim is linked. + + The string specified by RADIUS_CONFIG_FILE is expanded and passed to the + Radius client library, which calls the Radius server. The condition is true + if the authentication is successful. For example: + + server_condition = ${if radius{<arguments>}} + +saslauthd {{<user>}{<password>}{<service>}{<realm>}} + + This condition supports user authentication using the Cyrus saslauthd + daemon. This replaces the older pwcheck daemon, which is now deprecated. + Using this daemon is one way of making it possible for passwords to be + checked by a process that is not running as root. + + The saslauthd support is not included in Exim by default. You need to + specify the location of the saslauthd daemon's socket in Local/Makefile + before building Exim. For example: + + CYRUS_SASLAUTHD_SOCKET=/var/state/saslauthd/mux + + You do not need to install the full Cyrus software suite in order to use + the saslauthd daemon. You can compile and install just the daemon alone + from the Cyrus SASL library. + + Up to four arguments can be supplied to the saslauthd condition, but only + two are mandatory. For example: + + server_condition = ${if saslauthd{{$auth1}{$auth2}}} + + The service and the realm are optional (which is why the arguments are + enclosed in their own set of braces). For details of the meaning of the + service and realm, and how to run the daemon, consult the Cyrus + documentation. + + +11.8 Combining expansion conditions +----------------------------------- + +Several conditions can be tested at once by combining them using the and and or +combination conditions. Note that and and or are complete conditions on their +own, and precede their lists of sub-conditions. Each sub-condition must be +enclosed in braces within the overall braces that contain the list. No +repetition of if is used. + +or {{<cond1>}{<cond2>}...} + + The sub-conditions are evaluated from left to right. The condition is true + if any one of the sub-conditions is true. For example, + + ${if or {{eq{$local_part}{spqr}}{eq{$domain}{testing.com}}}... + + When a true sub-condition is found, the following ones are parsed but not + evaluated. If there are several "match" sub-conditions the values of the + numeric variables afterwards are taken from the first one that succeeds. + +and {{<cond1>}{<cond2>}...} + + The sub-conditions are evaluated from left to right. The condition is true + if all of the sub-conditions are true. If there are several "match" + sub-conditions, the values of the numeric variables afterwards are taken + from the last one. When a false sub-condition is found, the following ones + are parsed but not evaluated. + + +11.9 Expansion variables +------------------------ + +This section contains an alphabetical list of all the expansion variables. Some +of them are available only when Exim is compiled with specific options such as +support for TLS or the content scanning extension. + +$0, $1, etc + + When a match expansion condition succeeds, these variables contain the + captured substrings identified by the regular expression during subsequent + processing of the success string of the containing if expansion item. In + the expansion condition case they do not retain their values afterwards; in + fact, their previous values are restored at the end of processing an if + item. The numerical variables may also be set externally by some other + matching process which precedes the expansion of the string. For example, + the commands available in Exim filter files include an if command with its + own regular expression matching condition. + +$acl_arg1, $acl_arg2, etc + + Within an acl condition, expansion condition or expansion item any + arguments are copied to these variables, any unused variables being made + empty. + +$acl_c... + + Values can be placed in these variables by the set modifier in an ACL. They + can be given any name that starts with $acl_c and is at least six + characters long, but the sixth character must be either a digit or an + underscore. For example: $acl_c5, $acl_c_mycount. The values of the + $acl_c... variables persist throughout the lifetime of an SMTP connection. + They can be used to pass information between ACLs and between different + invocations of the same ACL. When a message is received, the values of + these variables are saved with the message, and can be accessed by filters, + routers, and transports during subsequent delivery. + +$acl_m... + + These variables are like the $acl_c... variables, except that their values + are reset after a message has been received. Thus, if several messages are + received in one SMTP connection, $acl_m... values are not passed on from + one message to the next, as $acl_c... values are. The $acl_m... variables + are also reset by MAIL, RSET, EHLO, HELO, and after starting a TLS session. + When a message is received, the values of these variables are saved with + the message, and can be accessed by filters, routers, and transports during + subsequent delivery. + +$acl_narg + + Within an acl condition, expansion condition or expansion item this + variable has the number of arguments. + +$acl_verify_message + + After an address verification has failed, this variable contains the + failure message. It retains its value for use in subsequent modifiers. The + message can be preserved by coding like this: + + warn !verify = sender + set acl_m0 = $acl_verify_message + + You can use $acl_verify_message during the expansion of the message or + log_message modifiers, to include information about the verification + failure. + +$address_data + + This variable is set by means of the address_data option in routers. The + value then remains with the address while it is processed by subsequent + routers and eventually a transport. If the transport is handling multiple + addresses, the value from the first address is used. See chapter 15 for + more details. Note: The contents of $address_data are visible in user + filter files. + + If $address_data is set when the routers are called from an ACL to verify a + recipient address, the final value is still in the variable for subsequent + conditions and modifiers of the ACL statement. If routing the address + caused it to be redirected to just one address, the child address is also + routed as part of the verification, and in this case the final value of + $address_data is from the child's routing. + + If $address_data is set when the routers are called from an ACL to verify a + sender address, the final value is also preserved, but this time in + $sender_address_data, to distinguish it from data from a recipient address. + + In both cases (recipient and sender verification), the value does not + persist after the end of the current ACL statement. If you want to preserve + these values for longer, you can save them in ACL variables. + +$address_file + + When, as a result of aliasing, forwarding, or filtering, a message is + directed to a specific file, this variable holds the name of the file when + the transport is running. At other times, the variable is empty. For + example, using the default configuration, if user r2d2 has a .forward file + containing + + /home/r2d2/savemail + + then when the address_file transport is running, $address_file contains the + text string "/home/r2d2/savemail". For Sieve filters, the value may be + "inbox" or a relative folder name. It is then up to the transport + configuration to generate an appropriate absolute path to the relevant + file. + +$address_pipe + + When, as a result of aliasing or forwarding, a message is directed to a + pipe, this variable holds the pipe command when the transport is running. + +$auth1 - $auth3 + + These variables are used in SMTP authenticators (see chapters 34-41). + Elsewhere, they are empty. + +$authenticated_id + + When a server successfully authenticates a client it may be configured to + preserve some of the authentication information in the variable + $authenticated_id (see chapter 33). For example, a user/password + authenticator configuration might preserve the user name for use in the + routers. Note that this is not the same information that is saved in + $sender_host_authenticated. + + When a message is submitted locally (that is, not over a TCP connection) + the value of $authenticated_id is normally the login name of the calling + process. However, a trusted user can override this by means of the -oMai + command line option. This second case also sets up information used by the + $authresults expansion item. + +$authenticated_fail_id + + When an authentication attempt fails, the variable $authenticated_fail_id + will contain the failed authentication id. If more than one authentication + id is attempted, it will contain only the last one. The variable is + available for processing in the ACL's, generally the quit or notquit ACL. A + message to a local recipient could still be accepted without requiring + authentication, which means this variable could also be visible in all of + the ACL's as well. + +$authenticated_sender + + When acting as a server, Exim takes note of the AUTH= parameter on an + incoming SMTP MAIL command if it believes the sender is sufficiently + trusted, as described in section 33.2. Unless the data is the string "<>", + it is set as the authenticated sender of the message, and the value is + available during delivery in the $authenticated_sender variable. If the + sender is not trusted, Exim accepts the syntax of AUTH=, but ignores the + data. + + When a message is submitted locally (that is, not over a TCP connection), + the value of $authenticated_sender is an address constructed from the login + name of the calling process and $qualify_domain, except that a trusted user + can override this by means of the -oMas command line option. + +$authentication_failed + + This variable is set to "1" in an Exim server if a client issues an AUTH + command that does not succeed. Otherwise it is set to "0". This makes it + possible to distinguish between "did not try to authenticate" ( + $sender_host_authenticated is empty and $authentication_failed is set to + "0") and "tried to authenticate but failed" ($sender_host_authenticated is + empty and $authentication_failed is set to "1"). Failure includes any + negative response to an AUTH command, including (for example) an attempt to + use an undefined mechanism. + +$av_failed + + This variable is available when Exim is compiled with the content-scanning + extension. It is set to "0" by default, but will be set to "1" if any + problem occurs with the virus scanner (specified by av_scanner) during the + ACL malware condition. + +$body_linecount + + When a message is being received or delivered, this variable contains the + number of lines in the message's body. See also $message_linecount. + +$body_zerocount + + When a message is being received or delivered, this variable contains the + number of binary zero bytes (ASCII NULs) in the message's body. + +$bounce_recipient + + This is set to the recipient address of a bounce message while Exim is + creating it. It is useful if a customized bounce message text file is in + use (see chapter 49). + +$bounce_return_size_limit + + This contains the value set in the bounce_return_size_limit option, rounded + up to a multiple of 1000. It is useful when a customized error message text + file is in use (see chapter 49). + +$caller_gid + + The real group id under which the process that called Exim was running. + This is not the same as the group id of the originator of a message (see + $originator_gid). If Exim re-execs itself, this variable in the new + incarnation normally contains the Exim gid. + +$caller_uid + + The real user id under which the process that called Exim was running. This + is not the same as the user id of the originator of a message (see + $originator_uid). If Exim re-execs itself, this variable in the new + incarnation normally contains the Exim uid. + +$callout_address + + After a callout for verification, spamd or malware daemon service, the + address that was connected to. + +$compile_number + + The building process for Exim keeps a count of the number of times it has + been compiled. This serves to distinguish different compilations of the + same version of Exim. + +$config_dir + + The directory name of the main configuration file. That is, the content of + $config_file with the last component stripped. The value does not contain + the trailing slash. If $config_file does not contain a slash, $config_dir + is ".". + +$config_file + + The name of the main configuration file Exim is using. + +$dkim_verify_status + + Results of DKIM verification. For details see section 57.3. + +$dkim_cur_signer, $dkim_verify_reason, $dkim_domain, $dkim_identity, + $dkim_selector, $dkim_algo, $dkim_canon_body, $dkim_canon_headers, + $dkim_copiedheaders, $dkim_bodylength, $dkim_created, $dkim_expires, + $dkim_headernames, $dkim_key_testing, $dkim_key_nosubdomains, + $dkim_key_srvtype, $dkim_key_granularity, $dkim_key_notes, $dkim_key_length + + These variables are only available within the DKIM ACL. For details see + section 57.3. + +$dkim_signers + + When a message has been received this variable contains a colon-separated + list of signer domains and identities for the message. For details see + section 57.3. + +$dnslist_domain, $dnslist_matched, $dnslist_text, $dnslist_value + + When a DNS (black) list lookup succeeds, these variables are set to contain + the following data from the lookup: the list's domain name, the key that + was looked up, the contents of any associated TXT record, and the value + from the main A record. See section 43.32 for more details. + +$domain + + When an address is being routed, or delivered on its own, this variable + contains the domain. Uppercase letters in the domain are converted into + lower case for $domain. + + Global address rewriting happens when a message is received, so the value + of $domain during routing and delivery is the value after rewriting. + $domain is set during user filtering, but not during system filtering, + because a message may have many recipients and the system filter is called + just once. + + When more than one address is being delivered at once (for example, several + RCPT commands in one SMTP delivery), $domain is set only if they all have + the same domain. Transports can be restricted to handling only one domain + at a time if the value of $domain is required at transport time - this is + the default for local transports. For further details of the environment in + which local transports are run, see chapter 23. + + At the end of a delivery, if all deferred addresses have the same domain, + it is set in $domain during the expansion of delay_warning_condition. + + The $domain variable is also used in some other circumstances: + + + When an ACL is running for a RCPT command, $domain contains the domain + of the recipient address. The domain of the sender address is in + $sender_address_domain at both MAIL time and at RCPT time. $domain is + not normally set during the running of the MAIL ACL. However, if the + sender address is verified with a callout during the MAIL ACL, the + sender domain is placed in $domain during the expansions of hosts, + interface, and port in the smtp transport. + + + When a rewrite item is being processed (see chapter 31), $domain + contains the domain portion of the address that is being rewritten; it + can be used in the expansion of the replacement address, for example, + to rewrite domains by file lookup. + + + With one important exception, whenever a domain list is being scanned, + $domain contains the subject domain. Exception: When a domain list in a + sender_domains condition in an ACL is being processed, the subject + domain is in $sender_address_domain and not in $domain. It works this + way so that, in a RCPT ACL, the sender domain list can be dependent on + the recipient domain (which is what is in $domain at this time). + + + When the smtp_etrn_command option is being expanded, $domain contains + the complete argument of the ETRN command (see section 48.8). + +$domain_data + + When the domains option on a router matches a domain by means of a lookup, + the data read by the lookup is available during the running of the router + as $domain_data. In addition, if the driver routes the address to a + transport, the value is available in that transport. If the transport is + handling multiple addresses, the value from the first address is used. + + $domain_data is also set when the domains condition in an ACL matches a + domain by means of a lookup. The data read by the lookup is available + during the rest of the ACL statement. In all other situations, this + variable expands to nothing. + +$exim_gid + + This variable contains the numerical value of the Exim group id. + +$exim_path + + This variable contains the path to the Exim binary. + +$exim_uid + + This variable contains the numerical value of the Exim user id. + +$exim_version + + This variable contains the version string of the Exim build. The first + character is a major version number, currently 4. Then after a dot, the + next group of digits is a minor version number. There may be other + characters following the minor version. + +$header_<name> + + This is not strictly an expansion variable. It is expansion syntax for + inserting the message header line with the given name. Note that the name + must be terminated by colon or white space, because it may contain a wide + variety of characters. Note also that braces must not be used. See the full + description in section 11.5 above. + +$headers_added + + Within an ACL this variable contains the headers added so far by the ACL + modifier add_header (section 43.24). The headers are a newline-separated + list. + +$home + + When the check_local_user option is set for a router, the user's home + directory is placed in $home when the check succeeds. In particular, this + means it is set during the running of users' filter files. A router may + also explicitly set a home directory for use by a transport; this can be + overridden by a setting on the transport itself. + + When running a filter test via the -bf option, $home is set to the value of + the environment variable HOME, which is subject to the keep_environment and + add_environment main config options. + +$host + + If a router assigns an address to a transport (any transport), and passes a + list of hosts with the address, the value of $host when the transport + starts to run is the name of the first host on the list. Note that this + applies both to local and remote transports. + + For the smtp transport, if there is more than one host, the value of $host + changes as the transport works its way through the list. In particular, + when the smtp transport is expanding its options for encryption using TLS, + or for specifying a transport filter (see chapter 24), $host contains the + name of the host to which it is connected. + + When used in the client part of an authenticator configuration (see chapter + 33), $host contains the name of the server to which the client is + connected. + +$host_address + + This variable is set to the remote host's IP address whenever $host is set + for a remote connection. It is also set to the IP address that is being + checked when the ignore_target_hosts option is being processed. + +$host_data + + If a hosts condition in an ACL is satisfied by means of a lookup, the + result of the lookup is made available in the $host_data variable. This + allows you, for example, to do things like this: + + deny hosts = net-lsearch;/some/file + message = $host_data + +$host_lookup_deferred + + This variable normally contains "0", as does $host_lookup_failed. When a + message comes from a remote host and there is an attempt to look up the + host's name from its IP address, and the attempt is not successful, one of + these variables is set to "1". + + + If the lookup receives a definite negative response (for example, a DNS + lookup succeeded, but no records were found), $host_lookup_failed is + set to "1". + + + If there is any kind of problem during the lookup, such that Exim + cannot tell whether or not the host name is defined (for example, a + timeout for a DNS lookup), $host_lookup_deferred is set to "1". + + Looking up a host's name from its IP address consists of more than just a + single reverse lookup. Exim checks that a forward lookup of at least one of + the names it receives from a reverse lookup yields the original IP address. + If this is not the case, Exim does not accept the looked up name(s), and + $host_lookup_failed is set to "1". Thus, being able to find a name from an + IP address (for example, the existence of a PTR record in the DNS) is not + sufficient on its own for the success of a host name lookup. If the reverse + lookup succeeds, but there is a lookup problem such as a timeout when + checking the result, the name is not accepted, and $host_lookup_deferred is + set to "1". See also $sender_host_name. + + Performing these checks sets up information used by the $authresults + expansion item. + +$host_lookup_failed + + See $host_lookup_deferred. + +$host_port + + This variable is set to the remote host's TCP port whenever $host is set + for an outbound connection. + +$initial_cwd + + This variable contains the full path name of the initial working directory + of the current Exim process. This may differ from the current working + directory, as Exim changes this to "/" during early startup, and to + $spool_directory later. + +$inode + + The only time this variable is set is while expanding the directory_file + option in the appendfile transport. The variable contains the inode number + of the temporary file which is about to be renamed. It can be used to + construct a unique name for the file. + +$interface_address + + This is an obsolete name for $received_ip_address. + +$interface_port + + This is an obsolete name for $received_port. + +$item + + This variable is used during the expansion of forall and forany conditions + (see section 11.7), and filter, map, and reduce items (see section 11.7). + In other circumstances, it is empty. + +$ldap_dn + + This variable, which is available only when Exim is compiled with LDAP + support, contains the DN from the last entry in the most recently + successful LDAP lookup. + +$load_average + + This variable contains the system load average, multiplied by 1000 so that + it is an integer. For example, if the load average is 0.21, the value of + the variable is 210. The value is recomputed every time the variable is + referenced. + +$local_part + + When an address is being routed, or delivered on its own, this variable + contains the local part. When a number of addresses are being delivered + together (for example, multiple RCPT commands in an SMTP session), + $local_part is not set. + + Global address rewriting happens when a message is received, so the value + of $local_part during routing and delivery is the value after rewriting. + $local_part is set during user filtering, but not during system filtering, + because a message may have many recipients and the system filter is called + just once. + + If a local part prefix or suffix has been recognized, it is not included in + the value of $local_part during routing and subsequent delivery. The values + of any prefix or suffix are in $local_part_prefix and $local_part_suffix, + respectively. + + When a message is being delivered to a file, pipe, or autoreply transport + as a result of aliasing or forwarding, $local_part is set to the local part + of the parent address, not to the filename or command (see $address_file + and $address_pipe). + + When an ACL is running for a RCPT command, $local_part contains the local + part of the recipient address. + + When a rewrite item is being processed (see chapter 31), $local_part + contains the local part of the address that is being rewritten; it can be + used in the expansion of the replacement address, for example. + + In all cases, all quoting is removed from the local part. For example, for + both the addresses + + "abc:xyz"@test.example + abc\:xyz@test.example + + the value of $local_part is + + abc:xyz + + If you use $local_part to create another address, you should always wrap it + inside a quoting operator. For example, in a redirect router you could + have: + + data = ${quote_local_part:$local_part}@new.domain.example + + Note: The value of $local_part is normally lower cased. If you want to + process local parts in a case-dependent manner in a router, you can set the + caseful_local_part option (see chapter 15). + +$local_part_data + + When the local_parts option on a router matches a local part by means of a + lookup, the data read by the lookup is available during the running of the + router as $local_part_data. In addition, if the driver routes the address + to a transport, the value is available in that transport. If the transport + is handling multiple addresses, the value from the first address is used. + + $local_part_data is also set when the local_parts condition in an ACL + matches a local part by means of a lookup. The data read by the lookup is + available during the rest of the ACL statement. In all other situations, + this variable expands to nothing. + +$local_part_prefix + + When an address is being routed or delivered, and a specific prefix for the + local part was recognized, it is available in this variable, having been + removed from $local_part. + +$local_part_suffix + + When an address is being routed or delivered, and a specific suffix for the + local part was recognized, it is available in this variable, having been + removed from $local_part. + +$local_scan_data + + This variable contains the text returned by the local_scan() function when + a message is received. See chapter 45 for more details. + +$local_user_gid + + See $local_user_uid. + +$local_user_uid + + This variable and $local_user_gid are set to the uid and gid after the + check_local_user router precondition succeeds. This means that their values + are available for the remaining preconditions (senders, require_files, and + condition), for the address_data expansion, and for any router-specific + expansions. At all other times, the values in these variables are "(uid_t) + (-1)" and "(gid_t)(-1)", respectively. + +$localhost_number + + This contains the expanded value of the localhost_number option. The + expansion happens after the main options have been read. + +$log_inodes + + The number of free inodes in the disk partition where Exim's log files are + being written. The value is recalculated whenever the variable is + referenced. If the relevant file system does not have the concept of + inodes, the value of is -1. See also the check_log_inodes option. + +$log_space + + The amount of free space (as a number of kilobytes) in the disk partition + where Exim's log files are being written. The value is recalculated + whenever the variable is referenced. If the operating system does not have + the ability to find the amount of free space (only true for experimental + systems), the space value is -1. See also the check_log_space option. + +$lookup_dnssec_authenticated + + This variable is set after a DNS lookup done by a dnsdb lookup expansion, + dnslookup router or smtp transport. It will be empty if DNSSEC was not + requested, "no" if the result was not labelled as authenticated data and + "yes" if it was. Results that are labelled as authoritative answer that + match the dns_trust_aa configuration variable count also as authenticated + data. + +$mailstore_basename + + This variable is set only when doing deliveries in "mailstore" format in + the appendfile transport. During the expansion of the mailstore_prefix, + mailstore_suffix, message_prefix, and message_suffix options, it contains + the basename of the files that are being written, that is, the name without + the ".tmp", ".env", or ".msg" suffix. At all other times, this variable is + empty. + +$malware_name + + This variable is available when Exim is compiled with the content-scanning + extension. It is set to the name of the virus that was found when the ACL + malware condition is true (see section 44.1). + +$max_received_linelength + + This variable contains the number of bytes in the longest line that was + received as part of the message, not counting the line termination + character(s). It is not valid if the spool_files_wireformat option is used. + +$message_age + + This variable is set at the start of a delivery attempt to contain the + number of seconds since the message was received. It does not change during + a single delivery attempt. + +$message_body + + This variable contains the initial portion of a message's body while it is + being delivered, and is intended mainly for use in filter files. The + maximum number of characters of the body that are put into the variable is + set by the message_body_visible configuration option; the default is 500. + + By default, newlines are converted into spaces in $message_body, to make it + easier to search for phrases that might be split over a line break. + However, this can be disabled by setting message_body_newlines to be true. + Binary zeros are always converted into spaces. + +$message_body_end + + This variable contains the final portion of a message's body while it is + being delivered. The format and maximum size are as for $message_body. + +$message_body_size + + When a message is being delivered, this variable contains the size of the + body in bytes. The count starts from the character after the blank line + that separates the body from the header. Newlines are included in the + count. See also $message_size, $body_linecount, and $body_zerocount. + + If the spool file is wireformat (see the spool_files_wireformat main + option) the CRLF line-terminators are included in the count. + +$message_exim_id + + When a message is being received or delivered, this variable contains the + unique message id that is generated and used by Exim to identify the + message. An id is not created for a message until after its header has been + successfully received. Note: This is not the contents of the Message-ID: + header line; it is the local id that Exim assigns to the message, for + example: "1BXTIK-0001yO-VA". + +$message_headers + + This variable contains a concatenation of all the header lines when a + message is being processed, except for lines added by routers or + transports. The header lines are separated by newline characters. Their + contents are decoded in the same way as a header line that is inserted by + bheader. + +$message_headers_raw + + This variable is like $message_headers except that no processing of the + contents of header lines is done. + +$message_id + + This is an old name for $message_exim_id. It is now deprecated. + +$message_linecount + + This variable contains the total number of lines in the header and body of + the message. Compare $body_linecount, which is the count for the body only. + During the DATA and content-scanning ACLs, $message_linecount contains the + number of lines received. Before delivery happens (that is, before filters, + routers, and transports run) the count is increased to include the + Received: header line that Exim standardly adds, and also any other header + lines that are added by ACLs. The blank line that separates the message + header from the body is not counted. + + As with the special case of $message_size, during the expansion of the + appendfile transport's maildir_tag option in maildir format, the value of + $message_linecount is the precise size of the number of newlines in the + file that has been written (minus one for the blank line between the header + and the body). + + Here is an example of the use of this variable in a DATA ACL: + + deny message = Too many lines in message header + condition = \ + ${if <{250}{${eval:$message_linecount - $body_linecount}}} + + In the MAIL and RCPT ACLs, the value is zero because at that stage the + message has not yet been received. + + This variable is not valid if the spool_files_wireformat option is used. + +$message_size + + When a message is being processed, this variable contains its size in + bytes. In most cases, the size includes those headers that were received + with the message, but not those (such as Envelope-to:) that are added to + individual deliveries as they are written. However, there is one special + case: during the expansion of the maildir_tag option in the appendfile + transport while doing a delivery in maildir format, the value of + $message_size is the precise size of the file that has been written. See + also $message_body_size, $body_linecount, and $body_zerocount. + + While running a per message ACL (mail/rcpt/predata), $message_size contains + the size supplied on the MAIL command, or -1 if no size was given. The + value may not, of course, be truthful. + +$mime_xxx + + A number of variables whose names start with $mime are available when Exim + is compiled with the content-scanning extension. For details, see section + 44.4. + +$n0 - $n9 + + These variables are counters that can be incremented by means of the add + command in filter files. + +$original_domain + + When a top-level address is being processed for delivery, this contains the + same value as $domain. However, if a "child" address (for example, + generated by an alias, forward, or filter file) is being processed, this + variable contains the domain of the original address (lower cased). This + differs from $parent_domain only when there is more than one level of + aliasing or forwarding. When more than one address is being delivered in a + single transport run, $original_domain is not set. + + If a new address is created by means of a deliver command in a system + filter, it is set up with an artificial "parent" address. This has the + local part system-filter and the default qualify domain. + +$original_local_part + + When a top-level address is being processed for delivery, this contains the + same value as $local_part, unless a prefix or suffix was removed from the + local part, because $original_local_part always contains the full local + part. When a "child" address (for example, generated by an alias, forward, + or filter file) is being processed, this variable contains the full local + part of the original address. + + If the router that did the redirection processed the local part + case-insensitively, the value in $original_local_part is in lower case. + This variable differs from $parent_local_part only when there is more than + one level of aliasing or forwarding. When more than one address is being + delivered in a single transport run, $original_local_part is not set. + + If a new address is created by means of a deliver command in a system + filter, it is set up with an artificial "parent" address. This has the + local part system-filter and the default qualify domain. + +$originator_gid + + This variable contains the value of $caller_gid that was set when the + message was received. For messages received via the command line, this is + the gid of the sending user. For messages received by SMTP over TCP/IP, + this is normally the gid of the Exim user. + +$originator_uid + + The value of $caller_uid that was set when the message was received. For + messages received via the command line, this is the uid of the sending + user. For messages received by SMTP over TCP/IP, this is normally the uid + of the Exim user. + +$parent_domain + + This variable is similar to $original_domain (see above), except that it + refers to the immediately preceding parent address. + +$parent_local_part + + This variable is similar to $original_local_part (see above), except that + it refers to the immediately preceding parent address. + +$pid + + This variable contains the current process id. + +$pipe_addresses + + This is not an expansion variable, but is mentioned here because the string + "$pipe_addresses" is handled specially in the command specification for the + pipe transport (chapter 29) and in transport filters (described under + transport_filter in chapter 24). It cannot be used in general expansion + strings, and provokes an "unknown variable" error if encountered. + +$primary_hostname + + This variable contains the value set by primary_hostname in the + configuration file, or read by the uname() function. If uname() returns a + single-component name, Exim calls gethostbyname() (or getipnodebyname() + where available) in an attempt to acquire a fully qualified host name. See + also $smtp_active_hostname. + +$proxy_external_address, $proxy_external_port, $proxy_local_address, + $proxy_local_port, $proxy_session + + These variables are only available when built with Proxy Protocol or SOCKS5 + support. For details see chapter 58.1. + +$prdr_requested + + This variable is set to "yes" if PRDR was requested by the client for the + current message, otherwise "no". + +$prvscheck_address + + This variable is used in conjunction with the prvscheck expansion item, + which is described in sections 11.5 and 43.51. + +$prvscheck_keynum + + This variable is used in conjunction with the prvscheck expansion item, + which is described in sections 11.5 and 43.51. + +$prvscheck_result + + This variable is used in conjunction with the prvscheck expansion item, + which is described in sections 11.5 and 43.51. + +$qualify_domain + + The value set for the qualify_domain option in the configuration file. + +$qualify_recipient + + The value set for the qualify_recipient option in the configuration file, + or if not set, the value of $qualify_domain. + +$queue_name + + The name of the spool queue in use; empty for the default queue. + +$rcpt_count + + When a message is being received by SMTP, this variable contains the number + of RCPT commands received for the current message. If this variable is used + in a RCPT ACL, its value includes the current command. + +$rcpt_defer_count + + When a message is being received by SMTP, this variable contains the number + of RCPT commands in the current message that have previously been rejected + with a temporary (4xx) response. + +$rcpt_fail_count + + When a message is being received by SMTP, this variable contains the number + of RCPT commands in the current message that have previously been rejected + with a permanent (5xx) response. + +$received_count + + This variable contains the number of Received: header lines in the message, + including the one added by Exim (so its value is always greater than zero). + It is available in the DATA ACL, the non-SMTP ACL, and while routing and + delivering. + +$received_for + + If there is only a single recipient address in an incoming message, this + variable contains that address when the Received: header line is being + built. The value is copied after recipient rewriting has happened, but + before the local_scan() function is run. + +$received_ip_address + + As soon as an Exim server starts processing an incoming TCP/IP connection, + this variable is set to the address of the local IP interface, and + $received_port is set to the local port number. (The remote IP address and + port are in $sender_host_address and $sender_host_port.) When testing with + -bh, the port value is -1 unless it has been set using the -oMi command + line option. + + As well as being useful in ACLs (including the "connect" ACL), these + variable could be used, for example, to make the filename for a TLS + certificate depend on which interface and/or port is being used for the + incoming connection. The values of $received_ip_address and $received_port + are saved with any messages that are received, thus making these variables + available at delivery time. For outbound connections see + $sending_ip_address. + +$received_port + + See $received_ip_address. + +$received_protocol + + When a message is being processed, this variable contains the name of the + protocol by which it was received. Most of the names used by Exim are + defined by RFCs 821, 2821, and 3848. They start with "smtp" (the client + used HELO) or "esmtp" (the client used EHLO). This can be followed by "s" + for secure (encrypted) and/or "a" for authenticated. Thus, for example, if + the protocol is set to "esmtpsa", the message was received over an + encrypted SMTP connection and the client was successfully authenticated. + + Exim uses the protocol name "smtps" for the case when encryption is + automatically set up on connection without the use of STARTTLS (see + tls_on_connect_ports), and the client uses HELO to initiate the encrypted + SMTP session. The name "smtps" is also used for the rare situation where + the client initially uses EHLO, sets up an encrypted connection using + STARTTLS, and then uses HELO afterwards. + + The -oMr option provides a way of specifying a custom protocol name for + messages that are injected locally by trusted callers. This is commonly + used to identify messages that are being re-injected after some kind of + scanning. + +$received_time + + This variable contains the date and time when the current message was + received, as a number of seconds since the start of the Unix epoch. + +$recipient_data + + This variable is set after an indexing lookup success in an ACL recipients + condition. It contains the data from the lookup, and the value remains set + until the next recipients test. Thus, you can do things like this: + + require recipients = cdb*@;/some/file + deny some further test involving $recipient_data + + Warning: This variable is set only when a lookup is used as an indexing + method in the address list, using the semicolon syntax as in the example + above. The variable is not set for a lookup that is used as part of the + string expansion that all such lists undergo before being interpreted. + +$recipient_verify_failure + + In an ACL, when a recipient verification fails, this variable contains + information about the failure. It is set to one of the following words: + + + "qualify": The address was unqualified (no domain), and the message was + neither local nor came from an exempted host. + + + "route": Routing failed. + + + "mail": Routing succeeded, and a callout was attempted; rejection + occurred at or before the MAIL command (that is, on initial connection, + HELO, or MAIL). + + + "recipient": The RCPT command in a callout was rejected. + + + "postmaster": The postmaster check in a callout was rejected. + + The main use of this variable is expected to be to distinguish between + rejections of MAIL and rejections of RCPT. + +$recipients + + This variable contains a list of envelope recipients for a message. A comma + and a space separate the addresses in the replacement text. However, the + variable is not generally available, to prevent exposure of Bcc recipients + in unprivileged users' filter files. You can use $recipients only in these + cases: + + 1. In a system filter file. + + 2. In the ACLs associated with the DATA command and with non-SMTP + messages, that is, the ACLs defined by acl_smtp_predata, acl_smtp_data, + acl_smtp_mime, acl_not_smtp_start, acl_not_smtp, and acl_not_smtp_mime. + + 3. From within a local_scan() function. + +$recipients_count + + When a message is being processed, this variable contains the number of + envelope recipients that came with the message. Duplicates are not excluded + from the count. While a message is being received over SMTP, the number + increases for each accepted recipient. It can be referenced in an ACL. + +$regex_match_string + + This variable is set to contain the matching regular expression after a + regex ACL condition has matched (see section 44.5). + +$regex1, $regex2, etc + + When a regex or mime_regex ACL condition succeeds, these variables contain + the captured substrings identified by the regular expression. + +$reply_address + + When a message is being processed, this variable contains the contents of + the Reply-To: header line if one exists and it is not empty, or otherwise + the contents of the From: header line. Apart from the removal of leading + white space, the value is not processed in any way. In particular, no RFC + 2047 decoding or character code translation takes place. + +$return_path + + When a message is being delivered, this variable contains the return path - + the sender field that will be sent as part of the envelope. It is not + enclosed in <> characters. At the start of routing an address, $return_path + has the same value as $sender_address, but if, for example, an incoming + message to a mailing list has been expanded by a router which specifies a + different address for bounce messages, $return_path subsequently contains + the new bounce address, whereas $sender_address always contains the + original sender address that was received with the message. In other words, + $sender_address contains the incoming envelope sender, and $return_path + contains the outgoing envelope sender. + +$return_size_limit + + This is an obsolete name for $bounce_return_size_limit. + +$router_name + + During the running of a router this variable contains its name. + +$runrc + + This variable contains the return code from a command that is run by the $ + {run...} expansion item. Warning: In a router or transport, you cannot + assume the order in which option values are expanded, except for those + preconditions whose order of testing is documented. Therefore, you cannot + reliably expect to set $runrc by the expansion of one option, and use it in + another. + +$self_hostname + + When an address is routed to a supposedly remote host that turns out to be + the local host, what happens is controlled by the self generic router + option. One of its values causes the address to be passed to another + router. When this happens, $self_hostname is set to the name of the local + host that the original router encountered. In other circumstances its + contents are null. + +$sender_address + + When a message is being processed, this variable contains the sender's + address that was received in the message's envelope. The case of letters in + the address is retained, in both the local part and the domain. For bounce + messages, the value of this variable is the empty string. See also + $return_path. + +$sender_address_data + + If $address_data is set when the routers are called from an ACL to verify a + sender address, the final value is preserved in $sender_address_data, to + distinguish it from data from a recipient address. The value does not + persist after the end of the current ACL statement. If you want to preserve + it for longer, you can save it in an ACL variable. + +$sender_address_domain + + The domain portion of $sender_address. + +$sender_address_local_part + + The local part portion of $sender_address. + +$sender_data + + This variable is set after a lookup success in an ACL senders condition or + in a router senders option. It contains the data from the lookup, and the + value remains set until the next senders test. Thus, you can do things like + this: + + require senders = cdb*@;/some/file + deny some further test involving $sender_data + + Warning: This variable is set only when a lookup is used as an indexing + method in the address list, using the semicolon syntax as in the example + above. The variable is not set for a lookup that is used as part of the + string expansion that all such lists undergo before being interpreted. + +$sender_fullhost + + When a message is received from a remote host, this variable contains the + host name and IP address in a single string. It ends with the IP address in + square brackets, followed by a colon and a port number if the logging of + ports is enabled. The format of the rest of the string depends on whether + the host issued a HELO or EHLO SMTP command, and whether the host name was + verified by looking up its IP address. (Looking up the IP address can be + forced by the host_lookup option, independent of verification.) A plain + host name at the start of the string is a verified host name; if this is + not present, verification either failed or was not requested. A host name + in parentheses is the argument of a HELO or EHLO command. This is omitted + if it is identical to the verified host name or to the host's IP address in + square brackets. + +$sender_helo_dnssec + + This boolean variable is true if a successful HELO verification was done + using DNS information the resolver library stated was authenticated data. + +$sender_helo_name + + When a message is received from a remote host that has issued a HELO or + EHLO command, the argument of that command is placed in this variable. It + is also set if HELO or EHLO is used when a message is received using SMTP + locally via the -bs or -bS options. + +$sender_host_address + + When a message is received from a remote host using SMTP, this variable + contains that host's IP address. For locally non-SMTP submitted messages, + it is empty. + +$sender_host_authenticated + + This variable contains the name (not the public name) of the authenticator + driver that successfully authenticated the client from which the message + was received. It is empty if there was no successful authentication. See + also $authenticated_id. + +$sender_host_dnssec + + If an attempt to populate $sender_host_name has been made (by reference, + hosts_lookup or otherwise) then this boolean will have been set true if, + and only if, the resolver library states that both the reverse and forward + DNS were authenticated data. At all other times, this variable is false. + + It is likely that you will need to coerce DNSSEC support on in the resolver + library, by setting: + + dns_dnssec_ok = 1 + + Exim does not perform DNSSEC validation itself, instead leaving that to a + validating resolver (e.g. unbound, or bind with suitable configuration). + + If you have changed host_lookup_order so that "bydns" is not the first + mechanism in the list, then this variable will be false. + + This requires that your system resolver library support EDNS0 (and that + DNSSEC flags exist in the system headers). If the resolver silently drops + all EDNS0 options, then this will have no effect. OpenBSD's asr resolver is + known to currently ignore EDNS0, documented in CAVEATS of asr_run(3). + +$sender_host_name + + When a message is received from a remote host, this variable contains the + host's name as obtained by looking up its IP address. For messages received + by other means, this variable is empty. + + If the host name has not previously been looked up, a reference to + $sender_host_name triggers a lookup (for messages from remote hosts). A + looked up name is accepted only if it leads back to the original IP address + via a forward lookup. If either the reverse or the forward lookup fails to + find any data, or if the forward lookup does not yield the original IP + address, $sender_host_name remains empty, and $host_lookup_failed is set to + "1". + + However, if either of the lookups cannot be completed (for example, there + is a DNS timeout), $host_lookup_deferred is set to "1", and + $host_lookup_failed remains set to "0". + + Once $host_lookup_failed is set to "1", Exim does not try to look up the + host name again if there is a subsequent reference to $sender_host_name in + the same Exim process, but it does try again if $host_lookup_deferred is + set to "1". + + Exim does not automatically look up every calling host's name. If you want + maximum efficiency, you should arrange your configuration so that it avoids + these lookups altogether. The lookup happens only if one or more of the + following are true: + + + A string containing $sender_host_name is expanded. + + + The calling host matches the list in host_lookup. In the default + configuration, this option is set to *, so it must be changed if + lookups are to be avoided. (In the code, the default for host_lookup is + unset.) + + + Exim needs the host name in order to test an item in a host list. The + items that require this are described in sections 10.13 and 10.17. + + + The calling host matches helo_try_verify_hosts or helo_verify_hosts. In + this case, the host name is required to compare with the name quoted in + any EHLO or HELO commands that the client issues. + + + The remote host issues a EHLO or HELO command that quotes one of the + domains in helo_lookup_domains. The default value of this option is + + helo_lookup_domains = @ : @[] + + which causes a lookup if a remote host (incorrectly) gives the server's + name or IP address in an EHLO or HELO command. + +$sender_host_port + + When a message is received from a remote host, this variable contains the + port number that was used on the remote host. + +$sender_ident + + When a message is received from a remote host, this variable contains the + identification received in response to an RFC 1413 request. When a message + has been received locally, this variable contains the login name of the + user that called Exim. + +$sender_rate_xxx + + A number of variables whose names begin $sender_rate_ are set as part of + the ratelimit ACL condition. Details are given in section 43.38. + +$sender_rcvhost + + This is provided specifically for use in Received: headers. It starts with + either the verified host name (as obtained from a reverse DNS lookup) or, + if there is no verified host name, the IP address in square brackets. After + that there may be text in parentheses. When the first item is a verified + host name, the first thing in the parentheses is the IP address in square + brackets, followed by a colon and a port number if port logging is enabled. + When the first item is an IP address, the port is recorded as "port=xxxx" + inside the parentheses. + + There may also be items of the form "helo=xxxx" if HELO or EHLO was used + and its argument was not identical to the real host name or IP address, and + "ident=xxxx" if an RFC 1413 ident string is available. If all three items + are present in the parentheses, a newline and tab are inserted into the + string, to improve the formatting of the Received: header. + +$sender_verify_failure + + In an ACL, when a sender verification fails, this variable contains + information about the failure. The details are the same as for + $recipient_verify_failure. + +$sending_ip_address + + This variable is set whenever an outgoing SMTP connection to another host + has been set up. It contains the IP address of the local interface that is + being used. This is useful if a host that has more than one IP address + wants to take on different personalities depending on which one is being + used. For incoming connections, see $received_ip_address. + +$sending_port + + This variable is set whenever an outgoing SMTP connection to another host + has been set up. It contains the local port that is being used. For + incoming connections, see $received_port. + +$smtp_active_hostname + + During an incoming SMTP session, this variable contains the value of the + active host name, as specified by the smtp_active_hostname option. The + value of $smtp_active_hostname is saved with any message that is received, + so its value can be consulted during routing and delivery. + +$smtp_command + + During the processing of an incoming SMTP command, this variable contains + the entire command. This makes it possible to distinguish between HELO and + EHLO in the HELO ACL, and also to distinguish between commands such as + these: + + MAIL FROM:<> + MAIL FROM: <> + + For a MAIL command, extra parameters such as SIZE can be inspected. For a + RCPT command, the address in $smtp_command is the original address before + any rewriting, whereas the values in $local_part and $domain are taken from + the address after SMTP-time rewriting. + +$smtp_command_argument + + While an ACL is running to check an SMTP command, this variable contains + the argument, that is, the text that follows the command name, with leading + white space removed. Following the introduction of $smtp_command, this + variable is somewhat redundant, but is retained for backwards + compatibility. + +$smtp_command_history + + A comma-separated list (with no whitespace) of the most-recent SMTP + commands received, in time-order left to right. Only a limited number of + commands are remembered. + +$smtp_count_at_connection_start + + This variable is set greater than zero only in processes spawned by the + Exim daemon for handling incoming SMTP connections. The name is + deliberately long, in order to emphasize what the contents are. When the + daemon accepts a new connection, it increments this variable. A copy of the + variable is passed to the child process that handles the connection, but + its value is fixed, and never changes. It is only an approximation of how + many incoming connections there actually are, because many other + connections may come and go while a single connection is being processed. + When a child process terminates, the daemon decrements its copy of the + variable. + +$sn0 - $sn9 + + These variables are copies of the values of the $n0 - $n9 accumulators that + were current at the end of the system filter file. This allows a system + filter file to set values that can be tested in users' filter files. For + example, a system filter could set a value indicating how likely it is that + a message is junk mail. + +$spam_xxx + + A number of variables whose names start with $spam are available when Exim + is compiled with the content-scanning extension. For details, see section + 44.2. + +$spf_header_comment, $spf_received, $spf_result, $spf_result_guessed, + $spf_smtp_comment + + These variables are only available if Exim is built with SPF support. For + details see section 57.4. + +$spool_directory + + The name of Exim's spool directory. + +$spool_inodes + + The number of free inodes in the disk partition where Exim's spool files + are being written. The value is recalculated whenever the variable is + referenced. If the relevant file system does not have the concept of + inodes, the value of is -1. See also the check_spool_inodes option. + +$spool_space + + The amount of free space (as a number of kilobytes) in the disk partition + where Exim's spool files are being written. The value is recalculated + whenever the variable is referenced. If the operating system does not have + the ability to find the amount of free space (only true for experimental + systems), the space value is -1. For example, to check in an ACL that there + is at least 50 megabytes free on the spool, you could write: + + condition = ${if > {$spool_space}{50000}} + + See also the check_spool_space option. + +$thisaddress + + This variable is set only during the processing of the foranyaddress + command in a filter file. Its use is explained in the description of that + command, which can be found in the separate document entitled Exim's + interfaces to mail filtering. + +$tls_in_bits + + Contains an approximation of the TLS cipher's bit-strength on the inbound + connection; the meaning of this depends upon the TLS implementation used. + If TLS has not been negotiated, the value will be 0. The value of this is + automatically fed into the Cyrus SASL authenticator when acting as a + server, to specify the "external SSF" (a SASL term). + + The deprecated $tls_bits variable refers to the inbound side except when + used in the context of an outbound SMTP delivery, when it refers to the + outbound. + +$tls_out_bits + + Contains an approximation of the TLS cipher's bit-strength on an outbound + SMTP connection; the meaning of this depends upon the TLS implementation + used. If TLS has not been negotiated, the value will be 0. + +$tls_in_ourcert + + This variable refers to the certificate presented to the peer of an inbound + connection when the message was received. It is only useful as the argument + of a certextract expansion item, md5, sha1 or sha256 operator, or a def + condition. + + Note: Under versions of OpenSSL preceding 1.1.1, when a list of more than + one file is used for tls_certificate, this variable is not reliable. + +$tls_in_peercert + + This variable refers to the certificate presented by the peer of an inbound + connection when the message was received. It is only useful as the argument + of a certextract expansion item, md5, sha1 or sha256 operator, or a def + condition. If certificate verification fails it may refer to a failing + chain element which is not the leaf. + +$tls_out_ourcert + + This variable refers to the certificate presented to the peer of an + outbound connection. It is only useful as the argument of a certextract + expansion item, md5, sha1 or sha256 operator, or a def condition. + +$tls_out_peercert + + This variable refers to the certificate presented by the peer of an + outbound connection. It is only useful as the argument of a certextract + expansion item, md5, sha1 or sha256 operator, or a def condition. If + certificate verification fails it may refer to a failing chain element + which is not the leaf. + +$tls_in_certificate_verified + + This variable is set to "1" if a TLS certificate was verified when the + message was received, and "0" otherwise. + + The deprecated $tls_certificate_verified variable refers to the inbound + side except when used in the context of an outbound SMTP delivery, when it + refers to the outbound. + +$tls_out_certificate_verified + + This variable is set to "1" if a TLS certificate was verified when an + outbound SMTP connection was made, and "0" otherwise. + +$tls_in_cipher + + When a message is received from a remote host over an encrypted SMTP + connection, this variable is set to the cipher suite that was negotiated, + for example DES-CBC3-SHA. In other circumstances, in particular, for + message received over unencrypted connections, the variable is empty. + Testing $tls_in_cipher for emptiness is one way of distinguishing between + encrypted and non-encrypted connections during ACL processing. + + The deprecated $tls_cipher variable is the same as $tls_in_cipher during + message reception, but in the context of an outward SMTP delivery taking + place via the smtp transport becomes the same as $tls_out_cipher. + +$tls_out_cipher + + This variable is cleared before any outgoing SMTP connection is made, and + then set to the outgoing cipher suite if one is negotiated. See chapter 42 + for details of TLS support and chapter 30 for details of the smtp + transport. + +$tls_out_dane + + DANE active status. See section 42.15. + +$tls_in_ocsp + + When a message is received from a remote client connection the result of + any OCSP request from the client is encoded in this variable: + + 0 OCSP proof was not requested (default value) + 1 No response to request + 2 Response not verified + 3 Verification failed + 4 Verification succeeded + +$tls_out_ocsp + + When a message is sent to a remote host connection the result of any OCSP + request made is encoded in this variable. See $tls_in_ocsp for values. + +$tls_in_peerdn + + When a message is received from a remote host over an encrypted SMTP + connection, and Exim is configured to request a certificate from the + client, the value of the Distinguished Name of the certificate is made + available in the $tls_in_peerdn during subsequent processing. If + certificate verification fails it may refer to a failing chain element + which is not the leaf. + + The deprecated $tls_peerdn variable refers to the inbound side except when + used in the context of an outbound SMTP delivery, when it refers to the + outbound. + +$tls_out_peerdn + + When a message is being delivered to a remote host over an encrypted SMTP + connection, and Exim is configured to request a certificate from the + server, the value of the Distinguished Name of the certificate is made + available in the $tls_out_peerdn during subsequent processing. If + certificate verification fails it may refer to a failing chain element + which is not the leaf. + +$tls_in_sni + + When a TLS session is being established, if the client sends the Server + Name Indication extension, the value will be placed in this variable. If + the variable appears in tls_certificate then this option and some others, + described in 42.10, will be re-expanded early in the TLS session, to permit + a different certificate to be presented (and optionally a different key to + be used) to the client, based upon the value of the SNI extension. + + The deprecated $tls_sni variable refers to the inbound side except when + used in the context of an outbound SMTP delivery, when it refers to the + outbound. + +$tls_out_sni + + During outbound SMTP deliveries, this variable reflects the value of the + tls_sni option on the transport. + +$tls_out_tlsa_usage + + Bitfield of TLSA record types found. See section 42.15. + +$tod_bsdinbox + + The time of day and the date, in the format required for BSD-style mailbox + files, for example: Thu Oct 17 17:14:09 1995. + +$tod_epoch + + The time and date as a number of seconds since the start of the Unix epoch. + +$tod_epoch_l + + The time and date as a number of microseconds since the start of the Unix + epoch. + +$tod_full + + A full version of the time and date, for example: Wed, 16 Oct 1995 09:51:40 + +0100. The timezone is always given as a numerical offset from UTC, with + positive values used for timezones that are ahead (east) of UTC, and + negative values for those that are behind (west). + +$tod_log + + The time and date in the format used for writing Exim's log files, for + example: 1995-10-12 15:32:29, but without a timezone. + +$tod_logfile + + This variable contains the date in the format yyyymmdd. This is the format + that is used for datestamping log files when log_file_path contains the + "%D" flag. + +$tod_zone + + This variable contains the numerical value of the local timezone, for + example: -0500. + +$tod_zulu + + This variable contains the UTC date and time in "Zulu" format, as specified + by ISO 8601, for example: 20030221154023Z. + +$transport_name + + During the running of a transport, this variable contains its name. + +$value + + This variable contains the result of an expansion lookup, extraction + operation, or external command, as described above. It is also used during + a reduce expansion. + +$verify_mode + + While a router or transport is being run in verify mode or for cutthrough + delivery, contains "S" for sender-verification or "R" for + recipient-verification. Otherwise, empty. + +$version_number + + The version number of Exim. + +$warn_message_delay + + This variable is set only during the creation of a message warning about a + delivery delay. Details of its use are explained in section 49.2. + +$warn_message_recipients + + This variable is set only during the creation of a message warning about a + delivery delay. Details of its use are explained in section 49.2. + + + +=============================================================================== +12. EMBEDDED PERL + +Exim can be built to include an embedded Perl interpreter. When this is done, +Perl subroutines can be called as part of the string expansion process. To make +use of the Perl support, you need version 5.004 or later of Perl installed on +your system. To include the embedded interpreter in the Exim binary, include +the line + +EXIM_PERL = perl.o + +in your Local/Makefile and then build Exim in the normal way. + + +12.1 Setting up so Perl can be used +----------------------------------- + +Access to Perl subroutines is via a global configuration option called +perl_startup and an expansion string operator ${perl ...}. If there is no +perl_startup option in the Exim configuration file then no Perl interpreter is +started and there is almost no overhead for Exim (since none of the Perl +library will be paged in unless used). If there is a perl_startup option then +the associated value is taken to be Perl code which is executed in a newly +created Perl interpreter. + +The value of perl_startup is not expanded in the Exim sense, so you do not need +backslashes before any characters to escape special meanings. The option should +usually be something like + +perl_startup = do '/etc/exim.pl' + +where /etc/exim.pl is Perl code which defines any subroutines you want to use +from Exim. Exim can be configured either to start up a Perl interpreter as soon +as it is entered, or to wait until the first time it is needed. Starting the +interpreter at the beginning ensures that it is done while Exim still has its +setuid privilege, but can impose an unnecessary overhead if Perl is not in fact +used in a particular run. Also, note that this does not mean that Exim is +necessarily running as root when Perl is called at a later time. By default, +the interpreter is started only when it is needed, but this can be changed in +two ways: + + * Setting perl_at_start (a boolean option) in the configuration requests a + startup when Exim is entered. + + * The command line option -ps also requests a startup when Exim is entered, + overriding the setting of perl_at_start. + +There is also a command line option -pd (for delay) which suppresses the +initial startup, even if perl_at_start is set. + + * To provide more security executing Perl code via the embedded Perl + interpreter, the perl_taintmode option can be set. This enables the taint + mode of the Perl interpreter. You are encouraged to set this option to a + true value. To avoid breaking existing installations, it defaults to false. + + +12.2 Calling Perl subroutines +----------------------------- + +When the configuration file includes a perl_startup option you can make use of +the string expansion item to call the Perl subroutines that are defined by the +perl_startup code. The operator is used in any of the following forms: + +${perl{foo}} +${perl{foo}{argument}} +${perl{foo}{argument1}{argument2} ... } + +which calls the subroutine foo with the given arguments. A maximum of eight +arguments may be passed. Passing more than this results in an expansion failure +with an error message of the form + +Too many arguments passed to Perl subroutine "foo" (max is 8) + +The return value of the Perl subroutine is evaluated in a scalar context before +it is passed back to Exim to be inserted into the expanded string. If the +return value is undef, the expansion is forced to fail in the same way as an +explicit "fail" on an if or lookup item. If the subroutine aborts by obeying +Perl's die function, the expansion fails with the error message that was passed +to die. + + +12.3 Calling Exim functions from Perl +------------------------------------- + +Within any Perl code called from Exim, the function Exim::expand_string() is +available to call back into Exim's string expansion function. For example, the +Perl code + +my $lp = Exim::expand_string('$local_part'); + +makes the current Exim $local_part available in the Perl variable $lp. Note +those are single quotes and not double quotes to protect against $local_part +being interpolated as a Perl variable. + +If the string expansion is forced to fail by a "fail" item, the result of +Exim::expand_string() is undef. If there is a syntax error in the expansion +string, the Perl call from the original expansion string fails with an +appropriate error message, in the same way as if die were used. + +Two other Exim functions are available for use from within Perl code. +Exim::debug_write() writes a string to the standard error stream if Exim's +debugging is enabled. If you want a newline at the end, you must supply it. +Exim::log_write() writes a string to Exim's main log, adding a leading +timestamp. In this case, you should not supply a terminating newline. + + +12.4 Use of standard output and error by Perl +--------------------------------------------- + +You should not write to the standard error or output streams from within your +Perl code, as it is not defined how these are set up. In versions of Exim +before 4.50, it is possible for the standard output or error to refer to the +SMTP connection during message reception via the daemon. Writing to this stream +is certain to cause chaos. From Exim 4.50 onwards, the standard output and +error streams are connected to /dev/null in the daemon. The chaos is avoided, +but the output is lost. + +The Perl warn statement writes to the standard error stream by default. Calls +to warn may be embedded in Perl modules that you use, but over which you have +no control. When Exim starts up the Perl interpreter, it arranges for output +from the warn statement to be written to the Exim main log. You can change this +by including appropriate Perl magic somewhere in your Perl code. For example, +to discard warn output completely, you need this: + +$SIG{__WARN__} = sub { }; + +Whenever a warn is obeyed, the anonymous subroutine is called. In this example, +the code for the subroutine is empty, so it does nothing, but you can include +any Perl code that you like. The text of the warn message is passed as the +first subroutine argument. + + + +=============================================================================== +13. STARTING THE DAEMON AND THE USE OF NETWORK INTERFACES + +A host that is connected to a TCP/IP network may have one or more physical +hardware network interfaces. Each of these interfaces may be configured as one +or more "logical" interfaces, which are the entities that a program actually +works with. Each of these logical interfaces is associated with an IP address. +In addition, TCP/IP software supports "loopback" interfaces (127.0.0.1 in IPv4 +and ::1 in IPv6), which do not use any physical hardware. Exim requires +knowledge about the host's interfaces for use in three different circumstances: + + 1. When a listening daemon is started, Exim needs to know which interfaces and + ports to listen on. + + 2. When Exim is routing an address, it needs to know which IP addresses are + associated with local interfaces. This is required for the correct + processing of MX lists by removing the local host and others with the same + or higher priority values. Also, Exim needs to detect cases when an address + is routed to an IP address that in fact belongs to the local host. Unless + the self router option or the allow_localhost option of the smtp transport + is set (as appropriate), this is treated as an error situation. + + 3. When Exim connects to a remote host, it may need to know which interface to + use for the outgoing connection. + +Exim's default behaviour is likely to be appropriate in the vast majority of +cases. If your host has only one interface, and you want all its IP addresses +to be treated in the same way, and you are using only the standard SMTP port, +you should not need to take any special action. The rest of this chapter does +not apply to you. + +In a more complicated situation you may want to listen only on certain +interfaces, or on different ports, and for this reason there are a number of +options that can be used to influence Exim's behaviour. The rest of this +chapter describes how they operate. + +When a message is received over TCP/IP, the interface and port that were +actually used are set in $received_ip_address and $received_port. + + +13.1 Starting a listening daemon +-------------------------------- + +When a listening daemon is started (by means of the -bd command line option), +the interfaces and ports on which it listens are controlled by the following +options: + + * daemon_smtp_ports contains a list of default ports or service names. (For + backward compatibility, this option can also be specified in the singular.) + + * local_interfaces contains list of interface IP addresses on which to + listen. Each item may optionally also specify a port. + +The default list separator in both cases is a colon, but this can be changed as +described in section 6.21. When IPv6 addresses are involved, it is usually best +to change the separator to avoid having to double all the colons. For example: + +local_interfaces = <; 127.0.0.1 ; \ + 192.168.23.65 ; \ + ::1 ; \ + 3ffe:ffff:836f::fe86:a061 + +There are two different formats for specifying a port along with an IP address +in local_interfaces: + + 1. The port is added onto the address with a dot separator. For example, to + listen on port 1234 on two different IP addresses: + + local_interfaces = <; 192.168.23.65.1234 ; \ + 3ffe:ffff:836f::fe86:a061.1234 + + 2. The IP address is enclosed in square brackets, and the port is added with a + colon separator, for example: + + local_interfaces = <; [192.168.23.65]:1234 ; \ + [3ffe:ffff:836f::fe86:a061]:1234 + +When a port is not specified, the value of daemon_smtp_ports is used. The +default setting contains just one port: + +daemon_smtp_ports = smtp + +If more than one port is listed, each interface that does not have its own port +specified listens on all of them. Ports that are listed in daemon_smtp_ports +can be identified either by name (defined in /etc/services) or by number. +However, when ports are given with individual IP addresses in local_interfaces, +only numbers (not names) can be used. + + +13.2 Special IP listening addresses +----------------------------------- + +The addresses 0.0.0.0 and ::0 are treated specially. They are interpreted as +"all IPv4 interfaces" and "all IPv6 interfaces", respectively. In each case, +Exim tells the TCP/IP stack to "listen on all IPvx interfaces" instead of +setting up separate listening sockets for each interface. The default value of +local_interfaces is + +local_interfaces = 0.0.0.0 + +when Exim is built without IPv6 support; otherwise it is: + +local_interfaces = <; ::0 ; 0.0.0.0 + +Thus, by default, Exim listens on all available interfaces, on the SMTP port. + + +13.3 Overriding local_interfaces and daemon_smtp_ports +------------------------------------------------------ + +The -oX command line option can be used to override the values of +daemon_smtp_ports and/or local_interfaces for a particular daemon instance. +Another way of doing this would be to use macros and the -D option. However, +-oX can be used by any admin user, whereas modification of the runtime +configuration by -D is allowed only when the caller is root or exim. + +The value of -oX is a list of items. The default colon separator can be changed +in the usual way (6.21) if required. If there are any items that do not contain +dots or colons (that is, are not IP addresses), the value of daemon_smtp_ports +is replaced by the list of those items. If there are any items that do contain +dots or colons, the value of local_interfaces is replaced by those items. Thus, +for example, + +-oX 1225 + +overrides daemon_smtp_ports, but leaves local_interfaces unchanged, whereas + +-oX 192.168.34.5.1125 + +overrides local_interfaces, leaving daemon_smtp_ports unchanged. (However, +since local_interfaces now contains no items without ports, the value of +daemon_smtp_ports is no longer relevant in this example.) + + +13.4 Support for the submissions (aka SSMTP or SMTPS) protocol +-------------------------------------------------------------- + +Exim supports the use of TLS-on-connect, used by mail clients in the +"submissions" protocol, historically also known as SMTPS or SSMTP. For some +years, IETF Standards Track documents only blessed the STARTTLS-based +Submission service (port 587) while common practice was to support the same +feature set on port 465, but using TLS-on-connect. If your installation needs +to provide service to mail clients (Mail User Agents, MUAs) then you should +provide service on both the 587 and the 465 TCP ports. + +If the tls_on_connect_ports option is set to a list of port numbers or service +names, connections to those ports must first establish TLS, before proceeding +to the application layer use of the SMTP protocol. + +The common use of this option is expected to be + +tls_on_connect_ports = 465 + +per RFC 8314. There is also a command line option -tls-on-connect, which forces +all ports to behave in this way when a daemon is started. + +Warning: Setting tls_on_connect_ports does not of itself cause the daemon to +listen on those ports. You must still specify them in daemon_smtp_ports, +local_interfaces, or the -oX option. (This is because tls_on_connect_ports +applies to inetd connections as well as to connections via the daemon.) + + +13.5 IPv6 address scopes +------------------------ + +IPv6 addresses have "scopes", and a host with multiple hardware interfaces can, +in principle, have the same link-local IPv6 address on different interfaces. +Thus, additional information is needed, over and above the IP address, to +distinguish individual interfaces. A convention of using a percent sign +followed by something (often the interface name) has been adopted in some +cases, leading to addresses like this: + +fe80::202:b3ff:fe03:45c1%eth0 + +To accommodate this usage, a percent sign followed by an arbitrary string is +allowed at the end of an IPv6 address. By default, Exim calls getaddrinfo() to +convert a textual IPv6 address for actual use. This function recognizes the +percent convention in operating systems that support it, and it processes the +address appropriately. Unfortunately, some older libraries have problems with +getaddrinfo(). If + +IPV6_USE_INET_PTON=yes + +is set in Local/Makefile (or an OS-dependent Makefile) when Exim is built, Exim +uses inet_pton() to convert a textual IPv6 address for actual use, instead of +getaddrinfo(). (Before version 4.14, it always used this function.) Of course, +this means that the additional functionality of getaddrinfo() - recognizing +scoped addresses - is lost. + + +13.6 Disabling IPv6 +------------------- + +Sometimes it happens that an Exim binary that was compiled with IPv6 support is +run on a host whose kernel does not support IPv6. The binary will fall back to +using IPv4, but it may waste resources looking up AAAA records, and trying to +connect to IPv6 addresses, causing delays to mail delivery. If you set the +disable_ipv6 option true, even if the Exim binary has IPv6 support, no IPv6 +activities take place. AAAA records are never looked up, and any IPv6 addresses +that are listed in local_interfaces, data for the manualroute router, etc. are +ignored. If IP literals are enabled, the ipliteral router declines to handle +IPv6 literal addresses. + +On the other hand, when IPv6 is in use, there may be times when you want to +disable it for certain hosts or domains. You can use the dns_ipv4_lookup option +to globally suppress the lookup of AAAA records for specified domains, and you +can use the ignore_target_hosts generic router option to ignore IPv6 addresses +in an individual router. + + +13.7 Examples of starting a listening daemon +-------------------------------------------- + +The default case in an IPv6 environment is + +daemon_smtp_ports = smtp +local_interfaces = <; ::0 ; 0.0.0.0 + +This specifies listening on the smtp port on all IPv6 and IPv4 interfaces. +Either one or two sockets may be used, depending on the characteristics of the +TCP/IP stack. (This is complicated and messy; for more information, read the +comments in the daemon.c source file.) + +To specify listening on ports 25 and 26 on all interfaces: + +daemon_smtp_ports = 25 : 26 + +(leaving local_interfaces at the default setting) or, more explicitly: + +local_interfaces = <; ::0.25 ; ::0.26 \ + 0.0.0.0.25 ; 0.0.0.0.26 + +To listen on the default port on all IPv4 interfaces, and on port 26 on the +IPv4 loopback address only: + +local_interfaces = 0.0.0.0 : 127.0.0.1.26 + +To specify listening on the default port on specific interfaces only: + +local_interfaces = 10.0.0.67 : 192.168.34.67 + +Warning: Such a setting excludes listening on the loopback interfaces. + + +13.8 Recognizing the local host +------------------------------- + +The local_interfaces option is also used when Exim needs to determine whether +or not an IP address refers to the local host. That is, the IP addresses of all +the interfaces on which a daemon is listening are always treated as local. + +For this usage, port numbers in local_interfaces are ignored. If either of the +items 0.0.0.0 or ::0 are encountered, Exim gets a complete list of available +interfaces from the operating system, and extracts the relevant (that is, IPv4 +or IPv6) addresses to use for checking. + +Some systems set up large numbers of virtual interfaces in order to provide +many virtual web servers. In this situation, you may want to listen for email +on only a few of the available interfaces, but nevertheless treat all +interfaces as local when routing. You can do this by setting +extra_local_interfaces to a list of IP addresses, possibly including the "all" +wildcard values. These addresses are recognized as local, but are not used for +listening. Consider this example: + +local_interfaces = <; 127.0.0.1 ; ::1 ; \ + 192.168.53.235 ; \ + 3ffe:2101:12:1:a00:20ff:fe86:a061 + +extra_local_interfaces = <; ::0 ; 0.0.0.0 + +The daemon listens on the loopback interfaces and just one IPv4 and one IPv6 +address, but all available interface addresses are treated as local when Exim +is routing. + +In some environments the local host name may be in an MX list, but with an IP +address that is not assigned to any local interface. In other cases it may be +desirable to treat other host names as if they referred to the local host. Both +these cases can be handled by setting the hosts_treat_as_local option. This +contains host names rather than IP addresses. When a host is referenced during +routing, either via an MX record or directly, it is treated as the local host +if its name matches hosts_treat_as_local, or if any of its IP addresses match +local_interfaces or extra_local_interfaces. + + +13.9 Delivering to a remote host +-------------------------------- + +Delivery to a remote host is handled by the smtp transport. By default, it +allows the system's TCP/IP functions to choose which interface to use (if there +is more than one) when connecting to a remote host. However, the interface +option can be set to specify which interface is used. See the description of +the smtp transport in chapter 30 for more details. + + + +=============================================================================== +14. MAIN CONFIGURATION + +The first part of the runtime configuration file contains three types of item: + + * Macro definitions: These lines start with an upper case letter. See section + 6.4 for details of macro processing. + + * Named list definitions: These lines start with one of the words + "domainlist", "hostlist", "addresslist", or "localpartlist". Their use is + described in section 10.5. + + * Main configuration settings: Each setting occupies one line of the file + (with possible continuations). If any setting is preceded by the word + "hide", the -bP command line option displays its value to admin users only. + See section 6.11 for a description of the syntax of these option settings. + +This chapter specifies all the main configuration options, along with their +types and default values. For ease of finding a particular option, they appear +in alphabetical order in section 14.23 below. However, because there are now so +many options, they are first listed briefly in functional groups, as an aid to +finding the name of the option you are looking for. Some options are listed in +more than one group. + + +14.1 Miscellaneous +------------------ + +bi_command to run for -bi command line option +debug_store do extra internal checks +disable_ipv6 do no IPv6 processing +keep_malformed for broken files - should not happen +localhost_number for unique message ids in clusters +message_body_newlines retain newlines in $message_body +message_body_visible how much to show in $message_body +mua_wrapper run in "MUA wrapper" mode +print_topbitchars top-bit characters are printing +spool_wireformat use wire-format spool data files when possible +timezone force time zone + + +14.2 Exim parameters +-------------------- + +exim_group override compiled-in value +exim_path override compiled-in value +exim_user override compiled-in value +primary_hostname default from uname() +split_spool_directory use multiple directories +spool_directory override compiled-in value + + +14.3 Privilege controls +----------------------- + +admin_groups groups that are Exim admin users +commandline_checks_require_admin require admin for various checks +deliver_drop_privilege drop root for delivery processes +local_from_check insert Sender: if necessary +local_from_prefix for testing From: for local sender +local_from_suffix for testing From: for local sender +local_sender_retain keep Sender: from untrusted user +never_users do not run deliveries as these +prod_requires_admin forced delivery requires admin user +queue_list_requires_admin queue listing requires admin user +trusted_groups groups that are trusted +trusted_users users that are trusted + + +14.4 Logging +------------ + +event_action custom logging +hosts_connection_nolog exemption from connect logging +log_file_path override compiled-in value +log_selector set/unset optional logging +log_timezone add timezone to log lines +message_logs create per-message logs +preserve_message_logs after message completion +process_log_path for SIGUSR1 and exiwhat +slow_lookup_log control logging of slow DNS lookups +syslog_duplication controls duplicate log lines on syslog +syslog_facility set syslog "facility" field +syslog_pid pid in syslog lines +syslog_processname set syslog "ident" field +syslog_timestamp timestamp syslog lines +write_rejectlog control use of message log + + +14.5 Frozen messages +-------------------- + +auto_thaw sets time for retrying frozen messages +freeze_tell send message when freezing +move_frozen_messages to another directory +timeout_frozen_after keep frozen messages only so long + + +14.6 Data lookups +----------------- + +ibase_servers InterBase servers +ldap_ca_cert_dir dir of CA certs to verify LDAP server's +ldap_ca_cert_file file of CA certs to verify LDAP server's +ldap_cert_file client cert file for LDAP +ldap_cert_key client key file for LDAP +ldap_cipher_suite TLS negotiation preference control +ldap_default_servers used if no server in query +ldap_require_cert action to take without LDAP server cert +ldap_start_tls require TLS within LDAP +ldap_version set protocol version +lookup_open_max lookup files held open +mysql_servers default MySQL servers +oracle_servers Oracle servers +pgsql_servers default PostgreSQL servers +sqlite_lock_timeout as it says + + +14.7 Message ids +---------------- + +message_id_header_domain used to build Message-ID: header +message_id_header_text ditto + + +14.8 Embedded Perl Startup +-------------------------- + +perl_at_start always start the interpreter +perl_startup code to obey when starting Perl +perl_taintmode enable taint mode in Perl + + +14.9 Daemon +----------- + +daemon_smtp_ports default ports +daemon_startup_retries number of times to retry +daemon_startup_sleep time to sleep between tries +extra_local_interfaces not necessarily listened on +local_interfaces on which to listen, with optional ports +pid_file_path override compiled-in value +queue_run_max maximum simultaneous queue runners + + +14.10 Resource control +---------------------- + +check_log_inodes before accepting a message +check_log_space before accepting a message +check_spool_inodes before accepting a message +check_spool_space before accepting a message +deliver_queue_load_max no queue deliveries if load high +queue_only_load queue incoming if load high +queue_only_load_latch don't re-evaluate load for each message +queue_run_max maximum simultaneous queue runners +remote_max_parallel parallel SMTP delivery per message +smtp_accept_max simultaneous incoming connections +smtp_accept_max_nonmail non-mail commands +smtp_accept_max_nonmail_hosts hosts to which the limit applies +smtp_accept_max_per_connection messages per connection +smtp_accept_max_per_host connections from one host +smtp_accept_queue queue mail if more connections +smtp_accept_queue_per_connection queue if more messages per connection +smtp_accept_reserve only reserve hosts if more connections +smtp_check_spool_space from SIZE on MAIL command +smtp_connect_backlog passed to TCP/IP stack +smtp_load_reserve SMTP from reserved hosts if load high +smtp_reserve_hosts these are the reserve hosts + + +14.11 Policy controls +--------------------- + +acl_not_smtp ACL for non-SMTP messages +acl_not_smtp_mime ACL for non-SMTP MIME parts +acl_not_smtp_start ACL for start of non-SMTP message +acl_smtp_auth ACL for AUTH +acl_smtp_connect ACL for connection +acl_smtp_data ACL for DATA +acl_smtp_data_prdr ACL for DATA, per-recipient +acl_smtp_dkim ACL for DKIM verification +acl_smtp_etrn ACL for ETRN +acl_smtp_expn ACL for EXPN +acl_smtp_helo ACL for EHLO or HELO +acl_smtp_mail ACL for MAIL +acl_smtp_mailauth ACL for AUTH on MAIL command +acl_smtp_mime ACL for MIME parts +acl_smtp_notquit ACL for non-QUIT terminations +acl_smtp_predata ACL for start of data +acl_smtp_quit ACL for QUIT +acl_smtp_rcpt ACL for RCPT +acl_smtp_starttls ACL for STARTTLS +acl_smtp_vrfy ACL for VRFY +av_scanner specify virus scanner +check_rfc2047_length check length of RFC 2047 "encoded words" +dns_cname_loops follow CNAMEs returned by resolver +dns_csa_search_limit control CSA parent search depth +dns_csa_use_reverse en/disable CSA IP reverse search +header_maxsize total size of message header +header_line_maxsize individual header line limit +helo_accept_junk_hosts allow syntactic junk from these hosts +helo_allow_chars allow illegal chars in HELO names +helo_lookup_domains lookup hostname for these HELO names +helo_try_verify_hosts HELO soft-checked for these hosts +helo_verify_hosts HELO hard-checked for these hosts +host_lookup host name looked up for these hosts +host_lookup_order order of DNS and local name lookups +hosts_proxy use proxy protocol for these hosts +host_reject_connection reject connection from these hosts +hosts_treat_as_local useful in some cluster configurations +local_scan_timeout timeout for local_scan() +message_size_limit for all messages +percent_hack_domains recognize %-hack for these domains +spamd_address set interface to SpamAssassin +strict_acl_vars object to unset ACL variables + + +14.12 Callout cache +------------------- + +callout_domain_negative_expire timeout for negative domain cache item +callout_domain_positive_expire timeout for positive domain cache item +callout_negative_expire timeout for negative address cache item +callout_positive_expire timeout for positive address cache item +callout_random_local_part string to use for "random" testing + + +14.13 TLS +--------- + +gnutls_compat_mode use GnuTLS compatibility mode +gnutls_allow_auto_pkcs11 allow GnuTLS to autoload PKCS11 modules +openssl_options adjust OpenSSL compatibility options +tls_advertise_hosts advertise TLS to these hosts +tls_certificate location of server certificate +tls_crl certificate revocation list +tls_dh_max_bits clamp D-H bit count suggestion +tls_dhparam DH parameters for server +tls_eccurve EC curve selection for server +tls_ocsp_file location of server certificate status proof +tls_on_connect_ports specify SSMTP (SMTPS) ports +tls_privatekey location of server private key +tls_remember_esmtp don't reset after starting TLS +tls_require_ciphers specify acceptable ciphers +tls_try_verify_hosts try to verify client certificate +tls_verify_certificates expected client certificates +tls_verify_hosts insist on client certificate verify + + +14.14 Local user handling +------------------------- + +finduser_retries useful in NIS environments +gecos_name used when creating Sender: +gecos_pattern ditto +max_username_length for systems that truncate +unknown_login used when no login name found +unknown_username ditto +uucp_from_pattern for recognizing "From " lines +uucp_from_sender ditto + + +14.15 All incoming messages (SMTP and non-SMTP) +----------------------------------------------- + +header_maxsize total size of message header +header_line_maxsize individual header line limit +message_size_limit applies to all messages +percent_hack_domains recognize %-hack for these domains +received_header_text expanded to make Received: +received_headers_max for mail loop detection +recipients_max limit per message +recipients_max_reject permanently reject excess recipients + + +14.16 Non-SMTP incoming messages +-------------------------------- + +receive_timeout for non-SMTP messages + + +14.17 Incoming SMTP messages +---------------------------- + +See also the Policy controls section above. + +dkim_verify_signers DKIM domain for which DKIM ACL is run +host_lookup host name looked up for these hosts +host_lookup_order order of DNS and local name lookups +recipient_unqualified_hosts may send unqualified recipients +rfc1413_hosts make ident calls to these hosts +rfc1413_query_timeout zero disables ident calls +sender_unqualified_hosts may send unqualified senders +smtp_accept_keepalive some TCP/IP magic +smtp_accept_max simultaneous incoming connections +smtp_accept_max_nonmail non-mail commands +smtp_accept_max_nonmail_hosts hosts to which the limit applies +smtp_accept_max_per_connection messages per connection +smtp_accept_max_per_host connections from one host +smtp_accept_queue queue mail if more connections +smtp_accept_queue_per_connection queue if more messages per connection +smtp_accept_reserve only reserve hosts if more connections +smtp_active_hostname host name to use in messages +smtp_banner text for welcome banner +smtp_check_spool_space from SIZE on MAIL command +smtp_connect_backlog passed to TCP/IP stack +smtp_enforce_sync of SMTP command/responses +smtp_etrn_command what to run for ETRN +smtp_etrn_serialize only one at once +smtp_load_reserve only reserve hosts if this load +smtp_max_unknown_commands before dropping connection +smtp_ratelimit_hosts apply ratelimiting to these hosts +smtp_ratelimit_mail ratelimit for MAIL commands +smtp_ratelimit_rcpt ratelimit for RCPT commands +smtp_receive_timeout per command or data line +smtp_reserve_hosts these are the reserve hosts +smtp_return_error_details give detail on rejections + + +14.18 SMTP extensions +--------------------- + +accept_8bitmime advertise 8BITMIME +auth_advertise_hosts advertise AUTH to these hosts +chunking_advertise_hosts advertise CHUNKING to these hosts +dsn_advertise_hosts advertise DSN extensions to these hosts +ignore_fromline_hosts allow "From " from these hosts +ignore_fromline_local allow "From " from local SMTP +pipelining_advertise_hosts advertise pipelining to these hosts +prdr_enable advertise PRDR to all hosts +smtputf8_advertise_hosts advertise SMTPUTF8 to these hosts +tls_advertise_hosts advertise TLS to these hosts + + +14.19 Processing messages +------------------------- + +allow_domain_literals recognize domain literal syntax +allow_mx_to_ip allow MX to point to IP address +allow_utf8_domains in addresses +check_rfc2047_length check length of RFC 2047 "encoded words" +delivery_date_remove from incoming messages +envelope_to_remove from incoming messages +extract_addresses_remove_arguments affects -t processing +headers_charset default for translations +qualify_domain default for senders +qualify_recipient default for recipients +return_path_remove from incoming messages +strip_excess_angle_brackets in addresses +strip_trailing_dot at end of addresses +untrusted_set_sender untrusted can set envelope sender + + +14.20 System filter +------------------- + +system_filter locate system filter +system_filter_directory_transport transport for delivery to a directory +system_filter_file_transport transport for delivery to a file +system_filter_group group for filter running +system_filter_pipe_transport transport for delivery to a pipe +system_filter_reply_transport transport for autoreply delivery +system_filter_user user for filter running + + +14.21 Routing and delivery +-------------------------- + +disable_ipv6 do no IPv6 processing +dns_again_means_nonexist for broken domains +dns_check_names_pattern pre-DNS syntax check +dns_dnssec_ok parameter for resolver +dns_ipv4_lookup only v4 lookup for these domains +dns_retrans parameter for resolver +dns_retry parameter for resolver +dns_trust_aa DNS zones trusted as authentic +dns_use_edns0 parameter for resolver +hold_domains hold delivery for these domains +local_interfaces for routing checks +queue_domains no immediate delivery for these +queue_only no immediate delivery at all +queue_only_file no immediate delivery if file exists +queue_only_load no immediate delivery if load is high +queue_only_load_latch don't re-evaluate load for each message +queue_only_override allow command line to override +queue_run_in_order order of arrival +queue_run_max of simultaneous queue runners +queue_smtp_domains no immediate SMTP delivery for these +remote_max_parallel parallel SMTP delivery per message +remote_sort_domains order of remote deliveries +retry_data_expire timeout for retry data +retry_interval_max safety net for retry rules + + +14.22 Bounce and warning messages +--------------------------------- + +bounce_message_file content of bounce +bounce_message_text content of bounce +bounce_return_body include body if returning message +bounce_return_linesize_limit limit on returned message line length +bounce_return_message include original message in bounce +bounce_return_size_limit limit on returned message +bounce_sender_authentication send authenticated sender with bounce +dsn_from set From: contents in bounces +errors_copy copy bounce messages +errors_reply_to Reply-to: in bounces +delay_warning time schedule +delay_warning_condition condition for warning messages +ignore_bounce_errors_after discard undeliverable bounces +smtp_return_error_details give detail on rejections +warn_message_file content of warning message + + +14.23 Alphabetical list of main options +--------------------------------------- + +Those options that undergo string expansion before use are marked with *. + ++-----------------------------------------------------+ +|accept_8bitmime|Use: main|Type: boolean|Default: true| ++-----------------------------------------------------+ + +This option causes Exim to send 8BITMIME in its response to an SMTP EHLO +command, and to accept the BODY= parameter on MAIL commands. However, though +Exim is 8-bit clean, it is not a protocol converter, and it takes no steps to +do anything special with messages received by this route. + +Historically Exim kept this option off by default, but the maintainers feel +that in today's Internet, this causes more problems than it solves. It now +defaults to true. A more detailed analysis of the issues is provided by Dan +Bernstein: + +https://cr.yp.to/smtp/8bitmime.html + +To log received 8BITMIME status use + +log_selector = +8bitmime + ++---------------------------------------------------+ +|acl_not_smtp|Use: main|Type: string*|Default: unset| ++---------------------------------------------------+ + +This option defines the ACL that is run when a non-SMTP message has been read +and is on the point of being accepted. See chapter 43 for further details. + ++--------------------------------------------------------+ +|acl_not_smtp_mime|Use: main|Type: string*|Default: unset| ++--------------------------------------------------------+ + +This option defines the ACL that is run for individual MIME parts of non-SMTP +messages. It operates in exactly the same way as acl_smtp_mime operates for +SMTP messages. + ++---------------------------------------------------------+ +|acl_not_smtp_start|Use: main|Type: string*|Default: unset| ++---------------------------------------------------------+ + +This option defines the ACL that is run before Exim starts reading a non-SMTP +message. See chapter 43 for further details. + ++----------------------------------------------------+ +|acl_smtp_auth|Use: main|Type: string*|Default: unset| ++----------------------------------------------------+ + +This option defines the ACL that is run when an SMTP AUTH command is received. +See chapter 43 for further details. + ++-------------------------------------------------------+ +|acl_smtp_connect|Use: main|Type: string*|Default: unset| ++-------------------------------------------------------+ + +This option defines the ACL that is run when an SMTP connection is received. +See chapter 43 for further details. + ++----------------------------------------------------+ +|acl_smtp_data|Use: main|Type: string*|Default: unset| ++----------------------------------------------------+ + +This option defines the ACL that is run after an SMTP DATA command has been +processed and the message itself has been received, but before the final +acknowledgment is sent. See chapter 43 for further details. + ++----------------------------------------------------------+ +|acl_smtp_data_prdr|Use: main|Type: string*|Default: accept| ++----------------------------------------------------------+ + +This option defines the ACL that, if the PRDR feature has been negotiated, is +run for each recipient after an SMTP DATA command has been processed and the +message itself has been received, but before the acknowledgment is sent. See +chapter 43 for further details. + ++----------------------------------------------------+ +|acl_smtp_dkim|Use: main|Type: string*|Default: unset| ++----------------------------------------------------+ + +This option defines the ACL that is run for each DKIM signature (by default, or +as specified in the dkim_verify_signers option) of a received message. See +section 57.3 for further details. + ++----------------------------------------------------+ +|acl_smtp_etrn|Use: main|Type: string*|Default: unset| ++----------------------------------------------------+ + +This option defines the ACL that is run when an SMTP ETRN command is received. +See chapter 43 for further details. + ++----------------------------------------------------+ +|acl_smtp_expn|Use: main|Type: string*|Default: unset| ++----------------------------------------------------+ + +This option defines the ACL that is run when an SMTP EXPN command is received. +See chapter 43 for further details. + ++----------------------------------------------------+ +|acl_smtp_helo|Use: main|Type: string*|Default: unset| ++----------------------------------------------------+ + +This option defines the ACL that is run when an SMTP EHLO or HELO command is +received. See chapter 43 for further details. + ++----------------------------------------------------+ +|acl_smtp_mail|Use: main|Type: string*|Default: unset| ++----------------------------------------------------+ + +This option defines the ACL that is run when an SMTP MAIL command is received. +See chapter 43 for further details. + ++--------------------------------------------------------+ +|acl_smtp_mailauth|Use: main|Type: string*|Default: unset| ++--------------------------------------------------------+ + +This option defines the ACL that is run when there is an AUTH parameter on a +MAIL command. See chapter 43 for details of ACLs, and chapter 33 for details of +authentication. + ++----------------------------------------------------+ +|acl_smtp_mime|Use: main|Type: string*|Default: unset| ++----------------------------------------------------+ + +This option is available when Exim is built with the content-scanning +extension. It defines the ACL that is run for each MIME part in a message. See +section 44.4 for details. + ++-------------------------------------------------------+ +|acl_smtp_notquit|Use: main|Type: string*|Default: unset| ++-------------------------------------------------------+ + +This option defines the ACL that is run when an SMTP session ends without a +QUIT command being received. See chapter 43 for further details. + ++-------------------------------------------------------+ +|acl_smtp_predata|Use: main|Type: string*|Default: unset| ++-------------------------------------------------------+ + +This option defines the ACL that is run when an SMTP DATA command is received, +before the message itself is received. See chapter 43 for further details. + ++----------------------------------------------------+ +|acl_smtp_quit|Use: main|Type: string*|Default: unset| ++----------------------------------------------------+ + +This option defines the ACL that is run when an SMTP QUIT command is received. +See chapter 43 for further details. + ++----------------------------------------------------+ +|acl_smtp_rcpt|Use: main|Type: string*|Default: unset| ++----------------------------------------------------+ + +This option defines the ACL that is run when an SMTP RCPT command is received. +See chapter 43 for further details. + ++--------------------------------------------------------+ +|acl_smtp_starttls|Use: main|Type: string*|Default: unset| ++--------------------------------------------------------+ + +This option defines the ACL that is run when an SMTP STARTTLS command is +received. See chapter 43 for further details. + ++----------------------------------------------------+ +|acl_smtp_vrfy|Use: main|Type: string*|Default: unset| ++----------------------------------------------------+ + +This option defines the ACL that is run when an SMTP VRFY command is received. +See chapter 43 for further details. + ++----------------------------------------------------------+ +|add_environment|Use: main|Type: string list|Default: empty| ++----------------------------------------------------------+ + +This option allows to set individual environment variables that the currently +linked libraries and programs in child processes use. See 29.4 for the +environment of pipe transports. + ++--------------------------------------------------------+ +|admin_groups|Use: main|Type: string list*|Default: unset| ++--------------------------------------------------------+ + +This option is expanded just once, at the start of Exim's processing. If the +current group or any of the supplementary groups of an Exim caller is in this +colon-separated list, the caller has admin privileges. If all your system +programmers are in a specific group, for example, you can give them all Exim +admin privileges by putting that group in admin_groups. However, this does not +permit them to read Exim's spool files (whose group owner is the Exim gid). To +permit this, you have to add individuals to the Exim group. + ++------------------------------------------------------------+ +|allow_domain_literals|Use: main|Type: boolean|Default: false| ++------------------------------------------------------------+ + +If this option is set, the RFC 2822 domain literal format is permitted in email +addresses. The option is not set by default, because the domain literal format +is not normally required these days, and few people know about it. It has, +however, been exploited by mail abusers. + +Unfortunately, it seems that some DNS black list maintainers are using this +format to report black listing to postmasters. If you want to accept messages +addressed to your hosts by IP address, you need to set allow_domain_literals +true, and also to add "@[]" to the list of local domains (defined in the named +domain list local_domains in the default configuration). This "magic string" +matches the domain literal form of all the local host's IP addresses. + ++-----------------------------------------------------+ +|allow_mx_to_ip|Use: main|Type: boolean|Default: false| ++-----------------------------------------------------+ + +It appears that more and more DNS zone administrators are breaking the rules +and putting domain names that look like IP addresses on the right hand side of +MX records. Exim follows the rules and rejects this, giving an error message +that explains the misconfiguration. However, some other MTAs support this +practice, so to avoid "Why can't Exim do this?" complaints, allow_mx_to_ip +exists, in order to enable this heinous activity. It is not recommended, except +when you have no other choice. + ++---------------------------------------------------------+ +|allow_utf8_domains|Use: main|Type: boolean|Default: false| ++---------------------------------------------------------+ + +Lots of discussion is going on about internationalized domain names. One camp +is strongly in favour of just using UTF-8 characters, and it seems that at +least two other MTAs permit this. This option allows Exim users to experiment +if they wish. + +If it is set true, Exim's domain parsing function allows valid UTF-8 +multicharacters to appear in domain name components, in addition to letters, +digits, and hyphens. However, just setting this option is not enough; if you +want to look up these domain names in the DNS, you must also adjust the value +of dns_check_names_pattern to match the extended form. A suitable setting is: + +dns_check_names_pattern = (?i)^(?>(?(1)\.|())[a-z0-9\xc0-\xff]\ + (?>[-a-z0-9\x80-\xff]*[a-z0-9\x80-\xbf])?)+$ + +Alternatively, you can just disable this feature by setting + +dns_check_names_pattern = + +That is, set the option to an empty string so that no check is done. + ++----------------------------------------------------------+ +|auth_advertise_hosts|Use: main|Type: host list*|Default: *| ++----------------------------------------------------------+ + +If any server authentication mechanisms are configured, Exim advertises them in +response to an EHLO command only if the calling host matches this list. +Otherwise, Exim does not advertise AUTH. Exim does not accept AUTH commands +from clients to which it has not advertised the availability of AUTH. The +advertising of individual authentication mechanisms can be controlled by the +use of the server_advertise_condition generic authenticator option on the +individual authenticators. See chapter 33 for further details. + +Certain mail clients (for example, Netscape) require the user to provide a name +and password for authentication if AUTH is advertised, even though it may not +be needed (the host may accept messages from hosts on its local LAN without +authentication, for example). The auth_advertise_hosts option can be used to +make these clients more friendly by excluding them from the set of hosts to +which Exim advertises AUTH. + +If you want to advertise the availability of AUTH only when the connection is +encrypted using TLS, you can make use of the fact that the value of this option +is expanded, with a setting like this: + +auth_advertise_hosts = ${if eq{$tls_in_cipher}{}{}{*}} + +If $tls_in_cipher is empty, the session is not encrypted, and the result of the +expansion is empty, thus matching no hosts. Otherwise, the result of the +expansion is *, which matches all hosts. + ++------------------------------------------+ +|auto_thaw|Use: main|Type: time|Default: 0s| ++------------------------------------------+ + +If this option is set to a time greater than zero, a queue runner will try a +new delivery attempt on any frozen message, other than a bounce message, if +this much time has passed since it was frozen. This may result in the message +being re-frozen if nothing has changed since the last attempt. It is a way of +saying "keep on trying, even though there are big problems". + +Note: This is an old option, which predates timeout_frozen_after and +ignore_bounce_errors_after. It is retained for compatibility, but it is not +thought to be very useful any more, and its use should probably be avoided. + ++----------------------------------------------------+ +|av_scanner|Use: main|Type: string|Default: see below| ++----------------------------------------------------+ + +This option is available if Exim is built with the content-scanning extension. +It specifies which anti-virus scanner to use. The default value is: + +sophie:/var/run/sophie + +If the value of av_scanner starts with a dollar character, it is expanded +before use. See section 44.1 for further details. + ++------------------------------------------------+ +|bi_command|Use: main|Type: string|Default: unset| ++------------------------------------------------+ + +This option supplies the name of a command that is run when Exim is called with +the -bi option (see chapter 5). The string value is just the command name, it +is not a complete command line. If an argument is required, it must come from +the -oA command line option. + ++---------------------------------------------------------+ +|bounce_message_file|Use: main|Type: string|Default: unset| ++---------------------------------------------------------+ + +This option defines a template file containing paragraphs of text to be used +for constructing bounce messages. Details of the file's contents are given in +chapter 49. See also warn_message_file. + ++---------------------------------------------------------+ +|bounce_message_text|Use: main|Type: string|Default: unset| ++---------------------------------------------------------+ + +When this option is set, its contents are included in the default bounce +message immediately after "This message was created automatically by mail +delivery software." It is not used if bounce_message_file is set. + ++--------------------------------------------------------+ +|bounce_return_body|Use: main|Type: boolean|Default: true| ++--------------------------------------------------------+ + +This option controls whether the body of an incoming message is included in a +bounce message when bounce_return_message is true. The default setting causes +the entire message, both header and body, to be returned (subject to the value +of bounce_return_size_limit). If this option is false, only the message header +is included. In the case of a non-SMTP message containing an error that is +detected during reception, only those header lines preceding the point at which +the error was detected are returned. + ++-----------------------------------------------------------------+ +|bounce_return_linesize_limit|Use: main|Type: integer|Default: 998| ++-----------------------------------------------------------------+ + +This option sets a limit in bytes on the line length of messages that are +returned to senders due to delivery problems, when bounce_return_message is +true. The default value corresponds to RFC limits. If the message being +returned has lines longer than this value it is treated as if the +bounce_return_size_limit (below) restriction was exceeded. + +The option also applies to bounces returned when an error is detected during +reception of a message. In this case lines from the original are truncated. + +The option does not apply to messages generated by an autoreply transport. + ++-----------------------------------------------------------+ +|bounce_return_message|Use: main|Type: boolean|Default: true| ++-----------------------------------------------------------+ + +If this option is set false, none of the original message is included in bounce +messages generated by Exim. See also bounce_return_size_limit and +bounce_return_body. + ++--------------------------------------------------------------+ +|bounce_return_size_limit|Use: main|Type: integer|Default: 100K| ++--------------------------------------------------------------+ + +This option sets a limit in bytes on the size of messages that are returned to +senders as part of bounce messages when bounce_return_message is true. The +limit should be less than the value of the global message_size_limit and of any +message_size_limit settings on transports, to allow for the bounce text that +Exim generates. If this option is set to zero there is no limit. + +When the body of any message that is to be included in a bounce message is +greater than the limit, it is truncated, and a comment pointing this out is +added at the top. The actual cutoff may be greater than the value given, owing +to the use of buffering for transferring the message in chunks (typically 8K in +size). The idea is to save bandwidth on those undeliverable 15-megabyte +messages. + ++------------------------------------------------------------------+ +|bounce_sender_authentication|Use: main|Type: string|Default: unset| ++------------------------------------------------------------------+ + +This option provides an authenticated sender address that is sent with any +bounce messages generated by Exim that are sent over an authenticated SMTP +connection. A typical setting might be: + +bounce_sender_authentication = mailer-daemon@my.domain.example + +which would cause bounce messages to be sent using the SMTP command: + +MAIL FROM:<> AUTH=mailer-daemon@my.domain.example + +The value of bounce_sender_authentication must always be a complete email +address. + ++---------------------------------------------------------------+ +|callout_domain_negative_expire|Use: main|Type: time|Default: 3h| ++---------------------------------------------------------------+ + +This option specifies the expiry time for negative callout cache data for a +domain. See section 43.45 for details of callout verification, and section +43.47 for details of the caching. + ++---------------------------------------------------------------+ +|callout_domain_positive_expire|Use: main|Type: time|Default: 7d| ++---------------------------------------------------------------+ + +This option specifies the expiry time for positive callout cache data for a +domain. See section 43.45 for details of callout verification, and section +43.47 for details of the caching. + ++--------------------------------------------------------+ +|callout_negative_expire|Use: main|Type: time|Default: 2h| ++--------------------------------------------------------+ + +This option specifies the expiry time for negative callout cache data for an +address. See section 43.45 for details of callout verification, and section +43.47 for details of the caching. + ++---------------------------------------------------------+ +|callout_positive_expire|Use: main|Type: time|Default: 24h| ++---------------------------------------------------------+ + +This option specifies the expiry time for positive callout cache data for an +address. See section 43.45 for details of callout verification, and section +43.47 for details of the caching. + ++--------------------------------------------------------------------+ +|callout_random_local_part|Use: main|Type: string*|Default: see below| ++--------------------------------------------------------------------+ + +This option defines the "random" local part that can be used as part of callout +verification. The default value is + +$primary_hostname-$tod_epoch-testing + +See section 43.46 for details of how this value is used. + ++-----------------------------------------------------+ +|check_log_inodes|Use: main|Type: integer|Default: 100| ++-----------------------------------------------------+ + +See check_spool_space below. + ++----------------------------------------------------+ +|check_log_space|Use: main|Type: integer|Default: 10M| ++----------------------------------------------------+ + +See check_spool_space below. + ++----------------------------------------------------------+ +|check_rfc2047_length|Use: main|Type: boolean|Default: true| ++----------------------------------------------------------+ + +RFC 2047 defines a way of encoding non-ASCII characters in headers using a +system of "encoded words". The RFC specifies a maximum length for an encoded +word; strings to be encoded that exceed this length are supposed to use +multiple encoded words. By default, Exim does not recognize encoded words that +exceed the maximum length. However, it seems that some software, in violation +of the RFC, generates overlong encoded words. If check_rfc2047_length is set +false, Exim recognizes encoded words of any length. + ++-------------------------------------------------------+ +|check_spool_inodes|Use: main|Type: integer|Default: 100| ++-------------------------------------------------------+ + +See check_spool_space below. + ++------------------------------------------------------+ +|check_spool_space|Use: main|Type: integer|Default: 10M| ++------------------------------------------------------+ + +The four check_... options allow for checking of disk resources before a +message is accepted. + +When any of these options are nonzero, they apply to all incoming messages. If +you want to apply different checks to different kinds of message, you can do so +by testing the variables $log_inodes, $log_space, $spool_inodes, and +$spool_space in an ACL with appropriate additional conditions. + +check_spool_space and check_spool_inodes check the spool partition if either +value is greater than zero, for example: + +check_spool_space = 100M +check_spool_inodes = 100 + +The spool partition is the one that contains the directory defined by +SPOOL_DIRECTORY in Local/Makefile. It is used for holding messages in transit. + +check_log_space and check_log_inodes check the partition in which log files are +written if either is greater than zero. These should be set only if +log_file_path and spool_directory refer to different partitions. + +If there is less space or fewer inodes than requested, Exim refuses to accept +incoming mail. In the case of SMTP input this is done by giving a 452 temporary +error response to the MAIL command. If ESMTP is in use and there was a SIZE +parameter on the MAIL command, its value is added to the check_spool_space +value, and the check is performed even if check_spool_space is zero, unless +no_smtp_check_spool_space is set. + +The values for check_spool_space and check_log_space are held as a number of +kilobytes (though specified in bytes). If a non-multiple of 1024 is specified, +it is rounded up. + +For non-SMTP input and for batched SMTP input, the test is done at start-up; on +failure a message is written to stderr and Exim exits with a non-zero code, as +it obviously cannot send an error message of any kind. + +There is a slight performance penalty for these checks. Versions of Exim +preceding 4.88 had these disabled by default; high-rate installations confident +they will never run out of resources may wish to deliberately disable them. + ++--------------------------------------------------------------+ +|chunking_advertise_hosts|Use: main|Type: host list*|Default: *| ++--------------------------------------------------------------+ + +The CHUNKING extension (RFC3030) will be advertised in the EHLO message to +these hosts. Hosts may use the BDAT command as an alternate to DATA. + ++-------------------------------------------------------------------------+ +|commandline_checks_require_admin|Use: main|Type: boolean|Default: "false"| ++-------------------------------------------------------------------------+ + +This option restricts various basic checking features to require an +administrative user. This affects most of the -b* options, such as -be. + ++----------------------------------------------------+ +|debug_store|Use: main|Type: boolean|Default: "false"| ++----------------------------------------------------+ + +This option, when true, enables extra checking in Exim's internal memory +management. For use when a memory corruption issue is being investigated, it +should normally be left as default. + ++--------------------------------------------------------+ +|daemon_smtp_ports|Use: main|Type: string|Default: "smtp"| ++--------------------------------------------------------+ + +This option specifies one or more default SMTP ports on which the Exim daemon +listens. See chapter 13 for details of how it is used. For backward +compatibility, daemon_smtp_port (singular) is a synonym. + ++---------------------------------------------------------+ +|daemon_startup_retries|Use: main|Type: integer|Default: 9| ++---------------------------------------------------------+ + +This option, along with daemon_startup_sleep, controls the retrying done by the +daemon at startup when it cannot immediately bind a listening socket (typically +because the socket is already in use): daemon_startup_retries defines the +number of retries after the first failure, and daemon_startup_sleep defines the +length of time to wait between retries. + ++------------------------------------------------------+ +|daemon_startup_sleep|Use: main|Type: time|Default: 30s| ++------------------------------------------------------+ + +See daemon_startup_retries. + ++----------------------------------------------------+ +|delay_warning|Use: main|Type: time list|Default: 24h| ++----------------------------------------------------+ + +When a message is delayed, Exim sends a warning message to the sender at +intervals specified by this option. The data is a colon-separated list of times +after which to send warning messages. If the value of the option is an empty +string or a zero time, no warnings are sent. Up to 10 times may be given. If a +message has been in the queue for longer than the last time, the last interval +between the times is used to compute subsequent warning times. For example, +with + +delay_warning = 4h:8h:24h + +the first message is sent after 4 hours, the second after 8 hours, and the +third one after 24 hours. After that, messages are sent every 16 hours, because +that is the interval between the last two times on the list. If you set just +one time, it specifies the repeat interval. For example, with: + +delay_warning = 6h + +messages are repeated every six hours. To stop warnings after a given time, set +a very large time at the end of the list. For example: + +delay_warning = 2h:12h:99d + +Note that the option is only evaluated at the time a delivery attempt fails, +which depends on retry and queue-runner configuration. Typically retries will +be configured more frequently than warning messages. + ++------------------------------------------------------------------+ +|delay_warning_condition|Use: main|Type: string*|Default: see below| ++------------------------------------------------------------------+ + +The string is expanded at the time a warning message might be sent. If all the +deferred addresses have the same domain, it is set in $domain during the +expansion. Otherwise $domain is empty. If the result of the expansion is a +forced failure, an empty string, or a string matching any of "0", "no" or +"false" (the comparison being done caselessly) then the warning message is not +sent. The default is: + +delay_warning_condition = ${if or {\ + { !eq{$h_list-id:$h_list-post:$h_list-subscribe:}{} }\ + { match{$h_precedence:}{(?i)bulk|list|junk} }\ + { match{$h_auto-submitted:}{(?i)auto-generated|auto-replied} }\ + } {no}{yes}} + +This suppresses the sending of warnings for messages that contain List-ID:, +List-Post:, or List-Subscribe: headers, or have "bulk", "list" or "junk" in a +Precedence: header, or have "auto-generated" or "auto-replied" in an +Auto-Submitted: header. + ++-------------------------------------------------------------+ +|deliver_drop_privilege|Use: main|Type: boolean|Default: false| ++-------------------------------------------------------------+ + +If this option is set true, Exim drops its root privilege at the start of a +delivery process, and runs as the Exim user throughout. This severely restricts +the kinds of local delivery that are possible, but is viable in certain types +of configuration. There is a discussion about the use of root privilege in +chapter 55. + ++-----------------------------------------------------------------+ +|deliver_queue_load_max|Use: main|Type: fixed-point|Default: unset| ++-----------------------------------------------------------------+ + +When this option is set, a queue run is abandoned if the system load average +becomes greater than the value of the option. The option has no effect on +ancient operating systems on which Exim cannot determine the load average. See +also queue_only_load and smtp_load_reserve. + ++----------------------------------------------------------+ +|delivery_date_remove|Use: main|Type: boolean|Default: true| ++----------------------------------------------------------+ + +Exim's transports have an option for adding a Delivery-date: header to a +message when it is delivered, in exactly the same way as Return-path: is +handled. Delivery-date: records the actual time of delivery. Such headers +should not be present in incoming messages, and this option causes them to be +removed at the time the message is received, to avoid any problems that might +occur when a delivered message is subsequently sent on to some other recipient. + ++----------------------------------------------------+ +|disable_fsync|Use: main|Type: boolean|Default: false| ++----------------------------------------------------+ + +This option is available only if Exim was built with the compile-time option +ENABLE_DISABLE_FSYNC. When this is not set, a reference to disable_fsync in a +runtime configuration generates an "unknown option" error. You should not build +Exim with ENABLE_DISABLE_FSYNC or set disable_fsync unless you really, really, +really understand what you are doing. No pre-compiled distributions of Exim +should ever make this option available. + +When disable_fsync is set true, Exim no longer calls fsync() to force updated +files' data to be written to disc before continuing. Unexpected events such as +crashes and power outages may cause data to be lost or scrambled. Here be +Dragons. Beware. + ++---------------------------------------------------+ +|disable_ipv6|Use: main|Type: boolean|Default: false| ++---------------------------------------------------+ + +If this option is set true, even if the Exim binary has IPv6 support, no IPv6 +activities take place. AAAA records are never looked up, and any IPv6 addresses +that are listed in local_interfaces, data for the manualroute router, etc. are +ignored. If IP literals are enabled, the ipliteral router declines to handle +IPv6 literal addresses. + ++-----------------------------------------------------------------------+ +|dkim_verify_signers|Use: main|Type: domain list*|Default: $dkim_signers| ++-----------------------------------------------------------------------+ + +This option gives a list of DKIM domains for which the DKIM ACL is run. It is +expanded after the message is received; by default it runs the ACL once for +each signature in the message. See section 57.3. + ++--------------------------------------------------------------------+ +|dns_again_means_nonexist|Use: main|Type: domain list*|Default: unset| ++--------------------------------------------------------------------+ + +DNS lookups give a "try again" response for the DNS errors "non-authoritative +host not found" and "SERVERFAIL". This can cause Exim to keep trying to deliver +a message, or to give repeated temporary errors to incoming mail. Sometimes the +effect is caused by a badly set up name server and may persist for a long time. +If a domain which exhibits this problem matches anything in +dns_again_means_nonexist, it is treated as if it did not exist. This option +should be used with care. You can make it apply to reverse lookups by a setting +such as this: + +dns_again_means_nonexist = *.in-addr.arpa + +This option applies to all DNS lookups that Exim does. It also applies when the +gethostbyname() or getipnodebyname() functions give temporary errors, since +these are most likely to be caused by DNS lookup problems. The dnslookup router +has some options of its own for controlling what happens when lookups for MX or +SRV records give temporary errors. These more specific options are applied +after this global option. + ++-----------------------------------------------------------------+ +|dns_check_names_pattern|Use: main|Type: string|Default: see below| ++-----------------------------------------------------------------+ + +When this option is set to a non-empty string, it causes Exim to check domain +names for characters that are not allowed in host names before handing them to +the DNS resolver, because some resolvers give temporary errors for names that +contain unusual characters. If a domain name contains any unwanted characters, +a "not found" result is forced, and the resolver is not called. The check is +done by matching the domain name against a regular expression, which is the +value of this option. The default pattern is + +dns_check_names_pattern = \ + (?i)^(?>(?(1)\.|())[^\W_](?>[a-z0-9/-]*[^\W_])?)+$ + +which permits only letters, digits, slashes, and hyphens in components, but +they must start and end with a letter or digit. Slashes are not, in fact, +permitted in host names, but they are found in certain NS records (which can be +accessed in Exim by using a dnsdb lookup). If you set allow_utf8_domains, you +must modify this pattern, or set the option to an empty string. + ++-------------------------------------------------------+ +|dns_csa_search_limit|Use: main|Type: integer|Default: 5| ++-------------------------------------------------------+ + +This option controls the depth of parental searching for CSA SRV records in the +DNS, as described in more detail in section 43.50. + ++---------------------------------------------------------+ +|dns_csa_use_reverse|Use: main|Type: boolean|Default: true| ++---------------------------------------------------------+ + +This option controls whether or not an IP address, given as a CSA domain, is +reversed and looked up in the reverse DNS, as described in more detail in +section 43.50. + ++--------------------------------------------------+ +|dns_cname_loops|Use: main|Type: integer|Default: 1| ++--------------------------------------------------+ + +This option controls the following of CNAME chains, needed if the resolver does +not do it internally. As of 2018 most should, and the default can be left. If +you have an ancient one, a value of 10 is likely needed. + +The default value of one CNAME-follow is needed thanks to the observed return +for an MX request, given no MX presence but a CNAME to an A, of the CNAME. + ++-------------------------------------------------+ +|dns_dnssec_ok|Use: main|Type: integer|Default: -1| ++-------------------------------------------------+ + +If this option is set to a non-negative number then Exim will initialise the +DNS resolver library to either use or not use DNSSEC, overriding the system +default. A value of 0 coerces DNSSEC off, a value of 1 coerces DNSSEC on. + +If the resolver library does not support DNSSEC then this option has no effect. + ++-----------------------------------------------------------+ +|dns_ipv4_lookup|Use: main|Type: domain list*|Default: unset| ++-----------------------------------------------------------+ + +When Exim is compiled with IPv6 support and disable_ipv6 is not set, it looks +for IPv6 address records (AAAA records) as well as IPv4 address records (A +records) when trying to find IP addresses for hosts, unless the host's domain +matches this list. + +This is a fudge to help with name servers that give big delays or otherwise do +not work for the AAAA record type. In due course, when the world's name servers +have all been upgraded, there should be no need for this option. + ++--------------------------------------------+ +|dns_retrans|Use: main|Type: time|Default: 0s| ++--------------------------------------------+ + +The options dns_retrans and dns_retry can be used to set the retransmission and +retry parameters for DNS lookups. Values of zero (the defaults) leave the +system default settings unchanged. The first value is the time between retries, +and the second is the number of retries. It isn't totally clear exactly how +these settings affect the total time a DNS lookup may take. I haven't found any +documentation about timeouts on DNS lookups; these parameter values are +available in the external resolver interface structure, but nowhere does it +seem to describe how they are used or what you might want to set in them. See +also the slow_lookup_log option. + ++--------------------------------------------+ +|dns_retry|Use: main|Type: integer|Default: 0| ++--------------------------------------------+ + +See dns_retrans above. + ++--------------------------------------------------------+ +|dns_trust_aa|Use: main|Type: domain list*|Default: unset| ++--------------------------------------------------------+ + +If this option is set then lookup results marked with the AA bit (Authoritative +Answer) are trusted the same way as if they were DNSSEC-verified. The authority +section's name of the answer must match with this expanded domain list. + +Use this option only if you talk directly to a resolver that is authoritative +for some zones and does not set the AD (Authentic Data) bit in the answer. Some +DNS servers may have an configuration option to mark the answers from their own +zones as verified (they set the AD bit). Others do not have this option. It is +considered as poor practice using a resolver that is an authoritative server +for some zones. + +Use this option only if you really have to (e.g. if you want to use DANE for +remote delivery to a server that is listed in the DNS zones that your resolver +is authoritative for). + +If the DNS answer packet has the AA bit set and contains resource record in the +answer section, the name of the first NS record appearing in the authority +section is compared against the list. If the answer packet is authoritative but +the answer section is empty, the name of the first SOA record in the +authoritative section is used instead. + ++-------------------------------------------------+ +|dns_use_edns0|Use: main|Type: integer|Default: -1| ++-------------------------------------------------+ + +If this option is set to a non-negative number then Exim will initialise the +DNS resolver library to either use or not use EDNS0 extensions, overriding the +system default. A value of 0 coerces EDNS0 off, a value of 1 coerces EDNS0 on. + +If the resolver library does not support EDNS0 then this option has no effect. + +OpenBSD's asr resolver routines are known to ignore the EDNS0 option; this +means that DNSSEC will not work with Exim on that platform either, unless Exim +is linked against an alternative DNS client library. + ++----------------------------------------------+ +|drop_cr|Use: main|Type: boolean|Default: false| ++----------------------------------------------+ + +This is an obsolete option that is now a no-op. It used to affect the way Exim +handled CR and LF characters in incoming messages. What happens now is +described in section 47.2. + ++-------------------------------------------------------------+ +|dsn_advertise_hosts|Use: main|Type: host list*|Default: unset| ++-------------------------------------------------------------+ + +DSN extensions (RFC3461) will be advertised in the EHLO message to, and +accepted from, these hosts. Hosts may use the NOTIFY and ENVID options on RCPT +TO commands, and RET and ORCPT options on MAIL FROM commands. A NOTIFY=SUCCESS +option requests success-DSN messages. A NOTIFY= option with no argument +requests that no delay or failure DSNs are sent. + ++---------------------------------------------------+ +|dsn_from|Use: main|Type: string*|Default: see below| ++---------------------------------------------------+ + +This option can be used to vary the contents of From: header lines in bounces +and other automatically generated messages ("Delivery Status Notifications" - +hence the name of the option). The default setting is: + +dsn_from = Mail Delivery System <Mailer-Daemon@$qualify_domain> + +The value is expanded every time it is needed. If the expansion fails, a panic +is logged, and the default value is used. + ++--------------------------------------------------------+ +|envelope_to_remove|Use: main|Type: boolean|Default: true| ++--------------------------------------------------------+ + +Exim's transports have an option for adding an Envelope-to: header to a message +when it is delivered, in exactly the same way as Return-path: is handled. +Envelope-to: records the original recipient address from the message's envelope +that caused the delivery to happen. Such headers should not be present in +incoming messages, and this option causes them to be removed at the time the +message is received, to avoid any problems that might occur when a delivered +message is subsequently sent on to some other recipient. + ++-------------------------------------------------------+ +|errors_copy|Use: main|Type: string list*|Default: unset| ++-------------------------------------------------------+ + +Setting this option causes Exim to send bcc copies of bounce messages that it +generates to other addresses. Note: This does not apply to bounce messages +coming from elsewhere. The value of the option is a colon-separated list of +items. Each item consists of a pattern, terminated by white space, followed by +a comma-separated list of email addresses. If a pattern contains spaces, it +must be enclosed in double quotes. + +Each pattern is processed in the same way as a single item in an address list +(see section 10.19). When a pattern matches the recipient of the bounce +message, the message is copied to the addresses on the list. The items are +scanned in order, and once a matching one is found, no further items are +examined. For example: + +errors_copy = spqr@mydomain postmaster@mydomain.example :\ + rqps@mydomain hostmaster@mydomain.example,\ + postmaster@mydomain.example + +The address list is expanded before use. The expansion variables $local_part +and $domain are set from the original recipient of the error message, and if +there was any wildcard matching in the pattern, the expansion variables $0, $1, +etc. are set in the normal way. + ++-----------------------------------------------------+ +|errors_reply_to|Use: main|Type: string|Default: unset| ++-----------------------------------------------------+ + +By default, Exim's bounce and delivery warning messages contain the header line + +From: Mail Delivery System <Mailer-Daemon@qualify-domain> + +where qualify-domain is the value of the qualify_domain option. A warning +message that is generated by the quota_warn_message option in an appendfile +transport may contain its own From: header line that overrides the default. + +Experience shows that people reply to bounce messages. If the errors_reply_to +option is set, a Reply-To: header is added to bounce and warning messages. For +example: + +errors_reply_to = postmaster@my.domain.example + +The value of the option is not expanded. It must specify a valid RFC 2822 +address. However, if a warning message that is generated by the +quota_warn_message option in an appendfile transport contain its own Reply-To: +header line, the value of the errors_reply_to option is not used. + ++---------------------------------------------------+ +|event_action|Use: main|Type: string*|Default: unset| ++---------------------------------------------------+ + +This option declares a string to be expanded for Exim's events mechanism. For +details see chapter 60. + ++------------------------------------------------------------------+ +|exim_group|Use: main|Type: string|Default: compile-time configured| ++------------------------------------------------------------------+ + +This option changes the gid under which Exim runs when it gives up root +privilege. The default value is compiled into the binary. The value of this +option is used only when exim_user is also set. Unless it consists entirely of +digits, the string is looked up using getgrnam(), and failure causes a +configuration error. See chapter 55 for a discussion of security issues. + ++---------------------------------------------------+ +|exim_path|Use: main|Type: string|Default: see below| ++---------------------------------------------------+ + +This option specifies the path name of the Exim binary, which is used when Exim +needs to re-exec itself. The default is set up to point to the file exim in the +directory configured at compile time by the BIN_DIRECTORY setting. It is +necessary to change exim_path if, exceptionally, Exim is run from some other +place. Warning: Do not use a macro to define the value of this option, because +you will break those Exim utilities that scan the configuration file to find +where the binary is. (They then use the -bP option to extract option settings +such as the value of spool_directory.) + ++-----------------------------------------------------------------+ +|exim_user|Use: main|Type: string|Default: compile-time configured| ++-----------------------------------------------------------------+ + +This option changes the uid under which Exim runs when it gives up root +privilege. The default value is compiled into the binary. Ownership of the run +time configuration file and the use of the -C and -D command line options is +checked against the values in the binary, not what is set here. + +Unless it consists entirely of digits, the string is looked up using getpwnam() +, and failure causes a configuration error. If exim_group is not also supplied, +the gid is taken from the result of getpwnam() if it is used. See chapter 55 +for a discussion of security issues. + ++-----------------------------------------------------------------+ +|extra_local_interfaces|Use: main|Type: string list|Default: unset| ++-----------------------------------------------------------------+ + +This option defines network interfaces that are to be considered local when +routing, but which are not used for listening by the daemon. See section 13.8 +for details. + ++------------------------------------------------------------------------+ +|extract_addresses_remove_arguments|Use: main|Type: boolean|Default: true| ++------------------------------------------------------------------------+ + +According to some Sendmail documentation (Sun, IRIX, HP-UX), if any addresses +are present on the command line when the -t option is used to build an envelope +from a message's To:, Cc: and Bcc: headers, the command line addresses are +removed from the recipients list. This is also how Smail behaves. However, +other Sendmail documentation (the O'Reilly book) states that command line +addresses are added to those obtained from the header lines. When +extract_addresses_remove_arguments is true (the default), Exim subtracts +argument headers. If it is set false, Exim adds rather than removes argument +addresses. + ++---------------------------------------------------+ +|finduser_retries|Use: main|Type: integer|Default: 0| ++---------------------------------------------------+ + +On systems running NIS or other schemes in which user and group information is +distributed from a remote system, there can be times when getpwnam() and +related functions fail, even when given valid data, because things time out. +Unfortunately these failures cannot be distinguished from genuine "not found" +errors. If finduser_retries is set greater than zero, Exim will try that many +extra times to find a user or a group, waiting for one second between retries. + +You should not set this option greater than zero if your user information is in +a traditional /etc/passwd file, because it will cause Exim needlessly to search +the file multiple times for non-existent users, and also cause delay. + ++-----------------------------------------------------------------------+ +|freeze_tell|Use: main|Type: string list, comma separated|Default: unset| ++-----------------------------------------------------------------------+ + +On encountering certain errors, or when configured to do so in a system filter, +ACL, or special router, Exim freezes a message. This means that no further +delivery attempts take place until an administrator thaws the message, or the +auto_thaw, ignore_bounce_errors_after, or timeout_frozen_after feature cause it +to be processed. If freeze_tell is set, Exim generates a warning message +whenever it freezes something, unless the message it is freezing is a +locally-generated bounce message. (Without this exception there is the +possibility of looping.) The warning message is sent to the addresses supplied +as the comma-separated value of this option. If several of the message's +addresses cause freezing, only a single message is sent. If the freezing was +automatic, the reason(s) for freezing can be found in the message log. If you +configure freezing in a filter or ACL, you must arrange for any logging that +you require. + ++-------------------------------------------------+ +|gecos_name|Use: main|Type: string*|Default: unset| ++-------------------------------------------------+ + +Some operating systems, notably HP-UX, use the "gecos" field in the system +password file to hold other information in addition to users' real names. Exim +looks up this field for use when it is creating Sender: or From: headers. If +either gecos_pattern or gecos_name are unset, the contents of the field are +used unchanged, except that, if an ampersand is encountered, it is replaced by +the user's login name with the first character forced to upper case, since this +is a convention that is observed on many systems. + +When these options are set, gecos_pattern is treated as a regular expression +that is to be applied to the field (again with & replaced by the login name), +and if it matches, gecos_name is expanded and used as the user's name. + +Numeric variables such as $1, $2, etc. can be used in the expansion to pick up +sub-fields that were matched by the pattern. In HP-UX, where the user's name +terminates at the first comma, the following can be used: + +gecos_pattern = ([^,]*) +gecos_name = $1 + ++---------------------------------------------------+ +|gecos_pattern|Use: main|Type: string|Default: unset| ++---------------------------------------------------+ + +See gecos_name above. + ++---------------------------------------------------------+ +|gnutls_compat_mode|Use: main|Type: boolean|Default: unset| ++---------------------------------------------------------+ + +This option controls whether GnuTLS is used in compatibility mode in an Exim +server. This reduces security slightly, but improves interworking with older +implementations of TLS. + ++---------------------------------------------------------------+ +|gnutls_allow_auto_pkcs11|Use: main|Type: boolean|Default: unset| ++---------------------------------------------------------------+ + +This option will let GnuTLS (2.12.0 or later) autoload PKCS11 modules with the +p11-kit configuration files in /etc/pkcs11/modules/. + +See https://www.gnutls.org/manual/gnutls.html#Smart-cards-and-HSMs for +documentation. + ++---------------------------------------------------------+ +|headers_charset|Use: main|Type: string|Default: see below| ++---------------------------------------------------------+ + +This option sets a default character set for translating from encoded MIME +"words" in header lines, when referenced by an $h_xxx expansion item. The +default is the value of HEADERS_CHARSET in Local/Makefile. The ultimate default +is ISO-8859-1. For more details see the description of header insertions in +section 11.5. + ++---------------------------------------------------------+ +|header_maxsize|Use: main|Type: integer|Default: see below| ++---------------------------------------------------------+ + +This option controls the overall maximum size of a message's header section. +The default is the value of HEADER_MAXSIZE in Local/Makefile; the default for +that is 1M. Messages with larger header sections are rejected. + ++------------------------------------------------------+ +|header_line_maxsize|Use: main|Type: integer|Default: 0| ++------------------------------------------------------+ + +This option limits the length of any individual header line in a message, after +all the continuations have been joined together. Messages with individual +header lines that are longer than the limit are rejected. The default value of +zero means "no limit". + ++----------------------------------------------------------------+ +|helo_accept_junk_hosts|Use: main|Type: host list*|Default: unset| ++----------------------------------------------------------------+ + +Exim checks the syntax of HELO and EHLO commands for incoming SMTP mail, and +gives an error response for invalid data. Unfortunately, there are some SMTP +clients that send syntactic junk. They can be accommodated by setting this +option. Note that this is a syntax check only. See helo_verify_hosts if you +want to do semantic checking. See also helo_allow_chars for a way of extending +the permitted character set. + ++------------------------------------------------------+ +|helo_allow_chars|Use: main|Type: string|Default: unset| ++------------------------------------------------------+ + +This option can be set to a string of rogue characters that are permitted in +all EHLO and HELO names in addition to the standard letters, digits, hyphens, +and dots. If you really must allow underscores, you can set + +helo_allow_chars = _ + +Note that the value is one string, not a list. + ++-----------------------------------------------------------------+ +|helo_lookup_domains|Use: main|Type: domain list*|Default: "@:@[]"| ++-----------------------------------------------------------------+ + +If the domain given by a client in a HELO or EHLO command matches this list, a +reverse lookup is done in order to establish the host's true name. The default +forces a lookup if the client host gives the server's name or any of its IP +addresses (in brackets), something that broken clients have been seen to do. + ++---------------------------------------------------------------+ +|helo_try_verify_hosts|Use: main|Type: host list*|Default: unset| ++---------------------------------------------------------------+ + +By default, Exim just checks the syntax of HELO and EHLO commands (see +helo_accept_junk_hosts and helo_allow_chars). However, some sites like to do +more extensive checking of the data supplied by these commands. The ACL +condition "verify = helo" is provided to make this possible. Formerly, it was +necessary also to set this option (helo_try_verify_hosts) to force the check to +occur. From release 4.53 onwards, this is no longer necessary. If the check has +not been done before "verify = helo" is encountered, it is done at that time. +Consequently, this option is obsolete. Its specification is retained here for +backwards compatibility. + +When an EHLO or HELO command is received, if the calling host matches +helo_try_verify_hosts, Exim checks that the host name given in the HELO or EHLO +command either: + + * is an IP literal matching the calling address of the host, or + + * matches the host name that Exim obtains by doing a reverse lookup of the + calling host address, or + + * when looked up in DNS yields the calling host address. + +However, the EHLO or HELO command is not rejected if any of the checks fail. +Processing continues, but the result of the check is remembered, and can be +detected later in an ACL by the "verify = helo" condition. + +If DNS was used for successful verification, the variable $helo_verify_dnssec +records the DNSSEC status of the lookups. + ++-----------------------------------------------------------+ +|helo_verify_hosts|Use: main|Type: host list*|Default: unset| ++-----------------------------------------------------------+ + +Like helo_try_verify_hosts, this option is obsolete, and retained only for +backwards compatibility. For hosts that match this option, Exim checks the host +name given in the HELO or EHLO in the same way as for helo_try_verify_hosts. If +the check fails, the HELO or EHLO command is rejected with a 550 error, and +entries are written to the main and reject logs. If a MAIL command is received +before EHLO or HELO, it is rejected with a 503 error. + ++--------------------------------------------------------+ +|hold_domains|Use: main|Type: domain list*|Default: unset| ++--------------------------------------------------------+ + +This option allows mail for particular domains to be held in the queue +manually. The option is overridden if a message delivery is forced with the -M, +-qf, -Rf or -Sf options, and also while testing or verifying addresses using +-bt or -bv. Otherwise, if a domain matches an item in hold_domains, no routing +or delivery for that address is done, and it is deferred every time the message +is looked at. + +This option is intended as a temporary operational measure for delaying the +delivery of mail while some problem is being sorted out, or some new +configuration tested. If you just want to delay the processing of some domains +until a queue run occurs, you should use queue_domains or queue_smtp_domains, +not hold_domains. + +A setting of hold_domains does not override Exim's code for removing messages +from the queue if they have been there longer than the longest retry time in +any retry rule. If you want to hold messages for longer than the normal retry +times, insert a dummy retry rule with a long retry time. + ++-----------------------------------------------------+ +|host_lookup|Use: main|Type: host list*|Default: unset| ++-----------------------------------------------------+ + +Exim does not look up the name of a calling host from its IP address unless it +is required to compare against some host list, or the host matches +helo_try_verify_hosts or helo_verify_hosts, or the host matches this option +(which normally contains IP addresses rather than host names). The default +configuration file contains + +host_lookup = * + +which causes a lookup to happen for all hosts. If the expense of these lookups +is felt to be too great, the setting can be changed or removed. + +After a successful reverse lookup, Exim does a forward lookup on the name it +has obtained, to verify that it yields the IP address that it started with. If +this check fails, Exim behaves as if the name lookup failed. + +After any kind of failure, the host name (in $sender_host_name) remains unset, +and $host_lookup_failed is set to the string "1". See also +dns_again_means_nonexist, helo_lookup_domains, and "verify = +reverse_host_lookup" in ACLs. + ++---------------------------------------------------------------------+ +|host_lookup_order|Use: main|Type: string list|Default: "bydns:byaddr"| ++---------------------------------------------------------------------+ + +This option specifies the order of different lookup methods when Exim is trying +to find a host name from an IP address. The default is to do a DNS lookup +first, and then to try a local lookup (using gethostbyaddr() or equivalent) if +that fails. You can change the order of these lookups, or omit one entirely, if +you want. + +Warning: The "byaddr" method does not always yield aliases when there are +multiple PTR records in the DNS and the IP address is not listed in /etc/hosts. +Different operating systems give different results in this case. That is why +the default tries a DNS lookup first. + ++----------------------------------------------------------------+ +|host_reject_connection|Use: main|Type: host list*|Default: unset| ++----------------------------------------------------------------+ + +If this option is set, incoming SMTP calls from the hosts listed are rejected +as soon as the connection is made. This option is obsolete, and retained only +for backward compatibility, because nowadays the ACL specified by +acl_smtp_connect can also reject incoming connections immediately. + +The ability to give an immediate rejection (either by this option or using an +ACL) is provided for use in unusual cases. Many hosts will just try again, +sometimes without much delay. Normally, it is better to use an ACL to reject +incoming messages at a later stage, such as after RCPT commands. See chapter 43 +. + ++----------------------------------------------------------------+ +|hosts_connection_nolog|Use: main|Type: host list*|Default: unset| ++----------------------------------------------------------------+ + +This option defines a list of hosts for which connection logging does not +happen, even though the smtp_connection log selector is set. For example, you +might want not to log SMTP connections from local processes, or from 127.0.0.1, +or from your local LAN. This option is consulted in the main loop of the +daemon; you should therefore strive to restrict its value to a short inline +list of IP addresses and networks. To disable logging SMTP connections from +local processes, you must create a host list with an empty item. For example: + +hosts_connection_nolog = : + +If the smtp_connection log selector is not set, this option has no effect. + ++-----------------------------------------------------+ +|hosts_proxy|Use: main|Type: host list*|Default: unset| ++-----------------------------------------------------+ + +This option enables use of Proxy Protocol proxies for incoming connections. For +details see section 58.1. + ++----------------------------------------------------------------+ +|hosts_treat_as_local|Use: main|Type: domain list*|Default: unset| ++----------------------------------------------------------------+ + +If this option is set, any host names that match the domain list are treated as +if they were the local host when Exim is scanning host lists obtained from MX +records or other sources. Note that the value of this option is a domain list, +not a host list, because it is always used to check host names, not IP +addresses. + +This option also applies when Exim is matching the special items "@mx_any", +"@mx_primary", and "@mx_secondary" in a domain list (see section 10.8), and +when checking the hosts option in the smtp transport for the local host (see +the allow_localhost option in that transport). See also local_interfaces, +extra_local_interfaces, and chapter 13, which contains a discussion about local +network interfaces and recognizing the local host. + ++--------------------------------------------------------+ +|ibase_servers|Use: main|Type: string list|Default: unset| ++--------------------------------------------------------+ + +This option provides a list of InterBase servers and associated connection +data, to be used in conjunction with ibase lookups (see section 9.22). The +option is available only if Exim has been built with InterBase support. + ++------------------------------------------------------------+ +|ignore_bounce_errors_after|Use: main|Type: time|Default: 10w| ++------------------------------------------------------------+ + +This option affects the processing of bounce messages that cannot be delivered, +that is, those that suffer a permanent delivery failure. (Bounce messages that +suffer temporary delivery failures are of course retried in the usual way.) + +After a permanent delivery failure, bounce messages are frozen, because there +is no sender to whom they can be returned. When a frozen bounce message has +been in the queue for more than the given time, it is unfrozen at the next +queue run, and a further delivery is attempted. If delivery fails again, the +bounce message is discarded. This makes it possible to keep failed bounce +messages around for a shorter time than the normal maximum retry time for +frozen messages. For example, + +ignore_bounce_errors_after = 12h + +retries failed bounce message deliveries after 12 hours, discarding any further +failures. If the value of this option is set to a zero time period, bounce +failures are discarded immediately. Setting a very long time (as in the default +value) has the effect of disabling this option. For ways of automatically +dealing with other kinds of frozen message, see auto_thaw and +timeout_frozen_after. + ++---------------------------------------------------------------+ +|ignore_fromline_hosts|Use: main|Type: host list*|Default: unset| ++---------------------------------------------------------------+ + +Some broken SMTP clients insist on sending a UUCP-like "From " line before the +headers of a message. By default this is treated as the start of the message's +body, which means that any following headers are not recognized as such. Exim +can be made to ignore it by setting ignore_fromline_hosts to match those hosts +that insist on sending it. If the sender is actually a local process rather +than a remote host, and is using -bs to inject the messages, +ignore_fromline_local must be set to achieve this effect. + ++------------------------------------------------------------+ +|ignore_fromline_local|Use: main|Type: boolean|Default: false| ++------------------------------------------------------------+ + +See ignore_fromline_hosts above. + ++-----------------------------------------------------------+ +|keep_environment|Use: main|Type: string list|Default: unset| ++-----------------------------------------------------------+ + +This option contains a string list of environment variables to keep. You have +to trust these variables or you have to be sure that these variables do not +impose any security risk. Keep in mind that during the startup phase Exim is +running with an effective UID 0 in most installations. As the default value is +an empty list, the default environment for using libraries, running embedded +Perl code, or running external binaries is empty, and does not not even contain +PATH or HOME. + +Actually the list is interpreted as a list of patterns (10.1), except that it +is not expanded first. + +WARNING: Macro substitution is still done first, so having a macro FOO and +having FOO_HOME in your keep_environment option may have unexpected results. +You may work around this using a regular expression that does not match the +macro name: ^[F]OO_HOME$. + +Current versions of Exim issue a warning during startup if you do not mention +keep_environment in your runtime configuration file and if your current +environment is not empty. Future versions may not issue that warning anymore. + +See the add_environment main config option for a way to set environment +variables to a fixed value. The environment for pipe transports is handled +separately, see section 29.4 for details. + ++-----------------------------------------------+ +|keep_malformed|Use: main|Type: time|Default: 4d| ++-----------------------------------------------+ + +This option specifies the length of time to keep messages whose spool files +have been corrupted in some way. This should, of course, never happen. At the +next attempt to deliver such a message, it gets removed. The incident is +logged. + ++------------------------------------------------------+ +|ldap_ca_cert_dir|Use: main|Type: string|Default: unset| ++------------------------------------------------------+ + +This option indicates which directory contains CA certificates for verifying a +TLS certificate presented by an LDAP server. While Exim does not provide a +default value, your SSL library may. Analogous to tls_verify_certificates but +as a client-side option for LDAP and constrained to be a directory. + ++-------------------------------------------------------+ +|ldap_ca_cert_file|Use: main|Type: string|Default: unset| ++-------------------------------------------------------+ + +This option indicates which file contains CA certificates for verifying a TLS +certificate presented by an LDAP server. While Exim does not provide a default +value, your SSL library may. Analogous to tls_verify_certificates but as a +client-side option for LDAP and constrained to be a file. + ++----------------------------------------------------+ +|ldap_cert_file|Use: main|Type: string|Default: unset| ++----------------------------------------------------+ + +This option indicates which file contains an TLS client certificate which Exim +should present to the LDAP server during TLS negotiation. Should be used +together with ldap_cert_key. + ++---------------------------------------------------+ +|ldap_cert_key|Use: main|Type: string|Default: unset| ++---------------------------------------------------+ + +This option indicates which file contains the secret/private key to use to +prove identity to the LDAP server during TLS negotiation. Should be used +together with ldap_cert_file, which contains the identity to be proven. + ++-------------------------------------------------------+ +|ldap_cipher_suite|Use: main|Type: string|Default: unset| ++-------------------------------------------------------+ + +This controls the TLS cipher-suite negotiation during TLS negotiation with the +LDAP server. See 42.4 for more details of the format of cipher-suite options +with OpenSSL (as used by LDAP client libraries). + ++---------------------------------------------------------------+ +|ldap_default_servers|Use: main|Type: string list|Default: unset| ++---------------------------------------------------------------+ + +This option provides a list of LDAP servers which are tried in turn when an +LDAP query does not contain a server. See section 9.15 for details of LDAP +queries. This option is available only when Exim has been built with LDAP +support. + ++--------------------------------------------------------+ +|ldap_require_cert|Use: main|Type: string|Default: unset.| ++--------------------------------------------------------+ + +This should be one of the values "hard", "demand", "allow", "try" or "never". A +value other than one of these is interpreted as "never". See the entry +"TLS_REQCERT" in your system man page for ldap.conf(5). Although Exim does not +set a default, the LDAP library probably defaults to hard/demand. + ++-----------------------------------------------------+ +|ldap_start_tls|Use: main|Type: boolean|Default: false| ++-----------------------------------------------------+ + +If set, Exim will attempt to negotiate TLS with the LDAP server when connecting +on a regular LDAP port. This is the LDAP equivalent of SMTP's "STARTTLS". This +is distinct from using "ldaps", which is the LDAP form of SSL-on-connect. In +the event of failure to negotiate TLS, the action taken is controlled by +ldap_require_cert. This option is ignored for "ldapi" connections. + ++---------------------------------------------------+ +|ldap_version|Use: main|Type: integer|Default: unset| ++---------------------------------------------------+ + +This option can be used to force Exim to set a specific protocol version for +LDAP. If it option is unset, it is shown by the -bP command line option as -1. +When this is the case, the default is 3 if LDAP_VERSION3 is defined in the LDAP +headers; otherwise it is 2. This option is available only when Exim has been +built with LDAP support. + ++------------------------------------------------------+ +|local_from_check|Use: main|Type: boolean|Default: true| ++------------------------------------------------------+ + +When a message is submitted locally (that is, not over a TCP/IP connection) by +an untrusted user, Exim removes any existing Sender: header line, and checks +that the From: header line matches the login of the calling user and the domain +specified by qualify_domain. + +Note: An unqualified address (no domain) in the From: header in a locally +submitted message is automatically qualified by Exim, unless the -bnq command +line option is used. + +You can use local_from_prefix and local_from_suffix to permit affixes on the +local part. If the From: header line does not match, Exim adds a Sender: header +with an address constructed from the calling user's login and the default +qualify domain. + +If local_from_check is set false, the From: header check is disabled, and no +Sender: header is ever added. If, in addition, you want to retain Sender: +header lines supplied by untrusted users, you must also set local_sender_retain +to be true. + +These options affect only the header lines in the message. The envelope sender +is still forced to be the login id at the qualify domain unless +untrusted_set_sender permits the user to supply an envelope sender. + +For messages received over TCP/IP, an ACL can specify "submission mode" to +request similar header line checking. See section 47.16, which has more details +about Sender: processing. + ++-------------------------------------------------------+ +|local_from_prefix|Use: main|Type: string|Default: unset| ++-------------------------------------------------------+ + +When Exim checks the From: header line of locally submitted messages for +matching the login id (see local_from_check above), it can be configured to +ignore certain prefixes and suffixes in the local part of the address. This is +done by setting local_from_prefix and/or local_from_suffix to appropriate +lists, in the same form as the local_part_prefix and local_part_suffix router +options (see chapter 15). For example, if + +local_from_prefix = *- + +is set, a From: line containing + +From: anything-user@your.domain.example + +will not cause a Sender: header to be added if user@your.domain.example matches +the actual sender address that is constructed from the login name and qualify +domain. + ++-------------------------------------------------------+ +|local_from_suffix|Use: main|Type: string|Default: unset| ++-------------------------------------------------------+ + +See local_from_prefix above. + ++---------------------------------------------------------------+ +|local_interfaces|Use: main|Type: string list|Default: see below| ++---------------------------------------------------------------+ + +This option controls which network interfaces are used by the daemon for +listening; they are also used to identify the local host when routing. Chapter +13 contains a full description of this option and the related options +daemon_smtp_ports, extra_local_interfaces, hosts_treat_as_local, and +tls_on_connect_ports. The default value for local_interfaces is + +local_interfaces = 0.0.0.0 + +when Exim is built without IPv6 support; otherwise it is + +local_interfaces = <; ::0 ; 0.0.0.0 + ++---------------------------------------------------+ +|local_scan_timeout|Use: main|Type: time|Default: 5m| ++---------------------------------------------------+ + +This timeout applies to the local_scan() function (see chapter 45). Zero means +"no timeout". If the timeout is exceeded, the incoming message is rejected with +a temporary error if it is an SMTP message. For a non-SMTP message, the message +is dropped and Exim ends with a non-zero code. The incident is logged on the +main and reject logs. + ++----------------------------------------------------------+ +|local_sender_retain|Use: main|Type: boolean|Default: false| ++----------------------------------------------------------+ + +When a message is submitted locally (that is, not over a TCP/IP connection) by +an untrusted user, Exim removes any existing Sender: header line. If you do not +want this to happen, you must set local_sender_retain, and you must also set +local_from_check to be false (Exim will complain if you do not). See also the +ACL modifier "control = suppress_local_fixups". Section 47.16 has more details +about Sender: processing. + ++-------------------------------------------------------+ +|localhost_number|Use: main|Type: string*|Default: unset| ++-------------------------------------------------------+ + +Exim's message ids are normally unique only within the local host. If +uniqueness among a set of hosts is required, each host must set a different +value for the localhost_number option. The string is expanded immediately after +reading the configuration file (so that a number can be computed from the host +name, for example) and the result of the expansion must be a number in the +range 0-16 (or 0-10 on operating systems with case-insensitive file systems). +This is available in subsequent string expansions via the variable +$localhost_number. When localhost_number is set, the final two characters of +the message id, instead of just being a fractional part of the time, are +computed from the time and the local host number as described in section 3.4. + ++-----------------------------------------------------------------------+ +|log_file_path|Use: main|Type: string list*|Default: set at compile time| ++-----------------------------------------------------------------------+ + +This option sets the path which is used to determine the names of Exim's log +files, or indicates that logging is to be to syslog, or both. It is expanded +when Exim is entered, so it can, for example, contain a reference to the host +name. If no specific path is set for the log files at compile or runtime, or if +the option is unset at runtime (i.e. "log_file_path = ") they are written in a +sub-directory called log in Exim's spool directory. Chapter 52 contains further +details about Exim's logging, and section 52.1 describes how the contents of +log_file_path are used. If this string is fixed at your installation (contains +no expansion variables) it is recommended that you do not set this option in +the configuration file, but instead supply the path using LOG_FILE_PATH in +Local/Makefile so that it is available to Exim for logging errors detected +early on - in particular, failure to read the configuration file. + ++--------------------------------------------------+ +|log_selector|Use: main|Type: string|Default: unset| ++--------------------------------------------------+ + +This option can be used to reduce or increase the number of things that Exim +writes to its log files. Its argument is made up of names preceded by plus or +minus characters. For example: + +log_selector = +arguments -retry_defer + +A list of possible names and what they control is given in the chapter on +logging, in section 52.15. + ++---------------------------------------------------+ +|log_timezone|Use: main|Type: boolean|Default: false| ++---------------------------------------------------+ + +By default, the timestamps on log lines are in local time without the timezone. +This means that if your timezone changes twice a year, the timestamps in log +lines are ambiguous for an hour when the clocks go back. One way of avoiding +this problem is to set the timezone to UTC. An alternative is to set +log_timezone true. This turns on the addition of the timezone offset to +timestamps in log lines. Turning on this option can add quite a lot to the size +of log files because each line is extended by 6 characters. Note that the +$tod_log variable contains the log timestamp without the zone, but there is +another variable called $tod_zone that contains just the timezone offset. + ++---------------------------------------------------+ +|lookup_open_max|Use: main|Type: integer|Default: 25| ++---------------------------------------------------+ + +This option limits the number of simultaneously open files for single-key +lookups that use regular files (that is, lsearch, dbm, and cdb). Exim normally +keeps these files open during routing, because often the same file is required +several times. If the limit is reached, Exim closes the least recently used +file. Note that if you are using the ndbm library, it actually opens two files +for each logical DBM database, though it still counts as one for the purposes +of lookup_open_max. If you are getting "too many open files" errors with NDBM, +you need to reduce the value of lookup_open_max. + ++------------------------------------------------------+ +|max_username_length|Use: main|Type: integer|Default: 0| ++------------------------------------------------------+ + +Some operating systems are broken in that they truncate long arguments to +getpwnam() to eight characters, instead of returning "no such user". If this +option is set greater than zero, any attempt to call getpwnam() with an +argument that is longer behaves as if getpwnam() failed. + ++---------------------------------------------------------+ +|message_body_newlines|Use: main|Type: bool|Default: false| ++---------------------------------------------------------+ + +By default, newlines in the message body are replaced by spaces when setting +the $message_body and $message_body_end expansion variables. If this option is +set true, this no longer happens. + ++---------------------------------------------------------+ +|message_body_visible|Use: main|Type: integer|Default: 500| ++---------------------------------------------------------+ + +This option specifies how much of a message's body is to be included in the +$message_body and $message_body_end expansion variables. + ++---------------------------------------------------------------+ +|message_id_header_domain|Use: main|Type: string*|Default: unset| ++---------------------------------------------------------------+ + +If this option is set, the string is expanded and used as the right hand side +(domain) of the Message-ID: header that Exim creates if a locally-originated +incoming message does not have one. "Locally-originated" means "not received +over TCP/IP." Otherwise, the primary host name is used. Only letters, digits, +dot and hyphen are accepted; any other characters are replaced by hyphens. If +the expansion is forced to fail, or if the result is an empty string, the +option is ignored. + ++-------------------------------------------------------------+ +|message_id_header_text|Use: main|Type: string*|Default: unset| ++-------------------------------------------------------------+ + +If this variable is set, the string is expanded and used to augment the text of +the Message-id: header that Exim creates if a locally-originated incoming +message does not have one. The text of this header is required by RFC 2822 to +take the form of an address. By default, Exim uses its internal message id as +the local part, and the primary host name as the domain. If this option is set, +it is expanded, and provided the expansion is not forced to fail, and does not +yield an empty string, the result is inserted into the header immediately +before the @, separated from the internal message id by a dot. Any characters +that are illegal in an address are automatically converted into hyphens. This +means that variables such as $tod_log can be used, because the spaces and +colons will become hyphens. + ++--------------------------------------------------+ +|message_logs|Use: main|Type: boolean|Default: true| ++--------------------------------------------------+ + +If this option is turned off, per-message log files are not created in the +msglog spool sub-directory. This reduces the amount of disk I/O required by +Exim, by reducing the number of files involved in handling a message from a +minimum of four (header spool file, body spool file, delivery journal, and +per-message log) to three. The other major I/O activity is Exim's main log, +which is not affected by this option. + ++-------------------------------------------------------+ +|message_size_limit|Use: main|Type: string*|Default: 50M| ++-------------------------------------------------------+ + +This option limits the maximum size of message that Exim will process. The +value is expanded for each incoming connection so, for example, it can be made +to depend on the IP address of the remote host for messages arriving via TCP/ +IP. After expansion, the value must be a sequence of decimal digits, optionally +followed by K or M. + +Note: This limit cannot be made to depend on a message's sender or any other +properties of an individual message, because it has to be advertised in the +server's response to EHLO. String expansion failure causes a temporary error. A +value of zero means no limit, but its use is not recommended. See also +bounce_return_size_limit. + +Incoming SMTP messages are failed with a 552 error if the limit is exceeded; +locally-generated messages either get a stderr message or a delivery failure +message to the sender, depending on the -oe setting. Rejection of an oversized +message is logged in both the main and the reject logs. See also the generic +transport option message_size_limit, which limits the size of message that an +individual transport can process. + +If you use a virus-scanner and set this option to to a value larger than the +maximum size that your virus-scanner is configured to support, you may get +failures triggered by large mails. The right size to configure for the +virus-scanner depends upon what data is passed and the options in use but it's +probably safest to just set it to a little larger than this value. E.g., with a +default Exim message size of 50M and a default ClamAV StreamMaxLength of 10M, +some problems may result. + +A value of 0 will disable size limit checking; Exim will still advertise the +SIZE extension in an EHLO response, but without a limit, so as to permit SMTP +clients to still indicate the message size along with the MAIL verb. + ++-----------------------------------------------------------+ +|move_frozen_messages|Use: main|Type: boolean|Default: false| ++-----------------------------------------------------------+ + +This option, which is available only if Exim has been built with the setting + +SUPPORT_MOVE_FROZEN_MESSAGES=yes + +in Local/Makefile, causes frozen messages and their message logs to be moved +from the input and msglog directories on the spool to Finput and Fmsglog, +respectively. There is currently no support in Exim or the standard utilities +for handling such moved messages, and they do not show up in lists generated by +-bp or by the Exim monitor. + ++--------------------------------------------------+ +|mua_wrapper|Use: main|Type: boolean|Default: false| ++--------------------------------------------------+ + +Setting this option true causes Exim to run in a very restrictive mode in which +it passes messages synchronously to a smart host. Chapter 51 contains a full +description of this facility. + ++--------------------------------------------------------+ +|mysql_servers|Use: main|Type: string list|Default: unset| ++--------------------------------------------------------+ + +This option provides a list of MySQL servers and associated connection data, to +be used in conjunction with mysql lookups (see section 9.22). The option is +available only if Exim has been built with MySQL support. + ++-------------------------------------------------------+ +|never_users|Use: main|Type: string list*|Default: unset| ++-------------------------------------------------------+ + +This option is expanded just once, at the start of Exim's processing. Local +message deliveries are normally run in processes that are setuid to the +recipient, and remote deliveries are normally run under Exim's own uid and gid. +It is usually desirable to prevent any deliveries from running as root, as a +safety precaution. + +When Exim is built, an option called FIXED_NEVER_USERS can be set to a list of +users that must not be used for local deliveries. This list is fixed in the +binary and cannot be overridden by the configuration file. By default, it +contains just the single user name "root". The never_users runtime option can +be used to add more users to the fixed list. + +If a message is to be delivered as one of the users on the fixed list or the +never_users list, an error occurs, and delivery is deferred. A common example +is + +never_users = root:daemon:bin + +Including root is redundant if it is also on the fixed list, but it does no +harm. This option overrides the pipe_as_creator option of the pipe transport +driver. + ++-----------------------------------------------------------------------------+ +|openssl_options| Use: | Type: string | Default: +no_sslv2 +single_dh_use| +| | main | list | +no_ticket| ++-----------------------------------------------------------------------------+ + +This option allows an administrator to adjust the SSL options applied by +OpenSSL to connections. It is given as a space-separated list of items, each +one to be +added or -subtracted from the current value. + +This option is only available if Exim is built against OpenSSL. The values +available for this option vary according to the age of your OpenSSL install. +The "all" value controls a subset of flags which are available, typically the +bug workaround options. The SSL_CTX_set_options man page will list the values +known on your system and Exim should support all the "bug workaround" options +and many of the "modifying" options. The Exim names lose the leading "SSL_OP_" +and are lower-cased. + +Note that adjusting the options can have severe impact upon the security of SSL +as used by Exim. It is possible to disable safety checks and shoot yourself in +the foot in various unpleasant ways. This option should not be adjusted +lightly. An unrecognised item will be detected at startup, by invoking Exim +with the -bV flag. + +The option affects Exim operating both as a server and as a client. + +Historical note: prior to release 4.80, Exim defaulted this value to +"+dont_insert_empty_fragments", which may still be needed for compatibility +with some clients, but which lowers security by increasing exposure to some now +infamous attacks. + +Examples: + +# Make both old MS and old Eudora happy: +openssl_options = -all +microsoft_big_sslv3_buffer \ + +dont_insert_empty_fragments + +# Disable older protocol versions: +openssl_options = +no_sslv2 +no_sslv3 + +Possible options may include: + + * "all" + + * "allow_unsafe_legacy_renegotiation" + + * "cipher_server_preference" + + * "dont_insert_empty_fragments" + + * "ephemeral_rsa" + + * "legacy_server_connect" + + * "microsoft_big_sslv3_buffer" + + * "microsoft_sess_id_bug" + + * "msie_sslv2_rsa_padding" + + * "netscape_challenge_bug" + + * "netscape_reuse_cipher_change_bug" + + * "no_compression" + + * "no_session_resumption_on_renegotiation" + + * "no_sslv2" + + * "no_sslv3" + + * "no_ticket" + + * "no_tlsv1" + + * "no_tlsv1_1" + + * "no_tlsv1_2" + + * "safari_ecdhe_ecdsa_bug" + + * "single_dh_use" + + * "single_ecdh_use" + + * "ssleay_080_client_dh_bug" + + * "sslref2_reuse_cert_type_bug" + + * "tls_block_padding_bug" + + * "tls_d5_bug" + + * "tls_rollback_bug" + +As an aside, the "safari_ecdhe_ecdsa_bug" item is a misnomer and affects all +clients connecting using the MacOS SecureTransport TLS facility prior to MacOS +10.8.4, including email clients. If you see old MacOS clients failing to +negotiate TLS then this option value might help, provided that your OpenSSL +release is new enough to contain this work-around. This may be a situation +where you have to upgrade OpenSSL to get buggy clients working. + ++---------------------------------------------------------+ +|oracle_servers|Use: main|Type: string list|Default: unset| ++---------------------------------------------------------+ + +This option provides a list of Oracle servers and associated connection data, +to be used in conjunction with oracle lookups (see section 9.22). The option is +available only if Exim has been built with Oracle support. + ++----------------------------------------------------------------+ +|percent_hack_domains|Use: main|Type: domain list*|Default: unset| ++----------------------------------------------------------------+ + +The "percent hack" is the convention whereby a local part containing a percent +sign is re-interpreted as a new email address, with the percent replaced by @. +This is sometimes called "source routing", though that term is also applied to +RFC 2822 addresses that begin with an @ character. If this option is set, Exim +implements the percent facility for those domains listed, but no others. This +happens before an incoming SMTP address is tested against an ACL. + +Warning: The "percent hack" has often been abused by people who are trying to +get round relaying restrictions. For this reason, it is best avoided if at all +possible. Unfortunately, a number of less security-conscious MTAs implement it +unconditionally. If you are running Exim on a gateway host, and routing mail +through to internal MTAs without processing the local parts, it is a good idea +to reject recipient addresses with percent characters in their local parts. +Exim's default configuration does this. + ++----------------------------------------------------+ +|perl_at_start|Use: main|Type: boolean|Default: false| ++----------------------------------------------------+ + +This option is available only when Exim is built with an embedded Perl +interpreter. See chapter 12 for details of its use. + ++--------------------------------------------------+ +|perl_startup|Use: main|Type: string|Default: unset| ++--------------------------------------------------+ + +This option is available only when Exim is built with an embedded Perl +interpreter. See chapter 12 for details of its use. + ++---------------------------------------------------+ +|perl_startup|Use: main|Type: boolean|Default: false| ++---------------------------------------------------+ + +This Option enables the taint mode of the embedded Perl interpreter. + ++--------------------------------------------------------+ +|pgsql_servers|Use: main|Type: string list|Default: unset| ++--------------------------------------------------------+ + +This option provides a list of PostgreSQL servers and associated connection +data, to be used in conjunction with pgsql lookups (see section 9.22). The +option is available only if Exim has been built with PostgreSQL support. + ++------------------------------------------------------------------+ +|pid_file_path|Use: main|Type: string*|Default: set at compile time| ++------------------------------------------------------------------+ + +This option sets the name of the file to which the Exim daemon writes its +process id. The string is expanded, so it can contain, for example, references +to the host name: + +pid_file_path = /var/log/$primary_hostname/exim.pid + +If no path is set, the pid is written to the file exim-daemon.pid in Exim's +spool directory. The value set by the option can be overridden by the -oP +command line option. A pid file is not written if a "non-standard" daemon is +run by means of the -oX option, unless a path is explicitly supplied by -oP. + ++----------------------------------------------------------------+ +|pipelining_advertise_hosts|Use: main|Type: host list*|Default: *| ++----------------------------------------------------------------+ + +This option can be used to suppress the advertisement of the SMTP PIPELINING +extension to specific hosts. See also the no_pipelining control in section +43.22. When PIPELINING is not advertised and smtp_enforce_sync is true, an Exim +server enforces strict synchronization for each SMTP command and response. When +PIPELINING is advertised, Exim assumes that clients will use it; "out of order" +commands that are "expected" do not count as protocol errors (see +smtp_max_synprot_errors). + ++--------------------------------------------------+ +|prdr_enable|Use: main|Type: boolean|Default: false| ++--------------------------------------------------+ + +This option can be used to enable the Per-Recipient Data Response extension to +SMTP, defined by Eric Hall. If the option is set, PRDR is advertised by Exim +when operating as a server. If the client requests PRDR, and more than one +recipient, for a message an additional ACL is called for each recipient after +the message content is received. See section 43.9. + ++------------------------------------------------------------+ +|preserve_message_logs|Use: main|Type: boolean|Default: false| ++------------------------------------------------------------+ + +If this option is set, message log files are not deleted when messages are +completed. Instead, they are moved to a sub-directory of the spool directory +called msglog.OLD, where they remain available for statistical or debugging +purposes. This is a dangerous option to set on systems with any appreciable +volume of mail. Use with care! + ++----------------------------------------------------------+ +|primary_hostname|Use: main|Type: string|Default: see below| ++----------------------------------------------------------+ + +This specifies the name of the current host. It is used in the default EHLO or +HELO command for outgoing SMTP messages (changeable via the helo_data option in +the smtp transport), and as the default for qualify_domain. The value is also +used by default in some SMTP response messages from an Exim server. This can be +changed dynamically by setting smtp_active_hostname. + +If primary_hostname is not set, Exim calls uname() to find the host name. If +this fails, Exim panics and dies. If the name returned by uname() contains only +one component, Exim passes it to gethostbyname() (or getipnodebyname() when +available) in order to obtain the fully qualified version. The variable +$primary_hostname contains the host name, whether set explicitly by this +option, or defaulted. + ++--------------------------------------------------------+ +|print_topbitchars|Use: main|Type: boolean|Default: false| ++--------------------------------------------------------+ + +By default, Exim considers only those characters whose codes lie in the range +32-126 to be printing characters. In a number of circumstances (for example, +when writing log entries) non-printing characters are converted into escape +sequences, primarily to avoid messing up the layout. If print_topbitchars is +set, code values of 128 and above are also considered to be printing +characters. + +This option also affects the header syntax checks performed by the autoreply +transport, and whether Exim uses RFC 2047 encoding of the user's full name when +constructing From: and Sender: addresses (as described in section 47.18). +Setting this option can cause Exim to generate eight bit message headers that +do not conform to the standards. + ++------------------------------------------------------+ +|process_log_path|Use: main|Type: string|Default: unset| ++------------------------------------------------------+ + +This option sets the name of the file to which an Exim process writes its +"process log" when sent a USR1 signal. This is used by the exiwhat utility +script. If this option is unset, the file called exim-process.info in Exim's +spool directory is used. The ability to specify the name explicitly can be +useful in environments where two different Exims are running, using different +spool directories. + ++---------------------------------------------------------+ +|prod_requires_admin|Use: main|Type: boolean|Default: true| ++---------------------------------------------------------+ + +The -M, -R, and -q command-line options require the caller to be an admin user +unless prod_requires_admin is set false. See also queue_list_requires_admin and +commandline_checks_require_admin. + ++--------------------------------------------------------+ +|qualify_domain|Use: main|Type: string|Default: see below| ++--------------------------------------------------------+ + +This option specifies the domain name that is added to any envelope sender +addresses that do not have a domain qualification. It also applies to recipient +addresses if qualify_recipient is not set. Unqualified addresses are accepted +by default only for locally-generated messages. Qualification is also applied +to addresses in header lines such as From: and To: for locally-generated +messages, unless the -bnq command line option is used. + +Messages from external sources must always contain fully qualified addresses, +unless the sending host matches sender_unqualified_hosts or +recipient_unqualified_hosts (as appropriate), in which case incoming addresses +are qualified with qualify_domain or qualify_recipient as necessary. +Internally, Exim always works with fully qualified envelope addresses. If +qualify_domain is not set, it defaults to the primary_hostname value. + ++-----------------------------------------------------------+ +|qualify_recipient|Use: main|Type: string|Default: see below| ++-----------------------------------------------------------+ + +This option allows you to specify a different domain for qualifying recipient +addresses to the one that is used for senders. See qualify_domain above. + ++---------------------------------------------------------+ +|queue_domains|Use: main|Type: domain list*|Default: unset| ++---------------------------------------------------------+ + +This option lists domains for which immediate delivery is not required. A +delivery process is started whenever a message is received, but only those +domains that do not match are processed. All other deliveries wait until the +next queue run. See also hold_domains and queue_smtp_domains. + ++---------------------------------------------------------------+ +|queue_list_requires_admin|Use: main|Type: boolean|Default: true| ++---------------------------------------------------------------+ + +The -bp command-line option, which lists the messages that are on the queue, +requires the caller to be an admin user unless queue_list_requires_admin is set +false. See also prod_requires_admin and commandline_checks_require_admin. + ++-------------------------------------------------+ +|queue_only|Use: main|Type: boolean|Default: false| ++-------------------------------------------------+ + +If queue_only is set, a delivery process is not automatically started whenever +a message is received. Instead, the message waits in the queue for the next +queue run. Even if queue_only is false, incoming messages may not get delivered +immediately when certain conditions (such as heavy load) occur. + +The -odq command line has the same effect as queue_only. The -odb and -odi +command line options override queue_only unless queue_only_override is set +false. See also queue_only_file, queue_only_load, and smtp_accept_queue. + ++-----------------------------------------------------+ +|queue_only_file|Use: main|Type: string|Default: unset| ++-----------------------------------------------------+ + +This option can be set to a colon-separated list of absolute path names, each +one optionally preceded by "smtp". When Exim is receiving a message, it tests +for the existence of each listed path using a call to stat(). For each path +that exists, the corresponding queueing option is set. For paths with no +prefix, queue_only is set; for paths prefixed by "smtp", queue_smtp_domains is +set to match all domains. So, for example, + +queue_only_file = smtp/some/file + +causes Exim to behave as if queue_smtp_domains were set to "*" whenever /some/ +file exists. + ++----------------------------------------------------------+ +|queue_only_load|Use: main|Type: fixed-point|Default: unset| ++----------------------------------------------------------+ + +If the system load average is higher than this value, incoming messages from +all sources are queued, and no automatic deliveries are started. If this +happens during local or remote SMTP input, all subsequent messages received on +the same SMTP connection are queued by default, whatever happens to the load in +the meantime, but this can be changed by setting queue_only_load_latch false. + +Deliveries will subsequently be performed by queue runner processes. This +option has no effect on ancient operating systems on which Exim cannot +determine the load average. See also deliver_queue_load_max and +smtp_load_reserve. + ++-----------------------------------------------------------+ +|queue_only_load_latch|Use: main|Type: boolean|Default: true| ++-----------------------------------------------------------+ + +When this option is true (the default), once one message has been queued +because the load average is higher than the value set by queue_only_load, all +subsequent messages received on the same SMTP connection are also queued. This +is a deliberate choice; even though the load average may fall below the +threshold, it doesn't seem right to deliver later messages on the same +connection when not delivering earlier ones. However, there are special +circumstances such as very long-lived connections from scanning appliances +where this is not the best strategy. In such cases, queue_only_load_latch +should be set false. This causes the value of the load average to be +re-evaluated for each message. + ++---------------------------------------------------------+ +|queue_only_override|Use: main|Type: boolean|Default: true| ++---------------------------------------------------------+ + +When this option is true, the -odx command line options override the setting of +queue_only or queue_only_file in the configuration file. If queue_only_override +is set false, the -odx options cannot be used to override; they are accepted, +but ignored. + ++---------------------------------------------------------+ +|queue_run_in_order|Use: main|Type: boolean|Default: false| ++---------------------------------------------------------+ + +If this option is set, queue runs happen in order of message arrival instead of +in an arbitrary order. For this to happen, a complete list of the entire queue +must be set up before the deliveries start. When the queue is all held in a +single directory (the default), a single list is created for both the ordered +and the non-ordered cases. However, if split_spool_directory is set, a single +list is not created when queue_run_in_order is false. In this case, the +sub-directories are processed one at a time (in a random order), and this +avoids setting up one huge list for the whole queue. Thus, setting +queue_run_in_order with split_spool_directory may degrade performance when the +queue is large, because of the extra work in setting up the single, large list. +In most situations, queue_run_in_order should not be set. + ++-------------------------------------------------+ +|queue_run_max|Use: main|Type: integer*|Default: 5| ++-------------------------------------------------+ + +This controls the maximum number of queue runner processes that an Exim daemon +can run simultaneously. This does not mean that it starts them all at once, but +rather that if the maximum number are still running when the time comes to +start another one, it refrains from starting another one. This can happen with +very large queues and/or very sluggish deliveries. This option does not, +however, interlock with other processes, so additional queue runners can be +started by other means, or by killing and restarting the daemon. + +Setting this option to zero does not suppress queue runs; rather, it disables +the limit, allowing any number of simultaneous queue runner processes to be +run. If you do not want queue runs to occur, omit the -qxx setting on the +daemon's command line. + +To set limits for different named queues use an expansion depending on the +$queue_name variable. + ++--------------------------------------------------------------+ +|queue_smtp_domains|Use: main|Type: domain list*|Default: unset| ++--------------------------------------------------------------+ + +When this option is set, a delivery process is started whenever a message is +received, routing is performed, and local deliveries take place. However, if +any SMTP deliveries are required for domains that match queue_smtp_domains, +they are not immediately delivered, but instead the message waits in the queue +for the next queue run. Since routing of the message has taken place, Exim +knows to which remote hosts it must be delivered, and so when the queue run +happens, multiple messages for the same host are delivered over a single SMTP +connection. The -odqs command line option causes all SMTP deliveries to be +queued in this way, and is equivalent to setting queue_smtp_domains to "*". See +also hold_domains and queue_domains. + ++------------------------------------------------+ +|receive_timeout|Use: main|Type: time|Default: 0s| ++------------------------------------------------+ + +This option sets the timeout for accepting a non-SMTP message, that is, the +maximum time that Exim waits when reading a message on the standard input. If +the value is zero, it will wait forever. This setting is overridden by the -or +command line option. The timeout for incoming SMTP messages is controlled by +smtp_receive_timeout. + ++---------------------------------------------------------------+ +|received_header_text|Use: main|Type: string*|Default: see below| ++---------------------------------------------------------------+ + +This string defines the contents of the Received: message header that is added +to each message, except for the timestamp, which is automatically added on at +the end (preceded by a semicolon). The string is expanded each time it is used. +If the expansion yields an empty string, no Received: header line is added to +the message. Otherwise, the string should start with the text "Received:" and +conform to the RFC 2822 specification for Received: header lines. The default +setting is: + +received_header_text = Received: \ + ${if def:sender_rcvhost {from $sender_rcvhost\n\t}\ + {${if def:sender_ident \ + {from ${quote_local_part:$sender_ident} }}\ + ${if def:sender_helo_name {(helo=$sender_helo_name)\n\t}}}}\ + by $primary_hostname \ + ${if def:received_protocol {with $received_protocol}} \ + ${if def:tls_in_cipher {($tls_in_cipher)\n\t}}\ + (Exim $version_number)\n\t\ + ${if def:sender_address \ + {(envelope-from <$sender_address>)\n\t}}\ + id $message_exim_id\ + ${if def:received_for {\n\tfor $received_for}} + +The reference to the TLS cipher is omitted when Exim is built without TLS +support. The use of conditional expansions ensures that this works for both +locally generated messages and messages received from remote hosts, giving +header lines such as the following: + +Received: from scrooge.carol.example ([192.168.12.25] ident=root) +by marley.carol.example with esmtp (Exim 4.00) +(envelope-from <bob@carol.example>) +id 16IOWa-00019l-00 +for chas@dickens.example; Tue, 25 Dec 2001 14:43:44 +0000 +Received: by scrooge.carol.example with local (Exim 4.00) +id 16IOWW-000083-00; Tue, 25 Dec 2001 14:43:41 +0000 + +Until the body of the message has been received, the timestamp is the time when +the message started to be received. Once the body has arrived, and all policy +checks have taken place, the timestamp is updated to the time at which the +message was accepted. + ++--------------------------------------------------------+ +|received_headers_max|Use: main|Type: integer|Default: 30| ++--------------------------------------------------------+ + +When a message is to be delivered, the number of Received: headers is counted, +and if it is greater than this parameter, a mail loop is assumed to have +occurred, the delivery is abandoned, and an error message is generated. This +applies to both local and remote deliveries. + ++---------------------------------------------------------------------+ +|recipient_unqualified_hosts|Use: main|Type: host list*|Default: unset| ++---------------------------------------------------------------------+ + +This option lists those hosts from which Exim is prepared to accept unqualified +recipient addresses in message envelopes. The addresses are made fully +qualified by the addition of the qualify_recipient value. This option also +affects message header lines. Exim does not reject unqualified recipient +addresses in headers, but it qualifies them only if the message came from a +host that matches recipient_unqualified_hosts, or if the message was submitted +locally (not using TCP/IP), and the -bnq option was not set. + ++-------------------------------------------------+ +|recipients_max|Use: main|Type: integer|Default: 0| ++-------------------------------------------------+ + +If this option is set greater than zero, it specifies the maximum number of +original recipients for any message. Additional recipients that are generated +by aliasing or forwarding do not count. SMTP messages get a 452 response for +all recipients over the limit; earlier recipients are delivered as normal. +Non-SMTP messages with too many recipients are failed, and no deliveries are +done. + +Note: The RFCs specify that an SMTP server should accept at least 100 RCPT +commands in a single message. + ++------------------------------------------------------------+ +|recipients_max_reject|Use: main|Type: boolean|Default: false| ++------------------------------------------------------------+ + +If this option is set true, Exim rejects SMTP messages containing too many +recipients by giving 552 errors to the surplus RCPT commands, and a 554 error +to the eventual DATA command. Otherwise (the default) it gives a 452 error to +the surplus RCPT commands and accepts the message on behalf of the initial set +of recipients. The remote server should then re-send the message for the +remaining recipients at a later time. + ++------------------------------------------------------+ +|remote_max_parallel|Use: main|Type: integer|Default: 2| ++------------------------------------------------------+ + +This option controls parallel delivery of one message to a number of remote +hosts. If the value is less than 2, parallel delivery is disabled, and Exim +does all the remote deliveries for a message one by one. Otherwise, if a single +message has to be delivered to more than one remote host, or if several copies +have to be sent to the same remote host, up to remote_max_parallel deliveries +are done simultaneously. If more than remote_max_parallel deliveries are +required, the maximum number of processes are started, and as each one +finishes, another is begun. The order of starting processes is the same as if +sequential delivery were being done, and can be controlled by the +remote_sort_domains option. If parallel delivery takes place while running with +debugging turned on, the debugging output from each delivery process is tagged +with its process id. + +This option controls only the maximum number of parallel deliveries for one +message in one Exim delivery process. Because Exim has no central queue +manager, there is no way of controlling the total number of simultaneous +deliveries if the configuration allows a delivery attempt as soon as a message +is received. + +If you want to control the total number of deliveries on the system, you need +to set the queue_only option. This ensures that all incoming messages are added +to the queue without starting a delivery process. Then set up an Exim daemon to +start queue runner processes at appropriate intervals (probably fairly often, +for example, every minute), and limit the total number of queue runners by +setting the queue_run_max parameter. Because each queue runner delivers only +one message at a time, the maximum number of deliveries that can then take +place at once is queue_run_max multiplied by remote_max_parallel. + +If it is purely remote deliveries you want to control, use queue_smtp_domains +instead of queue_only. This has the added benefit of doing the SMTP routing +before queueing, so that several messages for the same host will eventually get +delivered down the same connection. + ++---------------------------------------------------------------+ +|remote_sort_domains|Use: main|Type: domain list*|Default: unset| ++---------------------------------------------------------------+ + +When there are a number of remote deliveries for a message, they are sorted by +domain into the order given by this list. For example, + +remote_sort_domains = *.cam.ac.uk:*.uk + +would attempt to deliver to all addresses in the cam.ac.uk domain first, then +to those in the uk domain, then to any others. + ++--------------------------------------------------+ +|retry_data_expire|Use: main|Type: time|Default: 7d| ++--------------------------------------------------+ + +This option sets a "use before" time on retry information in Exim's hints +database. Any older retry data is ignored. This means that, for example, once a +host has not been tried for 7 days, Exim behaves as if it has no knowledge of +past failures. + ++----------------------------------------------------+ +|retry_interval_max|Use: main|Type: time|Default: 24h| ++----------------------------------------------------+ + +Chapter 32 describes Exim's mechanisms for controlling the intervals between +delivery attempts for messages that cannot be delivered straight away. This +option sets an overall limit to the length of time between retries. It cannot +be set greater than 24 hours; any attempt to do so forces the default value. + ++--------------------------------------------------------+ +|return_path_remove|Use: main|Type: boolean|Default: true| ++--------------------------------------------------------+ + +RFC 2821, section 4.4, states that an SMTP server must insert a Return-path: +header line into a message when it makes a "final delivery". The Return-path: +header preserves the sender address as received in the MAIL command. This +description implies that this header should not be present in an incoming +message. If return_path_remove is true, any existing Return-path: headers are +removed from messages at the time they are received. Exim's transports have +options for adding Return-path: headers at the time of delivery. They are +normally used only for final local deliveries. + ++-------------------------------------------------------+ +|return_size_limit|Use: main|Type: integer|Default: 100K| ++-------------------------------------------------------+ + +This option is an obsolete synonym for bounce_return_size_limit. + ++-----------------------------------------------------+ +|rfc1413_hosts|Use: main|Type: host list*|Default: @[]| ++-----------------------------------------------------+ + +RFC 1413 identification calls are made to any client host which matches an item +in the list. The default value specifies just this host, being any local +interface for the system. + ++------------------------------------------------------+ +|rfc1413_query_timeout|Use: main|Type: time|Default: 0s| ++------------------------------------------------------+ + +This sets the timeout on RFC 1413 identification calls. If it is set to zero, +no RFC 1413 calls are ever made. + ++------------------------------------------------------------------+ +|sender_unqualified_hosts|Use: main|Type: host list*|Default: unset| ++------------------------------------------------------------------+ + +This option lists those hosts from which Exim is prepared to accept unqualified +sender addresses. The addresses are made fully qualified by the addition of +qualify_domain. This option also affects message header lines. Exim does not +reject unqualified addresses in headers that contain sender addresses, but it +qualifies them only if the message came from a host that matches +sender_unqualified_hosts, or if the message was submitted locally (not using +TCP/IP), and the -bnq option was not set. + ++----------------------------------------------------------+ +|set_environment|Use: main|Type: string list|Default: empty| ++----------------------------------------------------------+ + +This option allows to set individual environment variables that the currently +linked libraries and programs in child processes use. The default list is +empty, + ++--------------------------------------------------+ +|slow_lookup_log|Use: main|Type: integer|Default: 0| ++--------------------------------------------------+ + +This option controls logging of slow lookups. If the value is nonzero it is +taken as a number of milliseconds and lookups taking longer than this are +logged. Currently this applies only to DNS lookups. + ++-----------------------------------------------------------+ +|smtp_accept_keepalive|Use: main|Type: boolean|Default: true| ++-----------------------------------------------------------+ + +This option controls the setting of the SO_KEEPALIVE option on incoming TCP/IP +socket connections. When set, it causes the kernel to probe idle connections +periodically, by sending packets with "old" sequence numbers. The other end of +the connection should send an acknowledgment if the connection is still okay or +a reset if the connection has been aborted. The reason for doing this is that +it has the beneficial effect of freeing up certain types of connection that can +get stuck when the remote host is disconnected without tidying up the TCP/IP +call properly. The keepalive mechanism takes several hours to detect +unreachable hosts. + ++---------------------------------------------------+ +|smtp_accept_max|Use: main|Type: integer|Default: 20| ++---------------------------------------------------+ + +This option specifies the maximum number of simultaneous incoming SMTP calls +that Exim will accept. It applies only to the listening daemon; there is no +control (in Exim) when incoming SMTP is being handled by inetd. If the value is +set to zero, no limit is applied. However, it is required to be non-zero if +either smtp_accept_max_per_host or smtp_accept_queue is set. See also +smtp_accept_reserve and smtp_load_reserve. + +A new SMTP connection is immediately rejected if the smtp_accept_max limit has +been reached. If not, Exim first checks smtp_accept_max_per_host. If that limit +has not been reached for the client host, smtp_accept_reserve and +smtp_load_reserve are then checked before accepting the connection. + ++-----------------------------------------------------------+ +|smtp_accept_max_nonmail|Use: main|Type: integer|Default: 10| ++-----------------------------------------------------------+ + +Exim counts the number of "non-mail" commands in an SMTP session, and drops the +connection if there are too many. This option defines "too many". The check +catches some denial-of-service attacks, repeated failing AUTHs, or a mad client +looping sending EHLO, for example. The check is applied only if the client host +matches smtp_accept_max_nonmail_hosts. + +When a new message is expected, one occurrence of RSET is not counted. This +allows a client to send one RSET between messages (this is not necessary, but +some clients do it). Exim also allows one uncounted occurrence of HELO or EHLO, +and one occurrence of STARTTLS between messages. After starting up a TLS +session, another EHLO is expected, and so it too is not counted. The first +occurrence of AUTH in a connection, or immediately following STARTTLS is not +counted. Otherwise, all commands other than MAIL, RCPT, DATA, and QUIT are +counted. + ++-------------------------------------------------------------------+ +|smtp_accept_max_nonmail_hosts|Use: main|Type: host list*|Default: *| ++-------------------------------------------------------------------+ + +You can control which hosts are subject to the smtp_accept_max_nonmail check by +setting this option. The default value makes it apply to all hosts. By changing +the value, you can exclude any badly-behaved hosts that you have to live with. + ++--------------------------------------------------------------------+ +|smtp_accept_max_per_connection|Use: main|Type: integer|Default: 1000| ++--------------------------------------------------------------------+ + +The value of this option limits the number of MAIL commands that Exim is +prepared to accept over a single SMTP connection, whether or not each command +results in the transfer of a message. After the limit is reached, a 421 +response is given to subsequent MAIL commands. This limit is a safety +precaution against a client that goes mad (incidents of this type have been +seen). + ++---------------------------------------------------------------+ +|smtp_accept_max_per_host|Use: main|Type: string*|Default: unset| ++---------------------------------------------------------------+ + +This option restricts the number of simultaneous IP connections from a single +host (strictly, from a single IP address) to the Exim daemon. The option is +expanded, to enable different limits to be applied to different hosts by +reference to $sender_host_address. Once the limit is reached, additional +connection attempts from the same host are rejected with error code 421. This +is entirely independent of smtp_accept_reserve. The option's default value of +zero imposes no limit. If this option is set greater than zero, it is required +that smtp_accept_max be non-zero. + +Warning: When setting this option you should not use any expansion +constructions that take an appreciable amount of time. The expansion and test +happen in the main daemon loop, in order to reject additional connections +without forking additional processes (otherwise a denial-of-service attack +could cause a vast number or processes to be created). While the daemon is +doing this processing, it cannot accept any other incoming connections. + ++----------------------------------------------------+ +|smtp_accept_queue|Use: main|Type: integer|Default: 0| ++----------------------------------------------------+ + +If the number of simultaneous incoming SMTP connections being handled via the +listening daemon exceeds this value, messages received by SMTP are just placed +in the queue; no delivery processes are started automatically. The count is +fixed at the start of an SMTP connection. It cannot be updated in the +subprocess that receives messages, and so the queueing or not queueing applies +to all messages received in the same connection. + +A value of zero implies no limit, and clearly any non-zero value is useful only +if it is less than the smtp_accept_max value (unless that is zero). See also +queue_only, queue_only_load, queue_smtp_domains, and the various -odx command +line options. + ++--------------------------------------------------------------------+ +|smtp_accept_queue_per_connection|Use: main|Type: integer|Default: 10| ++--------------------------------------------------------------------+ + +This option limits the number of delivery processes that Exim starts +automatically when receiving messages via SMTP, whether via the daemon or by +the use of -bs or -bS. If the value of the option is greater than zero, and the +number of messages received in a single SMTP session exceeds this number, +subsequent messages are placed in the queue, but no delivery processes are +started. This helps to limit the number of Exim processes when a server +restarts after downtime and there is a lot of mail waiting for it on other +systems. On large systems, the default should probably be increased, and on +dial-in client systems it should probably be set to zero (that is, disabled). + ++------------------------------------------------------+ +|smtp_accept_reserve|Use: main|Type: integer|Default: 0| ++------------------------------------------------------+ + +When smtp_accept_max is set greater than zero, this option specifies a number +of SMTP connections that are reserved for connections from the hosts that are +specified in smtp_reserve_hosts. The value set in smtp_accept_max includes this +reserve pool. The specified hosts are not restricted to this number of +connections; the option specifies a minimum number of connection slots for +them, not a maximum. It is a guarantee that this group of hosts can always get +at least smtp_accept_reserve connections. However, the limit specified by +smtp_accept_max_per_host is still applied to each individual host. + +For example, if smtp_accept_max is set to 50 and smtp_accept_reserve is set to +5, once there are 45 active connections (from any hosts), new connections are +accepted only from hosts listed in smtp_reserve_hosts, provided the other +criteria for acceptance are met. + ++-----------------------------------------------------------+ +|smtp_active_hostname|Use: main|Type: string*|Default: unset| ++-----------------------------------------------------------+ + +This option is provided for multi-homed servers that want to masquerade as +several different hosts. At the start of an incoming SMTP connection, its value +is expanded and used instead of the value of $primary_hostname in SMTP +responses. For example, it is used as domain name in the response to an +incoming HELO or EHLO command. + +The active hostname is placed in the $smtp_active_hostname variable, which is +saved with any messages that are received. It is therefore available for use in +routers and transports when the message is later delivered. + +If this option is unset, or if its expansion is forced to fail, or if the +expansion results in an empty string, the value of $primary_hostname is used. +Other expansion failures cause a message to be written to the main and panic +logs, and the SMTP command receives a temporary error. Typically, the value of +smtp_active_hostname depends on the incoming interface address. For example: + +smtp_active_hostname = ${if eq{$received_ip_address}{10.0.0.1}\ + {cox.mydomain}{box.mydomain}} + +Although $smtp_active_hostname is primarily concerned with incoming messages, +it is also used as the default for HELO commands in callout verification if +there is no remote transport from which to obtain a helo_data value. + ++------------------------------------------------------+ +|smtp_banner|Use: main|Type: string*|Default: see below| ++------------------------------------------------------+ + +This string, which is expanded every time it is used, is output as the initial +positive response to an SMTP connection. The default setting is: + +smtp_banner = $smtp_active_hostname ESMTP Exim \ + $version_number $tod_full + +Failure to expand the string causes a panic error. If you want to create a +multiline response to the initial SMTP connection, use "\n" in the string at +appropriate points, but not at the end. Note that the 220 code is not included +in this string. Exim adds it automatically (several times in the case of a +multiline response). + ++------------------------------------------------------------+ +|smtp_check_spool_space|Use: main|Type: boolean|Default: true| ++------------------------------------------------------------+ + +When this option is set, if an incoming SMTP session encounters the SIZE option +on a MAIL command, it checks that there is enough space in the spool +directory's partition to accept a message of that size, while still leaving +free the amount specified by check_spool_space (even if that value is zero). If +there isn't enough space, a temporary error code is returned. + ++--------------------------------------------------------+ +|smtp_connect_backlog|Use: main|Type: integer|Default: 20| ++--------------------------------------------------------+ + +This option specifies a maximum number of waiting SMTP connections. Exim passes +this value to the TCP/IP system when it sets up its listener. Once this number +of connections are waiting for the daemon's attention, subsequent connection +attempts are refused at the TCP/IP level. At least, that is what the manuals +say; in some circumstances such connection attempts have been observed to time +out instead. For large systems it is probably a good idea to increase the value +(to 50, say). It also gives some protection against denial-of-service attacks +by SYN flooding. + ++-------------------------------------------------------+ +|smtp_enforce_sync|Use: main|Type: boolean|Default: true| ++-------------------------------------------------------+ + +The SMTP protocol specification requires the client to wait for a response from +the server at certain points in the dialogue. Without PIPELINING these +synchronization points are after every command; with PIPELINING they are fewer, +but they still exist. + +Some spamming sites send out a complete set of SMTP commands without waiting +for any response. Exim protects against this by rejecting a message if the +client has sent further input when it should not have. The error response "554 +SMTP synchronization error" is sent, and the connection is dropped. Testing for +this error cannot be perfect because of transmission delays (unexpected input +may be on its way but not yet received when Exim checks). However, it does +detect many instances. + +The check can be globally disabled by setting smtp_enforce_sync false. If you +want to disable the check selectively (for example, only for certain hosts), +you can do so by an appropriate use of a control modifier in an ACL (see +section 43.22). See also pipelining_advertise_hosts. + ++--------------------------------------------------------+ +|smtp_etrn_command|Use: main|Type: string*|Default: unset| ++--------------------------------------------------------+ + +If this option is set, the given command is run whenever an SMTP ETRN command +is received from a host that is permitted to issue such commands (see chapter +43). The string is split up into separate arguments which are independently +expanded. The expansion variable $domain is set to the argument of the ETRN +command, and no syntax checking is done on it. For example: + +smtp_etrn_command = /etc/etrn_command $domain \ + $sender_host_address + +A new process is created to run the command, but Exim does not wait for it to +complete. Consequently, its status cannot be checked. If the command cannot be +run, a line is written to the panic log, but the ETRN caller still receives a +250 success response. Exim is normally running under its own uid when receiving +SMTP, so it is not possible for it to change the uid before running the +command. + ++---------------------------------------------------------+ +|smtp_etrn_serialize|Use: main|Type: boolean|Default: true| ++---------------------------------------------------------+ + +When this option is set, it prevents the simultaneous execution of more than +one identical command as a result of ETRN in an SMTP connection. See section +48.8 for details. + ++------------------------------------------------------------+ +|smtp_load_reserve|Use: main|Type: fixed-point|Default: unset| ++------------------------------------------------------------+ + +If the system load average ever gets higher than this, incoming SMTP calls are +accepted only from those hosts that match an entry in smtp_reserve_hosts. If +smtp_reserve_hosts is not set, no incoming SMTP calls are accepted when the +load is over the limit. The option has no effect on ancient operating systems +on which Exim cannot determine the load average. See also +deliver_queue_load_max and queue_only_load. + ++----------------------------------------------------------+ +|smtp_max_synprot_errors|Use: main|Type: integer|Default: 3| ++----------------------------------------------------------+ + +Exim rejects SMTP commands that contain syntax or protocol errors. In +particular, a syntactically invalid email address, as in this command: + +RCPT TO:<abc xyz@a.b.c> + +causes immediate rejection of the command, before any other tests are done. +(The ACL cannot be run if there is no valid address to set up for it.) An +example of a protocol error is receiving RCPT before MAIL. If there are too +many syntax or protocol errors in one SMTP session, the connection is dropped. +The limit is set by this option. + +When the PIPELINING extension to SMTP is in use, some protocol errors are +"expected", for instance, a RCPT command after a rejected MAIL command. Exim +assumes that PIPELINING will be used if it advertises it (see +pipelining_advertise_hosts), and in this situation, "expected" errors do not +count towards the limit. + ++------------------------------------------------------------+ +|smtp_max_unknown_commands|Use: main|Type: integer|Default: 3| ++------------------------------------------------------------+ + +If there are too many unrecognized commands in an incoming SMTP session, an +Exim server drops the connection. This is a defence against some kinds of abuse +that subvert web clients into making connections to SMTP ports; in these +circumstances, a number of non-SMTP command lines are sent first. + ++--------------------------------------------------------------+ +|smtp_ratelimit_hosts|Use: main|Type: host list*|Default: unset| ++--------------------------------------------------------------+ + +Some sites find it helpful to be able to limit the rate at which certain hosts +can send them messages, and the rate at which an individual message can specify +recipients. + +Exim has two rate-limiting facilities. This section describes the older +facility, which can limit rates within a single connection. The newer ratelimit +ACL condition can limit rates across all connections. See section 43.38 for +details of the newer facility. + +When a host matches smtp_ratelimit_hosts, the values of smtp_ratelimit_mail and +smtp_ratelimit_rcpt are used to control the rate of acceptance of MAIL and RCPT +commands in a single SMTP session, respectively. Each option, if set, must +contain a set of four comma-separated values: + + * A threshold, before which there is no rate limiting. + + * An initial time delay. Unlike other times in Exim, numbers with decimal + fractional parts are allowed here. + + * A factor by which to increase the delay each time. + + * A maximum value for the delay. This should normally be less than 5 minutes, + because after that time, the client is liable to timeout the SMTP command. + +For example, these settings have been used successfully at the site which first +suggested this feature, for controlling mail from their customers: + +smtp_ratelimit_mail = 2,0.5s,1.05,4m +smtp_ratelimit_rcpt = 4,0.25s,1.015,4m + +The first setting specifies delays that are applied to MAIL commands after two +have been received over a single connection. The initial delay is 0.5 seconds, +increasing by a factor of 1.05 each time. The second setting applies delays to +RCPT commands when more than four occur in a single message. + ++---------------------------------------------------------+ +|smtp_ratelimit_mail|Use: main|Type: string|Default: unset| ++---------------------------------------------------------+ + +See smtp_ratelimit_hosts above. + ++---------------------------------------------------------+ +|smtp_ratelimit_rcpt|Use: main|Type: string|Default: unset| ++---------------------------------------------------------+ + +See smtp_ratelimit_hosts above. + ++------------------------------------------------------+ +|smtp_receive_timeout|Use: main|Type: time*|Default: 5m| ++------------------------------------------------------+ + +This sets a timeout value for SMTP reception. It applies to all forms of SMTP +input, including batch SMTP. If a line of input (either an SMTP command or a +data line) is not received within this time, the SMTP connection is dropped and +the message is abandoned. A line is written to the log containing one of the +following messages: + +SMTP command timeout on connection from... +SMTP data timeout on connection from... + +The former means that Exim was expecting to read an SMTP command; the latter +means that it was in the DATA phase, reading the contents of a message. + +If the first character of the option is a "$" the option is expanded before use +and may depend on $sender_host_name, $sender_host_address and $sender_host_port +. + +The value set by this option can be overridden by the -os command-line option. +A setting of zero time disables the timeout, but this should never be used for +SMTP over TCP/IP. (It can be useful in some cases of local input using -bs or +-bS.) For non-SMTP input, the reception timeout is controlled by +receive_timeout and -or. + ++------------------------------------------------------------+ +|smtp_reserve_hosts|Use: main|Type: host list*|Default: unset| ++------------------------------------------------------------+ + +This option defines hosts for which SMTP connections are reserved; see +smtp_accept_reserve and smtp_load_reserve above. + ++----------------------------------------------------------------+ +|smtp_return_error_details|Use: main|Type: boolean|Default: false| ++----------------------------------------------------------------+ + +In the default state, Exim uses bland messages such as "Administrative +prohibition" when it rejects SMTP commands for policy reasons. Many sysadmins +like this because it gives away little information to spammers. However, some +other sysadmins who are applying strict checking policies want to give out much +fuller information about failures. Setting smtp_return_error_details true +causes Exim to be more forthcoming. For example, instead of "Administrative +prohibition", it might give: + +550-Rejected after DATA: '>' missing at end of address: +550 failing address in "From" header is: <user@dom.ain + ++--------------------------------------------------------------+ +|smtputf8_advertise_hosts|Use: main|Type: host list*|Default: *| ++--------------------------------------------------------------+ + +When Exim is built with support for internationalised mail names, the +availability thereof is advertised in response to EHLO only to those client +hosts that match this option. See chapter 59 for details of Exim's support for +internationalisation. + ++-----------------------------------------------------------+ +|spamd_address|Use: main|Type: string|Default: 127.0.0.1 783| ++-----------------------------------------------------------+ + +This option is available when Exim is compiled with the content-scanning +extension. It specifies how Exim connects to SpamAssassin's spamd daemon. See +section 44.2 for more details. + ++--------------------------------------------------------------------+ +|spf_guess|Use: main|Type: string|Default: v=spf1 a/24 mx/24 ptr ?all| ++--------------------------------------------------------------------+ + +This option is available when Exim is compiled with SPF support. See section +57.4 for more details. + ++------------------------------------------------------------+ +|split_spool_directory|Use: main|Type: boolean|Default: false| ++------------------------------------------------------------+ + +If this option is set, it causes Exim to split its input directory into 62 +subdirectories, each with a single alphanumeric character as its name. The +sixth character of the message id is used to allocate messages to +subdirectories; this is the least significant base-62 digit of the time of +arrival of the message. + +Splitting up the spool in this way may provide better performance on systems +where there are long mail queues, by reducing the number of files in any one +directory. The msglog directory is also split up in a similar way to the input +directory; however, if preserve_message_logs is set, all old msglog files are +still placed in the single directory msglog.OLD. + +It is not necessary to take any special action for existing messages when +changing split_spool_directory. Exim notices messages that are in the "wrong" +place, and continues to process them. If the option is turned off after a +period of being on, the subdirectories will eventually empty and be +automatically deleted. + +When split_spool_directory is set, the behaviour of queue runner processes +changes. Instead of creating a list of all messages in the queue, and then +trying to deliver each one, in turn, it constructs a list of those in one +sub-directory and tries to deliver them, before moving on to the next +sub-directory. The sub-directories are processed in a random order. This +spreads out the scanning of the input directories, and uses less memory. It is +particularly beneficial when there are lots of messages in the queue. However, +if queue_run_in_order is set, none of this new processing happens. The entire +queue has to be scanned and sorted before any deliveries can start. + ++--------------------------------------------------------------------+ +|spool_directory|Use: main|Type: string*|Default: set at compile time| ++--------------------------------------------------------------------+ + +This defines the directory in which Exim keeps its spool, that is, the messages +it is waiting to deliver. The default value is taken from the compile-time +configuration setting, if there is one. If not, this option must be set. The +string is expanded, so it can contain, for example, a reference to +$primary_hostname. + +If the spool directory name is fixed on your installation, it is recommended +that you set it at build time rather than from this option, particularly if the +log files are being written to the spool directory (see log_file_path). +Otherwise log files cannot be used for errors that are detected early on, such +as failures in the configuration file. + +By using this option to override the compiled-in path, it is possible to run +tests of Exim without using the standard spool. + ++-------------------------------------------------------+ +|spool_wireformat|Use: main|Type: boolean|Default: false| ++-------------------------------------------------------+ + +If this option is set, Exim may for some messages use an alternative format for +data-files in the spool which matches the wire format. Doing this permits more +efficient message reception and transmission. Currently it is only done for +messages received using the ESMTP CHUNKING option. + +The following variables will not have useful values: + +$max_received_linelength +$body_linecount +$body_zerocount + +Users of the local_scan() API (see 45), and any external programs which are +passed a reference to a message data file (except via the "regex", "malware" or +"spam") ACL conditions) will need to be aware of the different formats +potentially available. + +Using any of the ACL conditions noted will negate the reception benefit (as a +Unix-mbox-format file is constructed for them). The transmission benefit is +maintained. + ++----------------------------------------------------+ +|sqlite_lock_timeout|Use: main|Type: time|Default: 5s| ++----------------------------------------------------+ + +This option controls the timeout that the sqlite lookup uses when trying to +access an SQLite database. See section 9.26 for more details. + ++------------------------------------------------------+ +|strict_acl_vars|Use: main|Type: boolean|Default: false| ++------------------------------------------------------+ + +This option controls what happens if a syntactically valid but undefined ACL +variable is referenced. If it is false (the default), an empty string is +substituted; if it is true, an error is generated. See section 43.19 for +details of ACL variables. + ++------------------------------------------------------------------+ +|strip_excess_angle_brackets|Use: main|Type: boolean|Default: false| ++------------------------------------------------------------------+ + +If this option is set, redundant pairs of angle brackets round "route-addr" +items in addresses are stripped. For example, <<xxx@a.b.c.d>> is treated as +<xxx@a.b.c.d>. If this is in the envelope and the message is passed on to +another MTA, the excess angle brackets are not passed on. If this option is not +set, multiple pairs of angle brackets cause a syntax error. + ++---------------------------------------------------------+ +|strip_trailing_dot|Use: main|Type: boolean|Default: false| ++---------------------------------------------------------+ + +If this option is set, a trailing dot at the end of a domain in an address is +ignored. If this is in the envelope and the message is passed on to another +MTA, the dot is not passed on. If this option is not set, a dot at the end of a +domain causes a syntax error. However, addresses in header lines are checked +only when an ACL requests header syntax checking. + ++--------------------------------------------------------+ +|syslog_duplication|Use: main|Type: boolean|Default: true| ++--------------------------------------------------------+ + +When Exim is logging to syslog, it writes the log lines for its three separate +logs at different syslog priorities so that they can in principle be separated +on the logging hosts. Some installations do not require this separation, and in +those cases, the duplication of certain log lines is a nuisance. If +syslog_duplication is set false, only one copy of any particular log line is +written to syslog. For lines that normally go to both the main log and the +reject log, the reject log version (possibly containing message header lines) +is written, at LOG_NOTICE priority. Lines that normally go to both the main and +the panic log are written at the LOG_ALERT priority. + ++-----------------------------------------------------+ +|syslog_facility|Use: main|Type: string|Default: unset| ++-----------------------------------------------------+ + +This option sets the syslog "facility" name, used when Exim is logging to +syslog. The value must be one of the strings "mail", "user", "news", "uucp", +"daemon", or "localx" where x is a digit between 0 and 7. If this option is +unset, "mail" is used. See chapter 52 for details of Exim's logging. + ++------------------------------------------------+ +|syslog_pid|Use: main|Type: boolean|Default: true| ++------------------------------------------------+ + +If syslog_pid is set false, the PID on Exim's log lines are omitted when these +lines are sent to syslog. (Syslog normally prefixes the log lines with the PID +of the logging process automatically.) You need to enable the "+pid" log +selector item, if you want Exim to write it's PID into the logs.) See chapter +52 for details of Exim's logging. + ++---------------------------------------------------------+ +|syslog_processname|Use: main|Type: string|Default: "exim"| ++---------------------------------------------------------+ + +This option sets the syslog "ident" name, used when Exim is logging to syslog. +The value must be no longer than 32 characters. See chapter 52 for details of +Exim's logging. + ++------------------------------------------------------+ +|syslog_timestamp|Use: main|Type: boolean|Default: true| ++------------------------------------------------------+ + +If syslog_timestamp is set false, the timestamps on Exim's log lines are +omitted when these lines are sent to syslog. See chapter 52 for details of +Exim's logging. + ++----------------------------------------------------+ +|system_filter|Use: main|Type: string*|Default: unset| ++----------------------------------------------------+ + +This option specifies an Exim filter file that is applied to all messages at +the start of each delivery attempt, before any routing is done. System filters +must be Exim filters; they cannot be Sieve filters. If the system filter +generates any deliveries to files or pipes, or any new mail messages, the +appropriate system_filter_..._transport option(s) must be set, to define which +transports are to be used. Details of this facility are given in chapter 46. A +forced expansion failure results in no filter operation. + ++------------------------------------------------------------------------+ +|system_filter_directory_transport|Use: main|Type: string*|Default: unset| ++------------------------------------------------------------------------+ + +This sets the name of the transport driver that is to be used when the save +command in a system message filter specifies a path ending in "/", implying +delivery of each message into a separate file in some directory. During the +delivery, the variable $address_file contains the path name. + ++-------------------------------------------------------------------+ +|system_filter_file_transport|Use: main|Type: string*|Default: unset| ++-------------------------------------------------------------------+ + +This sets the name of the transport driver that is to be used when the save +command in a system message filter specifies a path not ending in "/". During +the delivery, the variable $address_file contains the path name. + ++---------------------------------------------------------+ +|system_filter_group|Use: main|Type: string|Default: unset| ++---------------------------------------------------------+ + +This option is used only when system_filter_user is also set. It sets the gid +under which the system filter is run, overriding any gid that is associated +with the user. The value may be numerical or symbolic. + ++-------------------------------------------------------------------+ +|system_filter_pipe_transport|Use: main|Type: string*|Default: unset| ++-------------------------------------------------------------------+ + +This specifies the transport driver that is to be used when a pipe command is +used in a system filter. During the delivery, the variable $address_pipe +contains the pipe command. + ++--------------------------------------------------------------------+ +|system_filter_reply_transport|Use: main|Type: string*|Default: unset| ++--------------------------------------------------------------------+ + +This specifies the transport driver that is to be used when a mail command is +used in a system filter. + ++--------------------------------------------------------+ +|system_filter_user|Use: main|Type: string|Default: unset| ++--------------------------------------------------------+ + +If this option is set to root, the system filter is run in the main Exim +delivery process, as root. Otherwise, the system filter runs in a separate +process, as the given user, defaulting to the Exim run-time user. Unless the +string consists entirely of digits, it is looked up in the password data. +Failure to find the named user causes a configuration error. The gid is either +taken from the password data, or specified by system_filter_group. When the uid +is specified numerically, system_filter_group is required to be set. + +If the system filter generates any pipe, file, or reply deliveries, the uid +under which the filter is run is used when transporting them, unless a +transport option overrides. + ++-------------------------------------------------+ +|tcp_nodelay|Use: main|Type: boolean|Default: true| ++-------------------------------------------------+ + +If this option is set false, it stops the Exim daemon setting the TCP_NODELAY +option on its listening sockets. Setting TCP_NODELAY turns off the "Nagle +algorithm", which is a way of improving network performance in interactive +(character-by-character) situations. Turning it off should improve Exim's +performance a bit, so that is what happens by default. However, it appears that +some broken clients cannot cope, and time out. Hence this option. It affects +only those sockets that are set up for listening by the daemon. Sockets created +by the smtp transport for delivering mail always set TCP_NODELAY. + ++-----------------------------------------------------+ +|timeout_frozen_after|Use: main|Type: time|Default: 0s| ++-----------------------------------------------------+ + +If timeout_frozen_after is set to a time greater than zero, a frozen message of +any kind that has been in the queue for longer than the given time is +automatically cancelled at the next queue run. If the frozen message is a +bounce message, it is just discarded; otherwise, a bounce is sent to the +sender, in a similar manner to cancellation by the -Mg command line option. If +you want to timeout frozen bounce messages earlier than other kinds of frozen +message, see ignore_bounce_errors_after. + +Note: the default value of zero means no timeouts; with this setting, frozen +messages remain in the queue forever (except for any frozen bounce messages +that are released by ignore_bounce_errors_after). + ++----------------------------------------------+ +|timezone|Use: main|Type: string|Default: unset| ++----------------------------------------------+ + +The value of timezone is used to set the environment variable TZ while running +Exim (if it is different on entry). This ensures that all timestamps created by +Exim are in the required timezone. If you want all your timestamps to be in UTC +(aka GMT) you should set + +timezone = UTC + +The default value is taken from TIMEZONE_DEFAULT in Local/Makefile, or, if that +is not set, from the value of the TZ environment variable when Exim is built. +If timezone is set to the empty string, either at build or run time, any +existing TZ variable is removed from the environment when Exim runs. This is +appropriate behaviour for obtaining wall-clock time on some, but unfortunately +not all, operating systems. + ++---------------------------------------------------------+ +|tls_advertise_hosts|Use: main|Type: host list*|Default: *| ++---------------------------------------------------------+ + +When Exim is built with support for TLS encrypted connections, the availability +of the STARTTLS command to set up an encrypted session is advertised in +response to EHLO only to those client hosts that match this option. See chapter +42 for details of Exim's support for TLS. Note that the default value requires +that a certificate be supplied using the tls_certificate option. If TLS support +for incoming connections is not required the tls_advertise_hosts option should +be set empty. + ++-----------------------------------------------------+ +|tls_certificate|Use: main|Type: string|Default: list*| ++-----------------------------------------------------+ + +The value of this option is expanded, and must then be a list of absolute paths +to files which contains the server's certificates. Commonly only one file is +needed. The server's private key is also assumed to be in this file if +tls_privatekey is unset. See chapter 42 for further details. + +Note: The certificates defined by this option are used only when Exim is +receiving incoming messages as a server. If you want to supply certificates for +use when sending messages as a client, you must set the tls_certificate option +in the relevant smtp transport. + +Note: If you use filenames based on IP addresses, change the list separator in +the usual way (6.21) >to avoid confusion under IPv6. + +Note: Under versions of OpenSSL preceding 1.1.1, when a list of more than one +file is used, the $tls_in_ourcert variable is unreliable. + +Note: OCSP stapling is not usable under OpenSSL when a list of more than one +file is used. + +If the option contains $tls_out_sni and Exim is built against OpenSSL, then if +the OpenSSL build supports TLS extensions and the TLS client sends the Server +Name Indication extension, then this option and others documented in 42.10 will +be re-expanded. + +If this option is unset or empty a fresh self-signed certificate will be +generated for every connection. + ++----------------------------------------------+ +|tls_crl|Use: main|Type: string*|Default: unset| ++----------------------------------------------+ + +This option specifies a certificate revocation list. The expanded value must be +the name of a file that contains CRLs in PEM format. + +Under OpenSSL the option can specify a directory with CRL files. + +Note: Under OpenSSL the option must, if given, supply a CRL for each signing +element of the certificate chain (i.e. all but the leaf). For the file variant +this can be multiple PEM blocks in the one file. + +See 42.10 for discussion of when this option might be re-expanded. + ++-----------------------------------------------------+ +|tls_dh_max_bits|Use: main|Type: integer|Default: 2236| ++-----------------------------------------------------+ + +The number of bits used for Diffie-Hellman key-exchange may be suggested by the +chosen TLS library. That value might prove to be too high for interoperability. +This option provides a maximum clamp on the value suggested, trading off +security for interoperability. + +The value must be at least 1024. + +The value 2236 was chosen because, at time of adding the option, it was the +hard-coded maximum value supported by the NSS cryptographic library, as used by +Thunderbird, while GnuTLS was suggesting 2432 bits as normal. + +If you prefer more security and are willing to break some clients, raise this +number. + +Note that the value passed to GnuTLS for *generating* a new prime may be a +little less than this figure, because GnuTLS is inexact and may produce a +larger prime than requested. + ++--------------------------------------------------+ +|tls_dhparam|Use: main|Type: string*|Default: unset| ++--------------------------------------------------+ + +The value of this option is expanded and indicates the source of DH parameters +to be used by Exim. + +Note: The Exim Maintainers strongly recommend using a filename with +site-generated local DH parameters, which has been supported across all +versions of Exim. The other specific constants available are a fallback so that +even when "unconfigured", Exim can offer Perfect Forward Secrecy in older +ciphersuites in TLS. + +If tls_dhparam is a filename starting with a "/", then it names a file from +which DH parameters should be loaded. If the file exists, it should hold a +PEM-encoded PKCS#3 representation of the DH prime. If the file does not exist, +for OpenSSL it is an error. For GnuTLS, Exim will attempt to create the file +and fill it with a generated DH prime. For OpenSSL, if the DH bit-count from +loading the file is greater than tls_dh_max_bits then it will be ignored, and +treated as though the tls_dhparam were set to "none". + +If this option expands to the string "none", then no DH parameters will be +loaded by Exim. + +If this option expands to the string "historic" and Exim is using GnuTLS, then +Exim will attempt to load a file from inside the spool directory. If the file +does not exist, Exim will attempt to create it. See section 42.3 for further +details. + +If Exim is using OpenSSL and this option is empty or unset, then Exim will load +a default DH prime; the default is Exim-specific but lacks verifiable +provenance. + +In older versions of Exim the default was the 2048 bit prime described in +section 2.2 of RFC 5114, "2048-bit MODP Group with 224-bit Prime Order +Subgroup", which in IKE is assigned number 23. + +Otherwise, the option must expand to the name used by Exim for any of a number +of DH primes specified in RFC 2409, RFC 3526, RFC 5114, RFC 7919, or from other +sources. As names, Exim uses a standard specified name, else "ike" followed by +the number used by IKE, or "default" which corresponds to +"exim.dev.20160529.3". + +The available standard primes are: "ffdhe2048", "ffdhe3072", "ffdhe4096", +"ffdhe6144", "ffdhe8192", "ike1", "ike2", "ike5", "ike14", "ike15", "ike16", +"ike17", "ike18", "ike22", "ike23" and "ike24". + +The available additional primes are: "exim.dev.20160529.1", +"exim.dev.20160529.2" and "exim.dev.20160529.3". + +Some of these will be too small to be accepted by clients. Some may be too +large to be accepted by clients. The open cryptographic community has +suspicions about the integrity of some of the later IKE values, which led into +RFC7919 providing new fixed constants (the "ffdhe" identifiers). + +At this point, all of the "ike" values should be considered obsolete; they're +still in Exim to avoid breaking unusual configurations, but are candidates for +removal the next time we have backwards-incompatible changes. + +The TLS protocol does not negotiate an acceptable size for this; clients tend +to hard-drop connections if what is offered by the server is unacceptable, +whether too large or too small, and there's no provision for the client to tell +the server what these constraints are. Thus, as a server operator, you need to +make an educated guess as to what is most likely to work for your userbase. + +Some known size constraints suggest that a bit-size in the range 2048 to 2236 +is most likely to maximise interoperability. The upper bound comes from +applications using the Mozilla Network Security Services (NSS) library, which +used to set its "DH_MAX_P_BITS" upper-bound to 2236. This affects many mail +user agents (MUAs). The lower bound comes from Debian installs of Exim4 prior +to the 4.80 release, as Debian used to patch Exim to raise the minimum +acceptable bound from 1024 to 2048. + ++---------------------------------------------------+ +|tls_eccurve|Use: main|Type: string*|Default: "auto"| ++---------------------------------------------------+ + +This option selects a EC curve for use by Exim when used with OpenSSL. It has +no effect when Exim is used with GnuTLS. + +After expansion it must contain a valid EC curve parameter, such as +"prime256v1", "secp384r1", or "P-512". Consult your OpenSSL manual for valid +selections. + +For OpenSSL versions before (and not including) 1.0.2, the string "auto" +selects "prime256v1". For more recent OpenSSL versions "auto" tells the library +to choose. + +If the option expands to an empty string, no EC curves will be enabled. + ++----------------------------------------------------+ +|tls_ocsp_file|Use: main|Type: string*|Default: unset| ++----------------------------------------------------+ + +This option must if set expand to the absolute path to a file which contains a +current status proof for the server's certificate, as obtained from the +Certificate Authority. + +Usable for GnuTLS 3.4.4 or 3.3.17 or OpenSSL 1.1.0 (or later). + +For GnuTLS 3.5.6 or later the expanded value of this option can be a list of +files, to match a list given for the tls_certificate option. The ordering of +the two lists must match. + ++---------------------------------------------------------------+ +|tls_on_connect_ports|Use: main|Type: string list|Default: unset| ++---------------------------------------------------------------+ + +This option specifies a list of incoming SSMTP (aka SMTPS) ports that should +operate the SSMTP (SMTPS) protocol, where a TLS session is immediately set up +without waiting for the client to issue a STARTTLS command. For further +details, see section 13.4. + ++----------------------------------------------------+ +|tls_privatekey|Use: main|Type: string|Default: list*| ++----------------------------------------------------+ + +The value of this option is expanded, and must then be a list of absolute paths +to files which contains the server's private keys. If this option is unset, or +if the expansion is forced to fail, or the result is an empty string, the +private key is assumed to be in the same file as the server's certificates. See +chapter 42 for further details. + +See 42.10 for discussion of when this option might be re-expanded. + ++---------------------------------------------------------+ +|tls_remember_esmtp|Use: main|Type: boolean|Default: false| ++---------------------------------------------------------+ + +If this option is set true, Exim violates the RFCs by remembering that it is in +"esmtp" state after successfully negotiating a TLS session. This provides +support for broken clients that fail to send a new EHLO after starting a TLS +session. + ++----------------------------------------------------------+ +|tls_require_ciphers|Use: main|Type: string*|Default: unset| ++----------------------------------------------------------+ + +This option controls which ciphers can be used for incoming TLS connections. +The smtp transport has an option of the same name for controlling outgoing +connections. This option is expanded for each connection, so can be varied for +different clients if required. The value of this option must be a list of +permitted cipher suites. The OpenSSL and GnuTLS libraries handle cipher control +in somewhat different ways. If GnuTLS is being used, the client controls the +preference order of the available ciphers. Details are given in sections 42.4 +and 42.5. + ++--------------------------------------------------------------+ +|tls_try_verify_hosts|Use: main|Type: host list*|Default: unset| ++--------------------------------------------------------------+ + +See tls_verify_hosts below. + ++---------------------------------------------------------------+ +|tls_verify_certificates|Use: main|Type: string*|Default: system| ++---------------------------------------------------------------+ + +The value of this option is expanded, and must then be either the word "system" +or the absolute path to a file or directory containing permitted certificates +for clients that match tls_verify_hosts or tls_try_verify_hosts. + +The "system" value for the option will use a system default location compiled +into the SSL library. This is not available for GnuTLS versions preceding +3.0.20, and will be taken as empty; an explicit location must be specified. + +The use of a directory for the option value is not available for GnuTLS +versions preceding 3.3.6 and a single file must be used. + +With OpenSSL the certificates specified explicitly either by file or directory +are added to those given by the system default location. + +These certificates should be for the certificate authorities trusted, rather +than the public cert of individual clients. With both OpenSSL and GnuTLS, if +the value is a file then the certificates are sent by Exim as a server to +connecting clients, defining the list of accepted certificate authorities. Thus +the values defined should be considered public data. To avoid this, use the +explicit directory version. + +See 42.10 for discussion of when this option might be re-expanded. + +A forced expansion failure or setting to an empty string is equivalent to being +unset. + ++----------------------------------------------------------+ +|tls_verify_hosts|Use: main|Type: host list*|Default: unset| ++----------------------------------------------------------+ + +This option, along with tls_try_verify_hosts, controls the checking of +certificates from clients. The expected certificates are defined by +tls_verify_certificates, which must be set. A configuration error occurs if +either tls_verify_hosts or tls_try_verify_hosts is set and +tls_verify_certificates is not set. + +Any client that matches tls_verify_hosts is constrained by +tls_verify_certificates. When the client initiates a TLS session, it must +present one of the listed certificates. If it does not, the connection is +aborted. Warning: Including a host in tls_verify_hosts does not require the +host to use TLS. It can still send SMTP commands through unencrypted +connections. Forcing a client to use TLS has to be done separately using an ACL +to reject inappropriate commands when the connection is not encrypted. + +A weaker form of checking is provided by tls_try_verify_hosts. If a client +matches this option (but not tls_verify_hosts), Exim requests a certificate and +checks it against tls_verify_certificates, but does not abort the connection if +there is no certificate or if it does not match. This state can be detected in +an ACL, which makes it possible to implement policies such as "accept for relay +only if a verified certificate has been received, but accept for local delivery +if encrypted, even without a verified certificate". + +Client hosts that match neither of these lists are not asked to present +certificates. + ++----------------------------------------------------------+ +|trusted_groups|Use: main|Type: string list*|Default: unset| ++----------------------------------------------------------+ + +This option is expanded just once, at the start of Exim's processing. If this +option is set, any process that is running in one of the listed groups, or +which has one of them as a supplementary group, is trusted. The groups can be +specified numerically or by name. See section 5.2 for details of what trusted +callers are permitted to do. If neither trusted_groups nor trusted_users is +set, only root and the Exim user are trusted. + ++---------------------------------------------------------+ +|trusted_users|Use: main|Type: string list*|Default: unset| ++---------------------------------------------------------+ + +This option is expanded just once, at the start of Exim's processing. If this +option is set, any process that is running as one of the listed users is +trusted. The users can be specified numerically or by name. See section 5.2 for +details of what trusted callers are permitted to do. If neither trusted_groups +nor trusted_users is set, only root and the Exim user are trusted. + ++----------------------------------------------------+ +|unknown_login|Use: main|Type: string*|Default: unset| ++----------------------------------------------------+ + +This is a specialized feature for use in unusual configurations. By default, if +the uid of the caller of Exim cannot be looked up using getpwuid(), Exim gives +up. The unknown_login option can be used to set a login name to be used in this +circumstance. It is expanded, so values like user$caller_uid can be set. When +unknown_login is used, the value of unknown_username is used for the user's +real name (gecos field), unless this has been set by the -F option. + ++------------------------------------------------------+ +|unknown_username|Use: main|Type: string|Default: unset| ++------------------------------------------------------+ + +See unknown_login. + ++-----------------------------------------------------------------+ +|untrusted_set_sender|Use: main|Type: address list*|Default: unset| ++-----------------------------------------------------------------+ + +When an untrusted user submits a message to Exim using the standard input, Exim +normally creates an envelope sender address from the user's login and the +default qualification domain. Data from the -f option (for setting envelope +senders on non-SMTP messages) or the SMTP MAIL command (if -bs or -bS is used) +is ignored. + +However, untrusted users are permitted to set an empty envelope sender address, +to declare that a message should never generate any bounces. For example: + +exim -f '<>' user@domain.example + +The untrusted_set_sender option allows you to permit untrusted users to set +other envelope sender addresses in a controlled way. When it is set, untrusted +users are allowed to set envelope sender addresses that match any of the +patterns in the list. Like all address lists, the string is expanded. The +identity of the user is in $sender_ident, so you can, for example, restrict +users to setting senders that start with their login ids followed by a hyphen +by a setting like this: + +untrusted_set_sender = ^$sender_ident- + +If you want to allow untrusted users to set envelope sender addresses without +restriction, you can use + +untrusted_set_sender = * + +The untrusted_set_sender option applies to all forms of local input, but only +to the setting of the envelope sender. It does not permit untrusted users to +use the other options which trusted user can use to override message +parameters. Furthermore, it does not stop Exim from removing an existing +Sender: header in the message, or from adding a Sender: header if necessary. +See local_sender_retain and local_from_check for ways of overriding these +actions. The handling of the Sender: header is also described in section 47.16. + +The log line for a message's arrival shows the envelope sender following "<=". +For local messages, the user's login always follows, after "U=". In -bp +displays, and in the Exim monitor, if an untrusted user sets an envelope sender +address, the user's login is shown in parentheses after the sender address. + ++-----------------------------------------------------------+ +|uucp_from_pattern|Use: main|Type: string|Default: see below| ++-----------------------------------------------------------+ + +Some applications that pass messages to an MTA via a command line interface use +an initial line starting with "From " to pass the envelope sender. In +particular, this is used by UUCP software. Exim recognizes such a line by means +of a regular expression that is set in uucp_from_pattern. When the pattern +matches, the sender address is constructed by expanding the contents of +uucp_from_sender, provided that the caller of Exim is a trusted user. The +default pattern recognizes lines in the following two forms: + +From ph10 Fri Jan 5 12:35 GMT 1996 +From ph10 Fri, 7 Jan 97 14:00:00 GMT + +The pattern can be seen by running + +exim -bP uucp_from_pattern + +It checks only up to the hours and minutes, and allows for a 2-digit or 4-digit +year in the second case. The first word after "From " is matched in the regular +expression by a parenthesized subpattern. The default value for +uucp_from_sender is "$1", which therefore just uses this first word ("ph10" in +the example above) as the message's sender. See also ignore_fromline_hosts. + ++------------------------------------------------------+ +|uucp_from_sender|Use: main|Type: string*|Default: "$1"| ++------------------------------------------------------+ + +See uucp_from_pattern above. + ++-------------------------------------------------------+ +|warn_message_file|Use: main|Type: string|Default: unset| ++-------------------------------------------------------+ + +This option defines a template file containing paragraphs of text to be used +for constructing the warning message which is sent by Exim when a message has +been in the queue for a specified amount of time, as specified by delay_warning +. Details of the file's contents are given in chapter 49. See also +bounce_message_file. + ++-----------------------------------------------------+ +|write_rejectlog|Use: main|Type: boolean|Default: true| ++-----------------------------------------------------+ + +If this option is set false, Exim no longer writes anything to the reject log. +See chapter 52 for details of what Exim writes to its logs. + + + +=============================================================================== +15. GENERIC OPTIONS FOR ROUTERS + +This chapter describes the generic options that apply to all routers. Those +that are preconditions are marked with ** in the "use" field. + +For a general description of how a router operates, see sections 3.10 and 3.12. +The latter specifies the order in which the preconditions are tested. The order +of expansion of the options that provide data for a transport is: errors_to, +headers_add, headers_remove, transport. + ++------------------------------------------------------+ +|address_data|Use: routers|Type: string*|Default: unset| ++------------------------------------------------------+ + +The string is expanded just before the router is run, that is, after all the +precondition tests have succeeded. If the expansion is forced to fail, the +router declines, the value of address_data remains unchanged, and the more +option controls what happens next. Other expansion failures cause delivery of +the address to be deferred. + +When the expansion succeeds, the value is retained with the address, and can be +accessed using the variable $address_data in the current router, subsequent +routers, and the eventual transport. + +Warning: If the current or any subsequent router is a redirect router that runs +a user's filter file, the contents of $address_data are accessible in the +filter. This is not normally a problem, because such data is usually either not +confidential or it "belongs" to the current user, but if you do put +confidential data into $address_data you need to remember this point. + +Even if the router declines or passes, the value of $address_data remains with +the address, though it can be changed by another address_data setting on a +subsequent router. If a router generates child addresses, the value of +$address_data propagates to them. This also applies to the special kind of +"child" that is generated by a router with the unseen option. + +The idea of address_data is that you can use it to look up a lot of data for +the address once, and then pick out parts of the data later. For example, you +could use a single LDAP lookup to return a string of the form + +uid=1234 gid=5678 mailbox=/mail/xyz forward=/home/xyz/.forward + +In the transport you could pick out the mailbox by a setting such as + +file = ${extract{mailbox}{$address_data}} + +This makes the configuration file less messy, and also reduces the number of +lookups (though Exim does cache lookups). + +The address_data facility is also useful as a means of passing information from +one router to another, and from a router to a transport. In addition, if +$address_data is set by a router when verifying a recipient address from an +ACL, it remains available for use in the rest of the ACL statement. After +verifying a sender, the value is transferred to $sender_address_data. + ++-------------------------------------------------------+ +|address_test|Use: routers**|Type: boolean|Default: true| ++-------------------------------------------------------+ + +If this option is set false, the router is skipped when routing is being tested +by means of the -bt command line option. This can be a convenience when your +first router sends messages to an external scanner, because it saves you having +to set the "already scanned" indicator when testing real address routing. + ++--------------------------------------------------------------+ +|cannot_route_message|Use: routers|Type: string*|Default: unset| ++--------------------------------------------------------------+ + +This option specifies a text message that is used when an address cannot be +routed because Exim has run out of routers. The default message is "Unrouteable +address". This option is useful only on routers that have more set false, or on +the very last router in a configuration, because the value that is used is +taken from the last router that is considered. This includes a router that is +skipped because its preconditions are not met, as well as a router that +declines. For example, using the default configuration, you could put: + +cannot_route_message = Remote domain not found in DNS + +on the first router, which is a dnslookup router with more set false, and + +cannot_route_message = Unknown local user + +on the final router that checks for local users. If string expansion fails for +this option, the default message is used. Unless the expansion failure was +explicitly forced, a message about the failure is written to the main and panic +logs, in addition to the normal message about the routing failure. + ++------------------------------------------------------------+ +|caseful_local_part|Use: routers|Type: boolean|Default: false| ++------------------------------------------------------------+ + +By default, routers handle the local parts of addresses in a case-insensitive +manner, though the actual case is preserved for transmission with the message. +If you want the case of letters to be significant in a router, you must set +this option true. For individual router options that contain address or local +part lists (for example, local_parts), case-sensitive matching can be turned on +by "+caseful" as a list item. See section 10.20 for more details. + +The value of the $local_part variable is forced to lower case while a router is +running unless caseful_local_part is set. When a router assigns an address to a +transport, the value of $local_part when the transport runs is the same as it +was in the router. Similarly, when a router generates child addresses by +aliasing or forwarding, the values of $original_local_part and +$parent_local_part are those that were used by the redirecting router. + +This option applies to the processing of an address by a router. When a +recipient address is being processed in an ACL, there is a separate control +modifier that can be used to specify case-sensitive processing within the ACL +(see section 43.22). + ++------------------------------------------------------------+ +|check_local_user|Use: routers**|Type: boolean|Default: false| ++------------------------------------------------------------+ + +When this option is true, Exim checks that the local part of the recipient +address (with affixes removed if relevant) is the name of an account on the +local system. The check is done by calling the getpwnam() function rather than +trying to read /etc/passwd directly. This means that other methods of holding +password data (such as NIS) are supported. If the local part is a local user, +$home is set from the password data, and can be tested in other preconditions +that are evaluated after this one (the order of evaluation is given in section +3.12). However, the value of $home can be overridden by router_home_directory. +If the local part is not a local user, the router is skipped. + +If you want to check that the local part is either the name of a local user or +matches something else, you cannot combine check_local_user with a setting of +local_parts, because that specifies the logical and of the two conditions. +However, you can use a passwd lookup in a local_parts setting to achieve this. +For example: + +local_parts = passwd;$local_part : lsearch;/etc/other/users + +Note, however, that the side effects of check_local_user (such as setting up a +home directory) do not occur when a passwd lookup is used in a local_parts (or +any other) precondition. + ++-----------------------------------------------------+ +|condition|Use: routers**|Type: string*|Default: unset| ++-----------------------------------------------------+ + +This option specifies a general precondition test that has to succeed for the +router to be called. The condition option is the last precondition to be +evaluated (see section 3.12). The string is expanded, and if the result is a +forced failure, or an empty string, or one of the strings "0" or "no" or +"false" (checked without regard to the case of the letters), the router is +skipped, and the address is offered to the next one. + +If the result is any other value, the router is run (as this is the last +precondition to be evaluated, all the other preconditions must be true). + +This option is unusual in that multiple condition options may be present. All +condition options must succeed. + +The condition option provides a means of applying custom conditions to the +running of routers. Note that in the case of a simple conditional expansion, +the default expansion values are exactly what is wanted. For example: + +condition = ${if >{$message_age}{600}} + +Because of the default behaviour of the string expansion, this is equivalent to + +condition = ${if >{$message_age}{600}{true}{}} + +A multiple condition example, which succeeds: + +condition = ${if >{$message_age}{600}} +condition = ${if !eq{${lc:$local_part}}{postmaster}} +condition = foobar + +If the expansion fails (other than forced failure) delivery is deferred. Some +of the other precondition options are common special cases that could in fact +be specified using condition. + +Historical note: We have condition on ACLs and on Routers. Routers are far +older, and use one set of semantics. ACLs are newer and when they were created, +the ACL condition process was given far stricter parse semantics. The bool{} +expansion condition uses the same rules as ACLs. The bool_lax{} expansion +condition uses the same rules as Routers. More pointedly, the bool_lax{} was +written to match the existing Router rules processing behavior. + +This is best illustrated in an example: + +# If used in an ACL condition will fail with a syntax error, but +# in a router condition any extra characters are treated as a string + +$ exim -be '${if eq {${lc:GOOGLE.com}} {google.com}} {yes} {no}}' +true {yes} {no}} + +$ exim -be '${if eq {${lc:WHOIS.com}} {google.com}} {yes} {no}}' + {yes} {no}} + +In each example above, the if statement actually ends after "{google.com}}". +Since no true or false braces were defined, the default if behavior is to +return a boolean true or a null answer (which evaluates to false). The rest of +the line is then treated as a string. So the first example resulted in the +boolean answer "true" with the string " {yes} {no}}" appended to it. The second +example resulted in the null output (indicating false) with the string " {yes} +{no}}" appended to it. + +In fact you can put excess forward braces in too. In the router condition, +Exim's parser only looks for "{" symbols when they mean something, like after a +"$" or when required as part of a conditional. But otherwise "{" and "}" are +treated as ordinary string characters. + +Thus, in a Router, the above expansion strings will both always evaluate true, +as the result of expansion is a non-empty string which doesn't match an +explicit false value. This can be tricky to debug. By contrast, in an ACL +either of those strings will always result in an expansion error because the +result doesn't look sufficiently boolean. + ++-----------------------------------------------------+ +|debug_print|Use: routers|Type: string*|Default: unset| ++-----------------------------------------------------+ + +If this option is set and debugging is enabled (see the -d command line option) +or in address-testing mode (see the -bt command line option), the string is +expanded and included in the debugging output. If expansion of the string +fails, the error message is written to the debugging output, and Exim carries +on processing. This option is provided to help with checking out the values of +variables and so on when debugging router configurations. For example, if a +condition option appears not to be working, debug_print can be used to output +the variables it references. The output happens after checks for domains, +local_parts, and check_local_user but before any other preconditions are +tested. A newline is added to the text if it does not end with one. The +variable $router_name contains the name of the router. + ++---------------------------------------------------------+ +|disable_logging|Use: routers|Type: boolean|Default: false| ++---------------------------------------------------------+ + +If this option is set true, nothing is logged for any routing errors or for any +deliveries caused by this router. You should not set this option unless you +really, really know what you are doing. See also the generic transport option +of the same name. + ++---------------------------------------------------------------------+ +|dnssec_request_domains|Use: routers|Type: domain list*|Default: unset| ++---------------------------------------------------------------------+ + +DNS lookups for domains matching dnssec_request_domains will be done with the +dnssec request bit set. This applies to all of the SRV, MX, AAAA, A lookup +sequence. + ++---------------------------------------------------------------------+ +|dnssec_require_domains|Use: routers|Type: domain list*|Default: unset| ++---------------------------------------------------------------------+ + +DNS lookups for domains matching dnssec_require_domains will be done with the +dnssec request bit set. Any returns not having the Authenticated Data bit (AD +bit) set will be ignored and logged as a host-lookup failure. This applies to +all of the SRV, MX, AAAA, A lookup sequence. + ++--------------------------------------------------------+ +|domains|Use: routers**|Type: domain list*|Default: unset| ++--------------------------------------------------------+ + +If this option is set, the router is skipped unless the current domain matches +the list. If the match is achieved by means of a file lookup, the data that the +lookup returned for the domain is placed in $domain_data for use in string +expansions of the driver's private options. See section 3.12 for a list of the +order in which preconditions are evaluated. + ++-----------------------------------------------+ +|driver|Use: routers|Type: string|Default: unset| ++-----------------------------------------------+ + +This option must always be set. It specifies which of the available routers is +to be used. + ++-----------------------------------------------------+ +|dsn_lasthop|Use: routers|Type: boolean|Default: false| ++-----------------------------------------------------+ + +If this option is set true, and extended DSN (RFC3461) processing is in effect, +Exim will not pass on DSN requests to downstream DSN-aware hosts but will +instead send a success DSN as if the next hop does not support DSN. Not +effective on redirect routers. + ++---------------------------------------------------+ +|errors_to|Use: routers|Type: string*|Default: unset| ++---------------------------------------------------+ + +If a router successfully handles an address, it may assign the address to a +transport for delivery or it may generate child addresses. In both cases, if +there is a delivery problem during later processing, the resulting bounce +message is sent to the address that results from expanding this string, +provided that the address verifies successfully. The errors_to option is +expanded before headers_add, headers_remove, and transport. + +The errors_to setting associated with an address can be overridden if it +subsequently passes through other routers that have their own errors_to +settings, or if the message is delivered by a transport with a return_path +setting. + +If errors_to is unset, or the expansion is forced to fail, or the result of the +expansion fails to verify, the errors address associated with the incoming +address is used. At top level, this is the envelope sender. A non-forced +expansion failure causes delivery to be deferred. + +If an address for which errors_to has been set ends up being delivered over +SMTP, the envelope sender for that delivery is the errors_to value, so that any +bounces that are generated by other MTAs on the delivery route are also sent +there. You can set errors_to to the empty string by either of these settings: + +errors_to = +errors_to = "" + +An expansion item that yields an empty string has the same effect. If you do +this, a locally detected delivery error for addresses processed by this router +no longer gives rise to a bounce message; the error is discarded. If the +address is delivered to a remote host, the return path is set to "<>", unless +overridden by the return_path option on the transport. + +If for some reason you want to discard local errors, but use a non-empty MAIL +command for remote delivery, you can preserve the original return path in +$address_data in the router, and reinstate it in the transport by setting +return_path. + +The most common use of errors_to is to direct mailing list bounces to the +manager of the list, as described in section 50.2, or to implement VERP +(Variable Envelope Return Paths) (see section 50.6). + ++-----------------------------------------------+ +|expn|Use: routers**|Type: boolean|Default: true| ++-----------------------------------------------+ + +If this option is turned off, the router is skipped when testing an address as +a result of processing an SMTP EXPN command. You might, for example, want to +turn it off on a router for users' .forward files, while leaving it on for the +system alias file. See section 3.12 for a list of the order in which +preconditions are evaluated. + +The use of the SMTP EXPN command is controlled by an ACL (see chapter 43). When +Exim is running an EXPN command, it is similar to testing an address with -bt. +Compare VRFY, whose counterpart is -bv. + ++-----------------------------------------------------+ +|fail_verify|Use: routers|Type: boolean|Default: false| ++-----------------------------------------------------+ + +Setting this option has the effect of setting both fail_verify_sender and +fail_verify_recipient to the same value. + ++---------------------------------------------------------------+ +|fail_verify_recipient|Use: routers|Type: boolean|Default: false| ++---------------------------------------------------------------+ + +If this option is true and an address is accepted by this router when verifying +a recipient, verification fails. + ++------------------------------------------------------------+ +|fail_verify_sender|Use: routers|Type: boolean|Default: false| ++------------------------------------------------------------+ + +If this option is true and an address is accepted by this router when verifying +a sender, verification fails. + ++------------------------------------------------------------+ +|fallback_hosts|Use: routers|Type: string list|Default: unset| ++------------------------------------------------------------+ + +String expansion is not applied to this option. The argument must be a +colon-separated list of host names or IP addresses. The list separator can be +changed (see section 6.21), and a port can be specified with each name or +address. In fact, the format of each item is exactly the same as defined for +the list of hosts in a manualroute router (see section 20.5). + +If a router queues an address for a remote transport, this host list is +associated with the address, and used instead of the transport's fallback host +list. If hosts_randomize is set on the transport, the order of the list is +randomized for each use. See the fallback_hosts option of the smtp transport +for further details. + ++---------------------------------------------------+ +|group|Use: routers|Type: string*|Default: see below| ++---------------------------------------------------+ + +When a router queues an address for a transport, and the transport does not +specify a group, the group given here is used when running the delivery +process. The group may be specified numerically or by name. If expansion fails, +the error is logged and delivery is deferred. The default is unset, unless +check_local_user is set, when the default is taken from the password +information. See also initgroups and user and the discussion in chapter 23. + ++---------------------------------------------------+ +|headers_add|Use: routers|Type: list*|Default: unset| ++---------------------------------------------------+ + +This option specifies a list of text headers, newline-separated (by default, +changeable in the usual way 6.21), that is associated with any addresses that +are accepted by the router. Each item is separately expanded, at routing time. +However, this option has no effect when an address is just being verified. The +way in which the text is used to add header lines at transport time is +described in section 47.17. New header lines are not actually added until the +message is in the process of being transported. This means that references to +header lines in string expansions in the transport's configuration do not "see" +the added header lines. + +The headers_add option is expanded after errors_to, but before headers_remove +and transport. If an item is empty, or if an item expansion is forced to fail, +the item has no effect. Other expansion failures are treated as configuration +errors. + +Unlike most options, headers_add can be specified multiple times for a router; +all listed headers are added. + +Warning 1: The headers_add option cannot be used for a redirect router that has +the one_time option set. + +Warning 2: If the unseen option is set on the router, all header additions are +deleted when the address is passed on to subsequent routers. For a redirect +router, if a generated address is the same as the incoming address, this can +lead to duplicate addresses with different header modifications. Exim does not +do duplicate deliveries (except, in certain circumstances, to pipes -- see +section 22.7), but it is undefined which of the duplicates is discarded, so +this ambiguous situation should be avoided. The repeat_use option of the +redirect router may be of help. + ++------------------------------------------------------+ +|headers_remove|Use: routers|Type: list*|Default: unset| ++------------------------------------------------------+ + +This option specifies a list of text headers, colon-separated (by default, +changeable in the usual way 6.21), that is associated with any addresses that +are accepted by the router. Each item is separately expanded, at routing time. +However, this option has no effect when an address is just being verified. The +way in which the text is used to remove header lines at transport time is +described in section 47.17. Header lines are not actually removed until the +message is in the process of being transported. This means that references to +header lines in string expansions in the transport's configuration still "see" +the original header lines. + +The headers_remove option is expanded after errors_to and headers_add, but +before transport. If an item expansion is forced to fail, the item has no +effect. Other expansion failures are treated as configuration errors. + +Unlike most options, headers_remove can be specified multiple times for a +router; all listed headers are removed. + +Warning 1: The headers_remove option cannot be used for a redirect router that +has the one_time option set. + +Warning 2: If the unseen option is set on the router, all header removal +requests are deleted when the address is passed on to subsequent routers, and +this can lead to problems with duplicates -- see the similar warning for +headers_add above. + +Warning 3: Because of the separate expansion of the list items, items that +contain a list separator must have it doubled. To avoid this, change the list +separator (6.21). + ++----------------------------------------------------------------+ +|ignore_target_hosts|Use: routers|Type: host list*|Default: unset| ++----------------------------------------------------------------+ + +Although this option is a host list, it should normally contain IP address +entries rather than names. If any host that is looked up by the router has an +IP address that matches an item in this list, Exim behaves as if that IP +address did not exist. This option allows you to cope with rogue DNS entries +like + +remote.domain.example. A 127.0.0.1 + +by setting + +ignore_target_hosts = 127.0.0.1 + +on the relevant router. If all the hosts found by a dnslookup router are +discarded in this way, the router declines. In a conventional configuration, an +attempt to mail to such a domain would normally provoke the "unrouteable +domain" error, and an attempt to verify an address in the domain would fail. +Similarly, if ignore_target_hosts is set on an ipliteral router, the router +declines if presented with one of the listed addresses. + +You can use this option to disable the use of IPv4 or IPv6 for mail delivery by +means of the first or the second of the following settings, respectively: + +ignore_target_hosts = 0.0.0.0/0 +ignore_target_hosts = <; 0::0/0 + +The pattern in the first line matches all IPv4 addresses, whereas the pattern +in the second line matches all IPv6 addresses. + +This option may also be useful for ignoring link-local and site-local IPv6 +addresses. Because, like all host lists, the value of ignore_target_hosts is +expanded before use as a list, it is possible to make it dependent on the +domain that is being routed. + +During its expansion, $host_address is set to the IP address that is being +checked. + ++----------------------------------------------------+ +|initgroups|Use: routers|Type: boolean|Default: false| ++----------------------------------------------------+ + +If the router queues an address for a transport, and this option is true, and +the uid supplied by the router is not overridden by the transport, the +initgroups() function is called when running the transport to ensure that any +additional groups associated with the uid are set up. See also group and user +and the discussion in chapter 23. + ++-----------------------------------------------------------------+ +|local_part_prefix|Use: routers**|Type: string list|Default: unset| ++-----------------------------------------------------------------+ + +If this option is set, the router is skipped unless the local part starts with +one of the given strings, or local_part_prefix_optional is true. See section +3.12 for a list of the order in which preconditions are evaluated. + +The list is scanned from left to right, and the first prefix that matches is +used. A limited form of wildcard is available; if the prefix begins with an +asterisk, it matches the longest possible sequence of arbitrary characters at +the start of the local part. An asterisk should therefore always be followed by +some character that does not occur in normal local parts. Wildcarding can be +used to set up multiple user mailboxes, as described in section 50.8. + +During the testing of the local_parts option, and while the router is running, +the prefix is removed from the local part, and is available in the expansion +variable $local_part_prefix. When a message is being delivered, if the router +accepts the address, this remains true during subsequent delivery by a +transport. In particular, the local part that is transmitted in the RCPT +command for LMTP, SMTP, and BSMTP deliveries has the prefix removed by default. +This behaviour can be overridden by setting rcpt_include_affixes true on the +relevant transport. + +When an address is being verified, local_part_prefix affects only the behaviour +of the router. If the callout feature of verification is in use, this means +that the full address, including the prefix, will be used during the callout. + +The prefix facility is commonly used to handle local parts of the form +owner-something. Another common use is to support local parts of the form +real-username to bypass a user's .forward file - helpful when trying to tell a +user their forwarding is broken - by placing a router like this one immediately +before the router that handles .forward files: + +real_localuser: + driver = accept + local_part_prefix = real- + check_local_user + transport = local_delivery + +For security, it would probably be a good idea to restrict the use of this +router to locally-generated messages, using a condition such as this: + + condition = ${if match {$sender_host_address}\ + {\N^(|127\.0\.0\.1)$\N}} + +If both local_part_prefix and local_part_suffix are set for a router, both +conditions must be met if not optional. Care must be taken if wildcards are +used in both a prefix and a suffix on the same router. Different separator +characters must be used to avoid ambiguity. + ++--------------------------------------------------------------------+ +|local_part_prefix_optional|Use: routers|Type: boolean|Default: false| ++--------------------------------------------------------------------+ + +See local_part_prefix above. + ++-----------------------------------------------------------------+ +|local_part_suffix|Use: routers**|Type: string list|Default: unset| ++-----------------------------------------------------------------+ + +This option operates in the same way as local_part_prefix, except that the +local part must end (rather than start) with the given string, the +local_part_suffix_optional option determines whether the suffix is mandatory, +and the wildcard * character, if present, must be the last character of the +suffix. This option facility is commonly used to handle local parts of the form +something-request and multiple user mailboxes of the form username-foo. + ++--------------------------------------------------------------------+ +|local_part_suffix_optional|Use: routers|Type: boolean|Default: false| ++--------------------------------------------------------------------+ + +See local_part_suffix above. + ++----------------------------------------------------------------+ +|local_parts|Use: routers**|Type: local part list*|Default: unset| ++----------------------------------------------------------------+ + +The router is run only if the local part of the address matches the list. See +section 3.12 for a list of the order in which preconditions are evaluated, and +section 10.21 for a discussion of local part lists. Because the string is +expanded, it is possible to make it depend on the domain, for example: + +local_parts = dbm;/usr/local/specials/$domain + +If the match is achieved by a lookup, the data that the lookup returned for the +local part is placed in the variable $local_part_data for use in expansions of +the router's private options. You might use this option, for example, if you +have a large number of local virtual domains, and you want to send all +postmaster mail to the same place without having to set up an alias in each +virtual domain: + +postmaster: + driver = redirect + local_parts = postmaster + data = postmaster@real.domain.example + ++----------------------------------------------------------+ +|log_as_local|Use: routers|Type: boolean|Default: see below| ++----------------------------------------------------------+ + +Exim has two logging styles for delivery, the idea being to make local +deliveries stand out more visibly from remote ones. In the "local" style, the +recipient address is given just as the local part, without a domain. The use of +this style is controlled by this option. It defaults to true for the accept +router, and false for all the others. This option applies only when a router +assigns an address to a transport. It has no effect on routers that redirect +addresses. + ++----------------------------------------------+ +|more|Use: routers|Type: boolean*|Default: true| ++----------------------------------------------+ + +The result of string expansion for this option must be a valid boolean value, +that is, one of the strings "yes", "no", "true", or "false". Any other result +causes an error, and delivery is deferred. If the expansion is forced to fail, +the default value for the option (true) is used. Other failures cause delivery +to be deferred. + +If this option is set false, and the router declines to handle the address, no +further routers are tried, routing fails, and the address is bounced. However, +if the router explicitly passes an address to the following router by means of +the setting + +self = pass + +or otherwise, the setting of more is ignored. Also, the setting of more does +not affect the behaviour if one of the precondition tests fails. In that case, +the address is always passed to the next router. + +Note that address_data is not considered to be a precondition. If its expansion +is forced to fail, the router declines, and the value of more controls what +happens next. + ++---------------------------------------------------------+ +|pass_on_timeout|Use: routers|Type: boolean|Default: false| ++---------------------------------------------------------+ + +If a router times out during a host lookup, it normally causes deferral of the +address. If pass_on_timeout is set, the address is passed on to the next +router, overriding no_more. This may be helpful for systems that are +intermittently connected to the Internet, or those that want to pass to a smart +host any messages that cannot immediately be delivered. + +There are occasional other temporary errors that can occur while doing DNS +lookups. They are treated in the same way as a timeout, and this option applies +to all of them. + ++----------------------------------------------------+ +|pass_router|Use: routers|Type: string|Default: unset| ++----------------------------------------------------+ + +Routers that recognize the generic self option (dnslookup, ipliteral, and +manualroute) are able to return "pass", forcing routing to continue, and +overriding a false setting of more. When one of these routers returns "pass", +the address is normally handed on to the next router in sequence. This can be +changed by setting pass_router to the name of another router. However (unlike +redirect_router) the named router must be below the current router, to avoid +loops. Note that this option applies only to the special case of "pass". It +does not apply when a router returns "decline" because it cannot handle an +address. + ++--------------------------------------------------------+ +|redirect_router|Use: routers|Type: string|Default: unset| ++--------------------------------------------------------+ + +Sometimes an administrator knows that it is pointless to reprocess addresses +generated from alias or forward files with the same router again. For example, +if an alias file translates real names into login ids there is no point +searching the alias file a second time, especially if it is a large file. + +The redirect_router option can be set to the name of any router instance. It +causes the routing of any generated addresses to start at the named router +instead of at the first router. This option has no effect if the router in +which it is set does not generate new addresses. + ++--------------------------------------------------------------+ +|require_files|Use: routers**|Type: string list*|Default: unset| ++--------------------------------------------------------------+ + +This option provides a general mechanism for predicating the running of a +router on the existence or non-existence of certain files or directories. +Before running a router, as one of its precondition tests, Exim works its way +through the require_files list, expanding each item separately. + +Because the list is split before expansion, any colons in expansion items must +be doubled, or the facility for using a different list separator must be used ( +6.21). If any expansion is forced to fail, the item is ignored. Other expansion +failures cause routing of the address to be deferred. + +If any expanded string is empty, it is ignored. Otherwise, except as described +below, each string must be a fully qualified file path, optionally preceded by +"!". The paths are passed to the stat() function to test for the existence of +the files or directories. The router is skipped if any paths not preceded by "! +" do not exist, or if any paths preceded by "!" do exist. + +If stat() cannot determine whether a file exists or not, delivery of the +message is deferred. This can happen when NFS-mounted filesystems are +unavailable. + +This option is checked after the domains, local_parts, and senders options, so +you cannot use it to check for the existence of a file in which to look up a +domain, local part, or sender. (See section 3.12 for a full list of the order +in which preconditions are evaluated.) However, as these options are all +expanded, you can use the exists expansion condition to make such tests. The +require_files option is intended for checking files that the router may be +going to use internally, or which are needed by a transport (e.g., .procmailrc +). + +During delivery, the stat() function is run as root, but there is a facility +for some checking of the accessibility of a file by another user. This is not a +proper permissions check, but just a "rough" check that operates as follows: + +If an item in a require_files list does not contain any forward slash +characters, it is taken to be the user (and optional group, separated by a +comma) to be checked for subsequent files in the list. If no group is specified +but the user is specified symbolically, the gid associated with the uid is +used. For example: + +require_files = mail:/some/file +require_files = $local_part:$home/.procmailrc + +If a user or group name in a require_files list does not exist, the +require_files condition fails. + +Exim performs the check by scanning along the components of the file path, and +checking the access for the given uid and gid. It checks for "x" access on +directories, and "r" access on the final file. Note that this means that file +access control lists, if the operating system has them, are ignored. + +Warning 1: When the router is being run to verify addresses for an incoming +SMTP message, Exim is not running as root, but under its own uid. This may +affect the result of a require_files check. In particular, stat() may yield the +error EACCES ("Permission denied"). This means that the Exim user is not +permitted to read one of the directories on the file's path. + +Warning 2: Even when Exim is running as root while delivering a message, stat() +can yield EACCES for a file in an NFS directory that is mounted without root +access. In this case, if a check for access by a particular user is requested, +Exim creates a subprocess that runs as that user, and tries the check again in +that process. + +The default action for handling an unresolved EACCES is to consider it to be +caused by a configuration error, and routing is deferred because the existence +or non-existence of the file cannot be determined. However, in some +circumstances it may be desirable to treat this condition as if the file did +not exist. If the filename (or the exclamation mark that precedes the filename +for non-existence) is preceded by a plus sign, the EACCES error is treated as +if the file did not exist. For example: + +require_files = +/some/file + +If the router is not an essential part of verification (for example, it handles +users' .forward files), another solution is to set the verify option false so +that the router is skipped when verifying. + ++------------------------------------------------------------------+ +|retry_use_local_part|Use: routers|Type: boolean|Default: see below| ++------------------------------------------------------------------+ + +When a delivery suffers a temporary routing failure, a retry record is created +in Exim's hints database. For addresses whose routing depends only on the +domain, the key for the retry record should not involve the local part, but for +other addresses, both the domain and the local part should be included. +Usually, remote routing is of the former kind, and local routing is of the +latter kind. + +This option controls whether the local part is used to form the key for retry +hints for addresses that suffer temporary errors while being handled by this +router. The default value is true for any router that has check_local_user set, +and false otherwise. Note that this option does not apply to hints keys for +transport delays; they are controlled by a generic transport option of the same +name. + +The setting of retry_use_local_part applies only to the router on which it +appears. If the router generates child addresses, they are routed +independently; this setting does not become attached to them. + ++---------------------------------------------------------------+ +|router_home_directory|Use: routers|Type: string*|Default: unset| ++---------------------------------------------------------------+ + +This option sets a home directory for use while the router is running. (Compare +transport_home_directory, which sets a home directory for later transporting.) +In particular, if used on a redirect router, this option sets a value for $home +while a filter is running. The value is expanded; forced expansion failure +causes the option to be ignored - other failures cause the router to defer. + +Expansion of router_home_directory happens immediately after the +check_local_user test (if configured), before any further expansions take +place. (See section 3.12 for a list of the order in which preconditions are +evaluated.) While the router is running, router_home_directory overrides the +value of $home that came from check_local_user. + +When a router accepts an address and assigns it to a local transport (including +the cases when a redirect router generates a pipe, file, or autoreply +delivery), the home directory setting for the transport is taken from the first +of these values that is set: + + * The home_directory option on the transport; + + * The transport_home_directory option on the router; + + * The password data if check_local_user is set on the router; + + * The router_home_directory option on the router. + +In other words, router_home_directory overrides the password data for the +router, but not for the transport. + ++----------------------------------------------+ +|self|Use: routers|Type: string|Default: freeze| ++----------------------------------------------+ + +This option applies to those routers that use a recipient address to find a +list of remote hosts. Currently, these are the dnslookup, ipliteral, and +manualroute routers. Certain configurations of the queryprogram router can also +specify a list of remote hosts. Usually such routers are configured to send the +message to a remote host via an smtp transport. The self option specifies what +happens when the first host on the list turns out to be the local host. The way +in which Exim checks for the local host is described in section 13.8. + +Normally this situation indicates either an error in Exim's configuration (for +example, the router should be configured not to process this domain), or an +error in the DNS (for example, the MX should not point to this host). For this +reason, the default action is to log the incident, defer the address, and +freeze the message. The following alternatives are provided for use in special +cases: + +defer + + Delivery of the message is tried again later, but the message is not + frozen. + +reroute: <domain> + + The domain is changed to the given domain, and the address is passed back + to be reprocessed by the routers. No rewriting of headers takes place. This + behaviour is essentially a redirection. + +reroute: rewrite: <domain> + + The domain is changed to the given domain, and the address is passed back + to be reprocessed by the routers. Any headers that contain the original + domain are rewritten. + +pass + + The router passes the address to the next router, or to the router named in + the pass_router option if it is set. This overrides no_more. During + subsequent routing and delivery, the variable $self_hostname contains the + name of the local host that the router encountered. This can be used to + distinguish between different cases for hosts with multiple names. The + combination + + self = pass + no_more + + ensures that only those addresses that routed to the local host are passed + on. Without no_more, addresses that were declined for other reasons would + also be passed to the next router. + +fail + + Delivery fails and an error report is generated. + +send + + The anomaly is ignored and the address is queued for the transport. This + setting should be used with extreme caution. For an smtp transport, it + makes sense only in cases where the program that is listening on the SMTP + port is not this version of Exim. That is, it must be some other MTA, or + Exim with a different configuration file that handles the domain in another + way. + ++---------------------------------------------------------+ +|senders|Use: routers**|Type: address list*|Default: unset| ++---------------------------------------------------------+ + +If this option is set, the router is skipped unless the message's sender +address matches something on the list. See section 3.12 for a list of the order +in which preconditions are evaluated. + +There are issues concerning verification when the running of routers is +dependent on the sender. When Exim is verifying the address in an errors_to +setting, it sets the sender to the null string. When using the -bt option to +check a configuration file, it is necessary also to use the -f option to set an +appropriate sender. For incoming mail, the sender is unset when verifying the +sender, but is available when verifying any recipients. If the SMTP VRFY +command is enabled, it must be used after MAIL if the sender address matters. + ++--------------------------------------------------------------+ +|translate_ip_address|Use: routers|Type: string*|Default: unset| ++--------------------------------------------------------------+ + +There exist some rare networking situations (for example, packet radio) where +it is helpful to be able to translate IP addresses generated by normal routing +mechanisms into other IP addresses, thus performing a kind of manual IP +routing. This should be done only if the normal IP routing of the TCP/IP stack +is inadequate or broken. Because this is an extremely uncommon requirement, the +code to support this option is not included in the Exim binary unless +SUPPORT_TRANSLATE_IP_ADDRESS=yes is set in Local/Makefile. + +The translate_ip_address string is expanded for every IP address generated by +the router, with the generated address set in $host_address. If the expansion +is forced to fail, no action is taken. For any other expansion error, delivery +of the message is deferred. If the result of the expansion is an IP address, +that replaces the original address; otherwise the result is assumed to be a +host name - this is looked up using gethostbyname() (or getipnodebyname() when +available) to produce one or more replacement IP addresses. For example, to +subvert all IP addresses in some specific networks, this could be added to a +router: + +translate_ip_address = \ + ${lookup{${mask:$host_address/26}}lsearch{/some/file}\ + {$value}fail}} + +The file would contain lines like + +10.2.3.128/26 some.host +10.8.4.34/26 10.44.8.15 + +You should not make use of this facility unless you really understand what you +are doing. + ++---------------------------------------------------+ +|transport|Use: routers|Type: string*|Default: unset| ++---------------------------------------------------+ + +This option specifies the transport to be used when a router accepts an address +and sets it up for delivery. A transport is never needed if a router is used +only for verification. The value of the option is expanded at routing time, +after the expansion of errors_to, headers_add, and headers_remove, and result +must be the name of one of the configured transports. If it is not, delivery is +deferred. + +The transport option is not used by the redirect router, but it does have some +private options that set up transports for pipe and file deliveries (see +chapter 22). + ++---------------------------------------------------------------------+ +|transport_current_directory|Use: routers|Type: string*|Default: unset| ++---------------------------------------------------------------------+ + +This option associates a current directory with any address that is routed to a +local transport. This can happen either because a transport is explicitly +configured for the router, or because it generates a delivery to a file or a +pipe. During the delivery process (that is, at transport time), this option +string is expanded and is set as the current directory, unless overridden by a +setting on the transport. If the expansion fails for any reason, including +forced failure, an error is logged, and delivery is deferred. See chapter 23 +for details of the local delivery environment. + ++----------------------------------------------------------------------+ +|transport_home_directory|Use: routers|Type: string*|Default: see below| ++----------------------------------------------------------------------+ + +This option associates a home directory with any address that is routed to a +local transport. This can happen either because a transport is explicitly +configured for the router, or because it generates a delivery to a file or a +pipe. During the delivery process (that is, at transport time), the option +string is expanded and is set as the home directory, unless overridden by a +setting of home_directory on the transport. If the expansion fails for any +reason, including forced failure, an error is logged, and delivery is deferred. + +If the transport does not specify a home directory, and +transport_home_directory is not set for the router, the home directory for the +transport is taken from the password data if check_local_user is set for the +router. Otherwise it is taken from router_home_directory if that option is set; +if not, no home directory is set for the transport. + +See chapter 23 for further details of the local delivery environment. + ++-------------------------------------------------+ +|unseen|Use: routers|Type: boolean*|Default: false| ++-------------------------------------------------+ + +The result of string expansion for this option must be a valid boolean value, +that is, one of the strings "yes", "no", "true", or "false". Any other result +causes an error, and delivery is deferred. If the expansion is forced to fail, +the default value for the option (false) is used. Other failures cause delivery +to be deferred. + +When this option is set true, routing does not cease if the router accepts the +address. Instead, a copy of the incoming address is passed to the next router, +overriding a false setting of more. There is little point in setting more false +if unseen is always true, but it may be useful in cases when the value of +unseen contains expansion items (and therefore, presumably, is sometimes true +and sometimes false). + +Setting the unseen option has a similar effect to the unseen command qualifier +in filter files. It can be used to cause copies of messages to be delivered to +some other destination, while also carrying out a normal delivery. In effect, +the current address is made into a "parent" that has two children - one that is +delivered as specified by this router, and a clone that goes on to be routed +further. For this reason, unseen may not be combined with the one_time option +in a redirect router. + +Warning: Header lines added to the address (or specified for removal) by this +router or by previous routers affect the "unseen" copy of the message only. The +clone that continues to be processed by further routers starts with no added +headers and none specified for removal. For a redirect router, if a generated +address is the same as the incoming address, this can lead to duplicate +addresses with different header modifications. Exim does not do duplicate +deliveries (except, in certain circumstances, to pipes -- see section 22.7), +but it is undefined which of the duplicates is discarded, so this ambiguous +situation should be avoided. The repeat_use option of the redirect router may +be of help. + +Unlike the handling of header modifications, any data that was set by the +address_data option in the current or previous routers is passed on to +subsequent routers. + ++--------------------------------------------------+ +|user|Use: routers|Type: string*|Default: see below| ++--------------------------------------------------+ + +When a router queues an address for a transport, and the transport does not +specify a user, the user given here is used when running the delivery process. +The user may be specified numerically or by name. If expansion fails, the error +is logged and delivery is deferred. This user is also used by the redirect +router when running a filter file. The default is unset, except when +check_local_user is set. In this case, the default is taken from the password +information. If the user is specified as a name, and group is not set, the +group associated with the user is used. See also initgroups and group and the +discussion in chapter 23. + ++-------------------------------------------------+ +|verify|Use: routers**|Type: boolean|Default: true| ++-------------------------------------------------+ + +Setting this option has the effect of setting verify_sender and +verify_recipient to the same value. + ++-------------------------------------------------------+ +|verify_only|Use: routers**|Type: boolean|Default: false| ++-------------------------------------------------------+ + +If this option is set, the router is used only when verifying an address, +delivering in cutthrough mode or testing with the -bv option, not when actually +doing a delivery, testing with the -bt option, or running the SMTP EXPN +command. It can be further restricted to verifying only senders or recipients +by means of verify_sender and verify_recipient. + +Warning: When the router is being run to verify addresses for an incoming SMTP +message, Exim is not running as root, but under its own uid. If the router +accesses any files, you need to make sure that they are accessible to the Exim +user or group. + ++-----------------------------------------------------------+ +|verify_recipient|Use: routers**|Type: boolean|Default: true| ++-----------------------------------------------------------+ + +If this option is false, the router is skipped when verifying recipient +addresses, delivering in cutthrough mode or testing recipient verification +using -bv. See section 3.12 for a list of the order in which preconditions are +evaluated. See also the $verify_mode variable. + ++--------------------------------------------------------+ +|verify_sender|Use: routers**|Type: boolean|Default: true| ++--------------------------------------------------------+ + +If this option is false, the router is skipped when verifying sender addresses +or testing sender verification using -bvs. See section 3.12 for a list of the +order in which preconditions are evaluated. See also the $verify_mode variable. + + + +=============================================================================== +16. THE ACCEPT ROUTER + +The accept router has no private options of its own. Unless it is being used +purely for verification (see verify_only) a transport is required to be defined +by the generic transport option. If the preconditions that are specified by +generic options are met, the router accepts the address and queues it for the +given transport. The most common use of this router is for setting up +deliveries to local mailboxes. For example: + +localusers: + driver = accept + domains = mydomain.example + check_local_user + transport = local_delivery + +The domains condition in this example checks the domain of the address, and +check_local_user checks that the local part is the login of a local user. When +both preconditions are met, the accept router runs, and queues the address for +the local_delivery transport. + + + +=============================================================================== +17. THE DNSLOOKUP ROUTER + +The dnslookup router looks up the hosts that handle mail for the recipient's +domain in the DNS. A transport must always be set for this router, unless +verify_only is set. + +If SRV support is configured (see check_srv below), Exim first searches for SRV +records. If none are found, or if SRV support is not configured, MX records are +looked up. If no MX records exist, address records are sought. However, +mx_domains can be set to disable the direct use of address records. + +MX records of equal priority are sorted by Exim into a random order. Exim then +looks for address records for the host names obtained from MX or SRV records. +When a host has more than one IP address, they are sorted into a random order, +except that IPv6 addresses are sorted before IPv4 addresses. If all the IP +addresses found are discarded by a setting of the ignore_target_hosts generic +option, the router declines. + +Unless they have the highest priority (lowest MX value), MX records that point +to the local host, or to any host name that matches hosts_treat_as_local, are +discarded, together with any other MX records of equal or lower priority. + +If the host pointed to by the highest priority MX record, or looked up as an +address record, is the local host, or matches hosts_treat_as_local, what +happens is controlled by the generic self option. + + +17.1 Problems with DNS lookups +------------------------------ + +There have been problems with DNS servers when SRV records are looked up. Some +misbehaving servers return a DNS error or timeout when a non-existent SRV +record is sought. Similar problems have in the past been reported for MX +records. The global dns_again_means_nonexist option can help with this problem, +but it is heavy-handed because it is a global option. + +For this reason, there are two options, srv_fail_domains and mx_fail_domains, +that control what happens when a DNS lookup in a dnslookup router results in a +DNS failure or a "try again" response. If an attempt to look up an SRV or MX +record causes one of these results, and the domain matches the relevant list, +Exim behaves as if the DNS had responded "no such record". In the case of an +SRV lookup, this means that the router proceeds to look for MX records; in the +case of an MX lookup, it proceeds to look for A or AAAA records, unless the +domain matches mx_domains, in which case routing fails. + + +17.2 Declining addresses by dnslookup +------------------------------------- + +There are a few cases where a dnslookup router will decline to accept an +address; if such a router is expected to handle "all remaining non-local +domains", then it is important to set no_more. + +The router will defer rather than decline if the domain is found in the +fail_defer_domains router option. + +Reasons for a dnslookup router to decline currently include: + + * The domain does not exist in DNS + + * The domain exists but the MX record's host part is just "."; this is a + common convention (borrowed from SRV) used to indicate that there is no + such service for this domain and to not fall back to trying A/AAAA records. + + * Ditto, but for SRV records, when check_srv is set on this router. + + * MX record points to a non-existent host. + + * MX record points to an IP address and the main section option + allow_mx_to_ip is not set. + + * MX records exist and point to valid hosts, but all hosts resolve only to + addresses blocked by the ignore_target_hosts generic option on this router. + + * The domain is not syntactically valid (see also allow_utf8_domains and + dns_check_names_pattern for handling one variant of this) + + * check_secondary_mx is set on this router but the local host can not be + found in the MX records (see below) + + +17.3 Private options for dnslookup +---------------------------------- + +The private options for the dnslookup router are as follows: + ++--------------------------------------------------------------+ +|check_secondary_mx|Use: dnslookup|Type: boolean|Default: false| ++--------------------------------------------------------------+ + +If this option is set, the router declines unless the local host is found in +(and removed from) the list of hosts obtained by MX lookup. This can be used to +process domains for which the local host is a secondary mail exchanger +differently to other domains. The way in which Exim decides whether a host is +the local host is described in section 13.8. + ++-----------------------------------------------------+ +|check_srv|Use: dnslookup|Type: string*|Default: unset| ++-----------------------------------------------------+ + +The dnslookup router supports the use of SRV records (see RFC 2782) in addition +to MX and address records. The support is disabled by default. To enable SRV +support, set the check_srv option to the name of the service required. For +example, + +check_srv = smtp + +looks for SRV records that refer to the normal smtp service. The option is +expanded, so the service name can vary from message to message or address to +address. This might be helpful if SRV records are being used for a submission +service. If the expansion is forced to fail, the check_srv option is ignored, +and the router proceeds to look for MX records in the normal way. + +When the expansion succeeds, the router searches first for SRV records for the +given service (it assumes TCP protocol). A single SRV record with a host name +that consists of just a single dot indicates "no such service for this domain"; +if this is encountered, the router declines. If other kinds of SRV record are +found, they are used to construct a host list for delivery according to the +rules of RFC 2782. MX records are not sought in this case. + +When no SRV records are found, MX records (and address records) are sought in +the traditional way. In other words, SRV records take precedence over MX +records, just as MX records take precedence over address records. Note that +this behaviour is not sanctioned by RFC 2782, though a previous draft RFC +defined it. It is apparently believed that MX records are sufficient for email +and that SRV records should not be used for this purpose. However, SRV records +have an additional "weight" feature which some people might find useful when +trying to split an SMTP load between hosts of different power. + +See section 17.1 above for a discussion of Exim's behaviour when there is a DNS +lookup error. + ++-------------------------------------------------------------------+ +|fail_defer_domains|Use: dnslookup|Type: domain list*|Default: unset| ++-------------------------------------------------------------------+ + +DNS lookups for domains matching fail_defer_domains which find no matching +record will cause the router to defer rather than the default behaviour of +decline. This maybe be useful for queueing messages for a newly created domain +while the DNS configuration is not ready. However, it will result in any +message with mistyped domains also being queued. + ++-------------------------------------------+ +|ipv4_only|Use: string*|Type: unset|Default:| ++-------------------------------------------+ + +The string is expanded, and if the result is anything but a forced failure, or +an empty string, or one of the strings ?0? or ?no? or ?false? (checked without +regard to the case of the letters), only A records are used. + ++---------------------------------------------+ +|ipv4_prefer|Use: string*|Type: unset|Default:| ++---------------------------------------------+ + +The string is expanded, and if the result is anything but a forced failure, or +an empty string, or one of the strings ?0? or ?no? or ?false? (checked without +regard to the case of the letters), A records are sorted before AAAA records +(inverting the default). + ++-----------------------------------------------------------+ +|mx_domains|Use: dnslookup|Type: domain list*|Default: unset| ++-----------------------------------------------------------+ + +A domain that matches mx_domains is required to have either an MX or an SRV +record in order to be recognized. (The name of this option could be improved.) +For example, if all the mail hosts in fict.example are known to have MX +records, except for those in discworld.fict.example, you could use this +setting: + +mx_domains = ! *.discworld.fict.example : *.fict.example + +This specifies that messages addressed to a domain that matches the list but +has no MX record should be bounced immediately instead of being routed using +the address record. + ++----------------------------------------------------------------+ +|mx_fail_domains|Use: dnslookup|Type: domain list*|Default: unset| ++----------------------------------------------------------------+ + +If the DNS lookup for MX records for one of the domains in this list causes a +DNS lookup error, Exim behaves as if no MX records were found. See section 17.1 +for more discussion. + ++---------------------------------------------------------+ +|qualify_single|Use: dnslookup|Type: boolean|Default: true| ++---------------------------------------------------------+ + +When this option is true, the resolver option RES_DEFNAMES is set for DNS +lookups. Typically, but not standardly, this causes the resolver to qualify +single-component names with the default domain. For example, on a machine +called dictionary.ref.example, the domain thesaurus would be changed to +thesaurus.ref.example inside the resolver. For details of what your resolver +actually does, consult your man pages for resolver and resolv.conf. + ++----------------------------------------------------------+ +|rewrite_headers|Use: dnslookup|Type: boolean|Default: true| ++----------------------------------------------------------+ + +If the domain name in the address that is being processed is not fully +qualified, it may be expanded to its full form by a DNS lookup. For example, if +an address is specified as dormouse@teaparty, the domain might be expanded to +teaparty.wonderland.fict.example. Domain expansion can also occur as a result +of setting the widen_domains option. If rewrite_headers is true, all +occurrences of the abbreviated domain name in any Bcc:, Cc:, From:, Reply-to:, +Sender:, and To: header lines of the message are rewritten with the full domain +name. + +This option should be turned off only when it is known that no message is ever +going to be sent outside an environment where the abbreviation makes sense. + +When an MX record is looked up in the DNS and matches a wildcard record, name +servers normally return a record containing the name that has been looked up, +making it impossible to detect whether a wildcard was present or not. However, +some name servers have recently been seen to return the wildcard entry. If the +name returned by a DNS lookup begins with an asterisk, it is not used for +header rewriting. + ++--------------------------------------------------------------------+ +|same_domain_copy_routing|Use: dnslookup|Type: boolean|Default: false| ++--------------------------------------------------------------------+ + +Addresses with the same domain are normally routed by the dnslookup router to +the same list of hosts. However, this cannot be presumed, because the router +options and preconditions may refer to the local part of the address. By +default, therefore, Exim routes each address in a message independently. DNS +servers run caches, so repeated DNS lookups are not normally expensive, and in +any case, personal messages rarely have more than a few recipients. + +If you are running mailing lists with large numbers of subscribers at the same +domain, and you are using a dnslookup router which is independent of the local +part, you can set same_domain_copy_routing to bypass repeated DNS lookups for +identical domains in one message. In this case, when dnslookup routes an +address to a remote transport, any other unrouted addresses in the message that +have the same domain are automatically given the same routing without +processing them independently, provided the following conditions are met: + + * No router that processed the address specified headers_add or + headers_remove. + + * The router did not change the address in any way, for example, by + "widening" the domain. + ++----------------------------------------------------------+ +|search_parents|Use: dnslookup|Type: boolean|Default: false| ++----------------------------------------------------------+ + +When this option is true, the resolver option RES_DNSRCH is set for DNS +lookups. This is different from the qualify_single option in that it applies to +domains containing dots. Typically, but not standardly, it causes the resolver +to search for the name in the current domain and in parent domains. For +example, on a machine in the fict.example domain, if looking up +teaparty.wonderland failed, the resolver would try +teaparty.wonderland.fict.example. For details of what your resolver actually +does, consult your man pages for resolver and resolv.conf. + +Setting this option true can cause problems in domains that have a wildcard MX +record, because any domain that does not have its own MX record matches the +local wildcard. + ++-----------------------------------------------------------------+ +|srv_fail_domains|Use: dnslookup|Type: domain list*|Default: unset| ++-----------------------------------------------------------------+ + +If the DNS lookup for SRV records for one of the domains in this list causes a +DNS lookup error, Exim behaves as if no SRV records were found. See section +17.1 for more discussion. + ++-------------------------------------------------------------+ +|widen_domains|Use: dnslookup|Type: string list|Default: unset| ++-------------------------------------------------------------+ + +If a DNS lookup fails and this option is set, each of its strings in turn is +added onto the end of the domain, and the lookup is tried again. For example, +if + +widen_domains = fict.example:ref.example + +is set and a lookup of klingon.dictionary fails, +klingon.dictionary.fict.example is looked up, and if this fails, +klingon.dictionary.ref.example is tried. Note that the qualify_single and +search_parents options can cause some widening to be undertaken inside the DNS +resolver. widen_domains is not applied to sender addresses when verifying, +unless rewrite_headers is false (not the default). + + +17.4 Effect of qualify_single and search_parents +------------------------------------------------ + +When a domain from an envelope recipient is changed by the resolver as a result +of the qualify_single or search_parents options, Exim rewrites the +corresponding address in the message's header lines unless rewrite_headers is +set false. Exim then re-routes the address, using the full domain. + +These two options affect only the DNS lookup that takes place inside the router +for the domain of the address that is being routed. They do not affect lookups +such as that implied by + +domains = @mx_any + +that may happen while processing a router precondition before the router is +entered. No widening ever takes place for these lookups. + + + +=============================================================================== +18. THE IPLITERAL ROUTER + +This router has no private options. Unless it is being used purely for +verification (see verify_only) a transport is required to be defined by the +generic transport option. The router accepts the address if its domain part +takes the form of an RFC 2822 domain literal. For example, the ipliteral router +handles the address + +root@[192.168.1.1] + +by setting up delivery to the host with that IP address. IPv4 domain literals +consist of an IPv4 address enclosed in square brackets. IPv6 domain literals +are similar, but the address is preceded by "ipv6:". For example: + +postmaster@[ipv6:fe80::a00:20ff:fe86:a061.5678] + +Exim allows "ipv4:" before IPv4 addresses, for consistency, and on the grounds +that sooner or later somebody will try it. + +If the IP address matches something in ignore_target_hosts, the router +declines. If an IP literal turns out to refer to the local host, the generic +self option determines what happens. + +The RFCs require support for domain literals; however, their use is +controversial in today's Internet. If you want to use this router, you must +also set the main configuration option allow_domain_literals. Otherwise, Exim +will not recognize the domain literal syntax in addresses. + + + +=============================================================================== +19. THE IPLOOKUP ROUTER + +The iplookup router was written to fulfil a specific requirement in Cambridge +University (which in fact no longer exists). For this reason, it is not +included in the binary of Exim by default. If you want to include it, you must +set + +ROUTER_IPLOOKUP=yes + +in your Local/Makefile configuration file. + +The iplookup router routes an address by sending it over a TCP or UDP +connection to one or more specific hosts. The host can then return the same or +a different address - in effect rewriting the recipient address in the +message's envelope. The new address is then passed on to subsequent routers. If +this process fails, the address can be passed on to other routers, or delivery +can be deferred. Since iplookup is just a rewriting router, a transport must +not be specified for it. + ++-----------------------------------------------+ +|hosts|Use: iplookup|Type: string|Default: unset| ++-----------------------------------------------+ + +This option must be supplied. Its value is a colon-separated list of host +names. The hosts are looked up using gethostbyname() (or getipnodebyname() when +available) and are tried in order until one responds to the query. If none +respond, what happens is controlled by optional. + ++---------------------------------------------------+ +|optional|Use: iplookup|Type: boolean|Default: false| ++---------------------------------------------------+ + +If optional is true, if no response is obtained from any host, the address is +passed to the next router, overriding no_more. If optional is false, delivery +to the address is deferred. + ++-------------------------------------------+ +|port|Use: iplookup|Type: integer|Default: 0| ++-------------------------------------------+ + +This option must be supplied. It specifies the port number for the TCP or UDP +call. + ++------------------------------------------------+ +|protocol|Use: iplookup|Type: string|Default: udp| ++------------------------------------------------+ + +This option can be set to "udp" or "tcp" to specify which of the two protocols +is to be used. + ++----------------------------------------------------+ +|query|Use: iplookup|Type: string*|Default: see below| ++----------------------------------------------------+ + +This defines the content of the query that is sent to the remote hosts. The +default value is: + +$local_part@$domain $local_part@$domain + +The repetition serves as a way of checking that a response is to the correct +query in the default case (see response_pattern below). + ++--------------------------------------------------+ +|reroute|Use: iplookup|Type: string*|Default: unset| ++--------------------------------------------------+ + +If this option is not set, the rerouted address is precisely the byte string +returned by the remote host, up to the first white space, if any. If set, the +string is expanded to form the rerouted address. It can include parts matched +in the response by response_pattern by means of numeric variables such as $1, +$2, etc. The variable $0 refers to the entire input string, whether or not a +pattern is in use. In all cases, the rerouted address must end up in the form +local_part@domain. + ++----------------------------------------------------------+ +|response_pattern|Use: iplookup|Type: string|Default: unset| ++----------------------------------------------------------+ + +This option can be set to a regular expression that is applied to the string +returned from the remote host. If the pattern does not match the response, the +router declines. If response_pattern is not set, no checking of the response is +done, unless the query was defaulted, in which case there is a check that the +text returned after the first white space is the original address. This checks +that the answer that has been received is in response to the correct question. +For example, if the response is just a new domain, the following could be used: + +response_pattern = ^([^@]+)$ +reroute = $local_part@$1 + ++--------------------------------------------+ +|timeout|Use: iplookup|Type: time|Default: 5s| ++--------------------------------------------+ + +This specifies the amount of time to wait for a response from the remote +machine. The same timeout is used for the connect() function for a TCP call. It +does not apply to UDP. + + + +=============================================================================== +20. THE MANUALROUTE ROUTER + +The manualroute router is so-called because it provides a way of manually +routing an address according to its domain. It is mainly used when you want to +route addresses to remote hosts according to your own rules, bypassing the +normal DNS routing that looks up MX records. However, manualroute can also +route to local transports, a facility that may be useful if you want to save +messages for dial-in hosts in local files. + +The manualroute router compares a list of domain patterns with the domain it is +trying to route. If there is no match, the router declines. Each pattern has +associated with it a list of hosts and some other optional data, which may +include a transport. The combination of a pattern and its data is called a +"routing rule". For patterns that do not have an associated transport, the +generic transport option must specify a transport, unless the router is being +used purely for verification (see verify_only). + +In the case of verification, matching the domain pattern is sufficient for the +router to accept the address. When actually routing an address for delivery, an +address that matches a domain pattern is queued for the associated transport. +If the transport is not a local one, a host list must be associated with the +pattern; IP addresses are looked up for the hosts, and these are passed to the +transport along with the mail address. For local transports, a host list is +optional. If it is present, it is passed in $host as a single text string. + +The list of routing rules can be provided as an inline string in route_list, or +the data can be obtained by looking up the domain in a file or database by +setting route_data. Only one of these settings may appear in any one instance +of manualroute. The format of routing rules is described below, following the +list of private options. + + +20.1 Private options for manualroute +------------------------------------ + +The private options for the manualroute router are as follows: + ++-------------------------------------------------------------+ +|host_all_ignored|Use: manualroute|Type: string|Default: defer| ++-------------------------------------------------------------+ + +See host_find_failed. + ++--------------------------------------------------------------+ +|host_find_failed|Use: manualroute|Type: string|Default: freeze| ++--------------------------------------------------------------+ + +This option controls what happens when manualroute tries to find an IP address +for a host, and the host does not exist. The option can be set to one of the +following values: + +decline +defer +fail +freeze +ignore +pass + +The default ("freeze") assumes that this state is a serious configuration +error. The difference between "pass" and "decline" is that the former forces +the address to be passed to the next router (or the router defined by +pass_router), overriding no_more, whereas the latter passes the address to the +next router only if more is true. + +The value "ignore" causes Exim to completely ignore a host whose IP address +cannot be found. If all the hosts in the list are ignored, the behaviour is +controlled by the host_all_ignored option. This takes the same values as +host_find_failed, except that it cannot be set to "ignore". + +The host_find_failed option applies only to a definite "does not exist" state; +if a host lookup gets a temporary error, delivery is deferred unless the +generic pass_on_timeout option is set. + ++-------------------------------------------------------------+ +|hosts_randomize|Use: manualroute|Type: boolean|Default: false| ++-------------------------------------------------------------+ + +If this option is set, the order of the items in a host list in a routing rule +is randomized each time the list is used, unless an option in the routing rule +overrides (see below). Randomizing the order of a host list can be used to do +crude load sharing. However, if more than one mail address is routed by the +same router to the same host list, the host lists are considered to be the same +(even though they may be randomized into different orders) for the purpose of +deciding whether to batch the deliveries into a single SMTP transaction. + +When hosts_randomize is true, a host list may be split into groups whose order +is separately randomized. This makes it possible to set up MX-like behaviour. +The boundaries between groups are indicated by an item that is just "+" in the +host list. For example: + +route_list = * host1:host2:host3:+:host4:host5 + +The order of the first three hosts and the order of the last two hosts is +randomized for each use, but the first three always end up before the last two. +If hosts_randomize is not set, a "+" item in the list is ignored. If a +randomized host list is passed to an smtp transport that also has +hosts_randomize set, the list is not re-randomized. + ++--------------------------------------------------------+ +|route_data|Use: manualroute|Type: string*|Default: unset| ++--------------------------------------------------------+ + +If this option is set, it must expand to yield the data part of a routing rule. +Typically, the expansion string includes a lookup based on the domain. For +example: + +route_data = ${lookup{$domain}dbm{/etc/routes}} + +If the expansion is forced to fail, or the result is an empty string, the +router declines. Other kinds of expansion failure cause delivery to be +deferred. + ++------------------------------------------------------------+ +|route_list|Use: manualroute|Type: string list|Default: unset| ++------------------------------------------------------------+ + +This string is a list of routing rules, in the form defined below. Note that, +unlike most string lists, the items are separated by semicolons. This is so +that they may contain colon-separated host lists. + ++----------------------------------------------------------------------+ +|same_domain_copy_routing|Use: manualroute|Type: boolean|Default: false| ++----------------------------------------------------------------------+ + +Addresses with the same domain are normally routed by the manualroute router to +the same list of hosts. However, this cannot be presumed, because the router +options and preconditions may refer to the local part of the address. By +default, therefore, Exim routes each address in a message independently. DNS +servers run caches, so repeated DNS lookups are not normally expensive, and in +any case, personal messages rarely have more than a few recipients. + +If you are running mailing lists with large numbers of subscribers at the same +domain, and you are using a manualroute router which is independent of the +local part, you can set same_domain_copy_routing to bypass repeated DNS lookups +for identical domains in one message. In this case, when manualroute routes an +address to a remote transport, any other unrouted addresses in the message that +have the same domain are automatically given the same routing without +processing them independently. However, this is only done if headers_add and +headers_remove are unset. + + +20.2 Routing rules in route_list +-------------------------------- + +The value of route_list is a string consisting of a sequence of routing rules, +separated by semicolons. If a semicolon is needed in a rule, it can be entered +as two semicolons. Alternatively, the list separator can be changed as +described (for colon-separated lists) in section 6.20. Empty rules are ignored. +The format of each rule is + +<domain pattern> <list of hosts> <options> + +The following example contains two rules, each with a simple domain pattern and +no options: + +route_list = \ + dict.ref.example mail-1.ref.example:mail-2.ref.example ; \ + thes.ref.example mail-3.ref.example:mail-4.ref.example + +The three parts of a rule are separated by white space. The pattern and the +list of hosts can be enclosed in quotes if necessary, and if they are, the +usual quoting rules apply. Each rule in a route_list must start with a single +domain pattern, which is the only mandatory item in the rule. The pattern is in +the same format as one item in a domain list (see section 10.8), except that it +may not be the name of an interpolated file. That is, it may be wildcarded, or +a regular expression, or a file or database lookup (with semicolons doubled, +because of the use of semicolon as a separator in a route_list). + +The rules in route_list are searched in order until one of the patterns matches +the domain that is being routed. The list of hosts and then options are then +used as described below. If there is no match, the router declines. When +route_list is set, route_data must not be set. + + +20.3 Routing rules in route_data +-------------------------------- + +The use of route_list is convenient when there are only a small number of +routing rules. For larger numbers, it is easier to use a file or database to +hold the routing information, and use the route_data option instead. The value +of route_data is a list of hosts, followed by (optional) options. Most +commonly, route_data is set as a string that contains an expansion lookup. For +example, suppose we place two routing rules in a file like this: + +dict.ref.example: mail-1.ref.example:mail-2.ref.example +thes.ref.example: mail-3.ref.example:mail-4.ref.example + +This data can be accessed by setting + +route_data = ${lookup{$domain}lsearch{/the/file/name}} + +Failure of the lookup results in an empty string, causing the router to +decline. However, you do not have to use a lookup in route_data. The only +requirement is that the result of expanding the string is a list of hosts, +possibly followed by options, separated by white space. The list of hosts must +be enclosed in quotes if it contains white space. + + +20.4 Format of the list of hosts +-------------------------------- + +A list of hosts, whether obtained via route_data or route_list, is always +separately expanded before use. If the expansion fails, the router declines. +The result of the expansion must be a colon-separated list of names and/or IP +addresses, optionally also including ports. If the list is written with spaces, +it must be protected with quotes. The format of each item in the list is +described in the next section. The list separator can be changed as described +in section 6.21. + +If the list of hosts was obtained from a route_list item, the following +variables are set during its expansion: + + * If the domain was matched against a regular expression, the numeric + variables $1, $2, etc. may be set. For example: + + route_list = ^domain(\d+) host-$1.text.example + + * $0 is always set to the entire domain. + + * $1 is also set when partial matching is done in a file lookup. + + * If the pattern that matched the domain was a lookup item, the data that was + looked up is available in the expansion variable $value. For example: + + route_list = lsearch;;/some/file.routes $value + +Note the doubling of the semicolon in the pattern that is necessary because +semicolon is the default route list separator. + + +20.5 Format of one host item +---------------------------- + +Each item in the list of hosts is either a host name or an IP address, +optionally with an attached port number. When no port is given, an IP address +is not enclosed in brackets. When a port is specified, it overrides the port +specification on the transport. The port is separated from the name or address +by a colon. This leads to some complications: + + * Because colon is the default separator for the list of hosts, either the + colon that specifies a port must be doubled, or the list separator must be + changed. The following two examples have the same effect: + + route_list = * "host1.tld::1225 : host2.tld::1226" + route_list = * "<+ host1.tld:1225 + host2.tld:1226" + + * When IPv6 addresses are involved, it gets worse, because they contain + colons of their own. To make this case easier, it is permitted to enclose + an IP address (either v4 or v6) in square brackets if a port number + follows. For example: + + route_list = * "</ [10.1.1.1]:1225 / [::1]:1226" + + +20.6 How the list of hosts is used +---------------------------------- + +When an address is routed to an smtp transport by manualroute, each of the +hosts is tried, in the order specified, when carrying out the SMTP delivery. +However, the order can be changed by setting the hosts_randomize option, either +on the router (see section 20.1 above), or on the transport. + +Hosts may be listed by name or by IP address. An unadorned name in the list of +hosts is interpreted as a host name. A name that is followed by "/MX" is +interpreted as an indirection to a sublist of hosts obtained by looking up MX +records in the DNS. For example: + +route_list = * x.y.z:p.q.r/MX:e.f.g + +If this feature is used with a port specifier, the port must come last. For +example: + +route_list = * dom1.tld/mx::1225 + +If the hosts_randomize option is set, the order of the items in the list is +randomized before any lookups are done. Exim then scans the list; for any name +that is not followed by "/MX" it looks up an IP address. If this turns out to +be an interface on the local host and the item is not the first in the list, +Exim discards it and any subsequent items. If it is the first item, what +happens is controlled by the self option of the router. + +A name on the list that is followed by "/MX" is replaced with the list of hosts +obtained by looking up MX records for the name. This is always a DNS lookup; +the bydns and byname options (see section 20.7 below) are not relevant here. +The order of these hosts is determined by the preference values in the MX +records, according to the usual rules. Because randomizing happens before the +MX lookup, it does not affect the order that is defined by MX preferences. + +If the local host is present in the sublist obtained from MX records, but is +not the most preferred host in that list, it and any equally or less preferred +hosts are removed before the sublist is inserted into the main list. + +If the local host is the most preferred host in the MX list, what happens +depends on where in the original list of hosts the "/MX" item appears. If it is +not the first item (that is, there are previous hosts in the main list), Exim +discards this name and any subsequent items in the main list. + +If the MX item is first in the list of hosts, and the local host is the most +preferred host, what happens is controlled by the self option of the router. + +DNS failures when lookup up the MX records are treated in the same way as DNS +failures when looking up IP addresses: pass_on_timeout and host_find_failed are +used when relevant. + +The generic ignore_target_hosts option applies to all hosts in the list, +whether obtained from an MX lookup or not. + + +20.7 How the options are used +----------------------------- + +The options are a sequence of words, space-separated. One of the words can be +the name of a transport; this overrides the transport option on the router for +this particular routing rule only. The other words (if present) control +randomization of the list of hosts on a per-rule basis, and how the IP +addresses of the hosts are to be found when routing to a remote transport. +These options are as follows: + + * randomize: randomize the order of the hosts in this list, overriding the + setting of hosts_randomize for this routing rule only. + + * no_randomize: do not randomize the order of the hosts in this list, + overriding the setting of hosts_randomize for this routing rule only. + + * byname: use getipnodebyname() (gethostbyname() on older systems) to find IP + addresses. This function may ultimately cause a DNS lookup, but it may also + look in /etc/hosts or other sources of information. + + * bydns: look up address records for the hosts directly in the DNS; fail if + no address records are found. If there is a temporary DNS error (such as a + timeout), delivery is deferred. + + * ipv4_only: in direct DNS lookups, look up only A records. + + * ipv4_prefer: in direct DNS lookups, sort A records before AAAA records. + +For example: + +route_list = domain1 host1:host2:host3 randomize bydns;\ + domain2 host4:host5 + +If neither byname nor bydns is given, Exim behaves as follows: First, a DNS +lookup is done. If this yields anything other than HOST_NOT_FOUND, that result +is used. Otherwise, Exim goes on to try a call to getipnodebyname() or +gethostbyname(), and the result of the lookup is the result of that call. + +Warning: It has been discovered that on some systems, if a DNS lookup called +via getipnodebyname() times out, HOST_NOT_FOUND is returned instead of +TRY_AGAIN. That is why the default action is to try a DNS lookup first. Only if +that gives a definite "no such host" is the local function called. + +Compatibility: From Exim 4.85 until fixed for 4.90, there was an inadvertent +constraint that a transport name as an option had to be the last option +specified. + +If no IP address for a host can be found, what happens is controlled by the +host_find_failed option. + +When an address is routed to a local transport, IP addresses are not looked up. +The host list is passed to the transport in the $host variable. + + +20.8 Manualroute examples +------------------------- + +In some of the examples that follow, the presence of the remote_smtp transport, +as defined in the default configuration file, is assumed: + + * The manualroute router can be used to forward all external mail to a smart + host. If you have set up, in the main part of the configuration, a named + domain list that contains your local domains, for example: + + domainlist local_domains = my.domain.example + + You can arrange for all other domains to be routed to a smart host by + making your first router something like this: + + smart_route: + driver = manualroute + domains = !+local_domains + transport = remote_smtp + route_list = * smarthost.ref.example + + This causes all non-local addresses to be sent to the single host + smarthost.ref.example. If a colon-separated list of smart hosts is given, + they are tried in order (but you can use hosts_randomize to vary the order + each time). Another way of configuring the same thing is this: + + smart_route: + driver = manualroute + transport = remote_smtp + route_list = !+local_domains smarthost.ref.example + + There is no difference in behaviour between these two routers as they + stand. However, they behave differently if no_more is added to them. In the + first example, the router is skipped if the domain does not match the + domains precondition; the following router is always tried. If the router + runs, it always matches the domain and so can never decline. Therefore, + no_more would have no effect. In the second case, the router is never + skipped; it always runs. However, if it doesn't match the domain, it + declines. In this case no_more would prevent subsequent routers from + running. + + * A mail hub is a host which receives mail for a number of domains via MX + records in the DNS and delivers it via its own private routing mechanism. + Often the final destinations are behind a firewall, with the mail hub being + the one machine that can connect to machines both inside and outside the + firewall. The manualroute router is usually used on a mail hub to route + incoming messages to the correct hosts. For a small number of domains, the + routing can be inline, using the route_list option, but for a larger number + a file or database lookup is easier to manage. + + If the domain names are in fact the names of the machines to which the mail + is to be sent by the mail hub, the configuration can be quite simple. For + example: + + hub_route: + driver = manualroute + transport = remote_smtp + route_list = *.rhodes.tvs.example $domain + + This configuration routes domains that match "*.rhodes.tvs.example" to + hosts whose names are the same as the mail domains. A similar approach can + be taken if the host name can be obtained from the domain name by a string + manipulation that the expansion facilities can handle. Otherwise, a lookup + based on the domain can be used to find the host: + + through_firewall: + driver = manualroute + transport = remote_smtp + route_data = ${lookup {$domain} cdb {/internal/host/routes}} + + The result of the lookup must be the name or IP address of the host (or + hosts) to which the address is to be routed. If the lookup fails, the route + data is empty, causing the router to decline. The address then passes to + the next router. + + * You can use manualroute to deliver messages to pipes or files in batched + SMTP format for onward transportation by some other means. This is one way + of storing mail for a dial-up host when it is not connected. The route list + entry can be as simple as a single domain name in a configuration like + this: + + save_in_file: + driver = manualroute + transport = batchsmtp_appendfile + route_list = saved.domain.example + + though often a pattern is used to pick up more than one domain. If there + are several domains or groups of domains with different transport + requirements, different transports can be listed in the routing + information: + + save_in_file: + driver = manualroute + route_list = \ + *.saved.domain1.example $domain batch_appendfile; \ + *.saved.domain2.example \ + ${lookup{$domain}dbm{/domain2/hosts}{$value}fail} \ + batch_pipe + + The first of these just passes the domain in the $host variable, which + doesn't achieve much (since it is also in $domain), but the second does a + file lookup to find a value to pass, causing the router to decline to + handle the address if the lookup fails. + + * Routing mail directly to UUCP software is a specific case of the use of + manualroute in a gateway to another mail environment. This is an example of + one way it can be done: + + # Transport + uucp: + driver = pipe + user = nobody + command = /usr/local/bin/uux -r - \ + ${substr_-5:$host}!rmail ${local_part} + return_fail_output = true + + # Router + uucphost: + transport = uucp + driver = manualroute + route_data = \ + ${lookup{$domain}lsearch{/usr/local/exim/uucphosts}} + + The file /usr/local/exim/uucphosts contains entries like + + darksite.ethereal.example: darksite.UUCP + + It can be set up more simply without adding and removing ".UUCP" but this + way makes clear the distinction between the domain name + darksite.ethereal.example and the UUCP host name darksite. + + + +=============================================================================== +21. THE QUERYPROGRAM ROUTER + +The queryprogram router routes an address by running an external command and +acting on its output. This is an expensive way to route, and is intended mainly +for use in lightly-loaded systems, or for performing experiments. However, if +it is possible to use the precondition options (domains, local_parts, etc) to +skip this router for most addresses, it could sensibly be used in special +cases, even on a busy host. There are the following private options: + ++------------------------------------------------------+ +|command|Use: queryprogram|Type: string*|Default: unset| ++------------------------------------------------------+ + +This option must be set. It specifies the command that is to be run. The +command is split up into a command name and arguments, and then each is +expanded separately (exactly as for a pipe transport, described in chapter 29). + ++-----------------------------------------------------------+ +|command_group|Use: queryprogram|Type: string|Default: unset| ++-----------------------------------------------------------+ + +This option specifies a gid to be set when running the command while routing an +address for deliver. It must be set if command_user specifies a numerical uid. +If it begins with a digit, it is interpreted as the numerical value of the gid. +Otherwise it is looked up using getgrnam(). + ++----------------------------------------------------------+ +|command_user|Use: queryprogram|Type: string|Default: unset| ++----------------------------------------------------------+ + +This option must be set. It specifies the uid which is set when running the +command while routing an address for delivery. If the value begins with a +digit, it is interpreted as the numerical value of the uid. Otherwise, it is +looked up using getpwnam() to obtain a value for the uid and, if command_group +is not set, a value for the gid also. + +Warning: Changing uid and gid is possible only when Exim is running as root, +which it does during a normal delivery in a conventional configuration. +However, when an address is being verified during message reception, Exim is +usually running as the Exim user, not as root. If the queryprogram router is +called from a non-root process, Exim cannot change uid or gid before running +the command. In this circumstance the command runs under the current uid and +gid. + ++-----------------------------------------------------------+ +|current_directory|Use: queryprogram|Type: string|Default: /| ++-----------------------------------------------------------+ + +This option specifies an absolute path which is made the current directory +before running the command. + ++------------------------------------------------+ +|timeout|Use: queryprogram|Type: time|Default: 1h| ++------------------------------------------------+ + +If the command does not complete within the timeout period, its process group +is killed and the message is frozen. A value of zero time specifies no timeout. + +The standard output of the command is connected to a pipe, which is read when +the command terminates. It should consist of a single line of output, +containing up to five fields, separated by white space. The maximum length of +the line is 1023 characters. Longer lines are silently truncated. The first +field is one of the following words (case-insensitive): + + * Accept: routing succeeded; the remaining fields specify what to do (see + below). + + * Decline: the router declines; pass the address to the next router, unless + no_more is set. + + * Fail: routing failed; do not pass the address to any more routers. Any + subsequent text on the line is an error message. If the router is run as + part of address verification during an incoming SMTP message, the message + is included in the SMTP response. + + * Defer: routing could not be completed at this time; try again later. Any + subsequent text on the line is an error message which is logged. It is not + included in any SMTP response. + + * Freeze: the same as defer, except that the message is frozen. + + * Pass: pass the address to the next router (or the router specified by + pass_router), overriding no_more. + + * Redirect: the message is redirected. The remainder of the line is a list of + new addresses, which are routed independently, starting with the first + router, or the router specified by redirect_router, if set. + +When the first word is accept, the remainder of the line consists of a number +of keyed data values, as follows (split into two lines here, to fit on the +page): + +ACCEPT TRANSPORT=<transport> HOSTS=<list of hosts> +LOOKUP=byname|bydns DATA=<text> + +The data items can be given in any order, and all are optional. If no transport +is included, the transport specified by the generic transport option is used. +The list of hosts and the lookup type are needed only if the transport is an +smtp transport that does not itself supply a list of hosts. + +The format of the list of hosts is the same as for the manualroute router. As +well as host names and IP addresses with optional port numbers, as described in +section 20.5, it may contain names followed by "/MX" to specify sublists of +hosts that are obtained by looking up MX records (see section 20.6). + +If the lookup type is not specified, Exim behaves as follows when trying to +find an IP address for each host: First, a DNS lookup is done. If this yields +anything other than HOST_NOT_FOUND, that result is used. Otherwise, Exim goes +on to try a call to getipnodebyname() or gethostbyname(), and the result of the +lookup is the result of that call. + +If the DATA field is set, its value is placed in the $address_data variable. +For example, this return line + +accept hosts=x1.y.example:x2.y.example data="rule1" + +routes the address to the default transport, passing a list of two hosts. When +the transport runs, the string "rule1" is in $address_data. + + + +=============================================================================== +22. THE REDIRECT ROUTER + +The redirect router handles several kinds of address redirection. Its most +common uses are for resolving local part aliases from a central alias file +(usually called /etc/aliases) and for handling users' personal .forward files, +but it has many other potential uses. The incoming address can be redirected in +several different ways: + + * It can be replaced by one or more new addresses which are themselves routed + independently. + + * It can be routed to be delivered to a given file or directory. + + * It can be routed to be delivered to a specified pipe command. + + * It can cause an automatic reply to be generated. + + * It can be forced to fail, optionally with a custom error message. + + * It can be temporarily deferred, optionally with a custom message. + + * It can be discarded. + +The generic transport option must not be set for redirect routers. However, +there are some private options which define transports for delivery to files +and pipes, and for generating autoreplies. See the file_transport, +pipe_transport and reply_transport descriptions below. + +If success DSNs have been requested redirection triggers one and the DSN +options are not passed any further. + + +22.1 Redirection data +--------------------- + +The router operates by interpreting a text string which it obtains either by +expanding the contents of the data option, or by reading the entire contents of +a file whose name is given in the file option. These two options are mutually +exclusive. The first is commonly used for handling system aliases, in a +configuration like this: + +system_aliases: + driver = redirect + data = ${lookup{$local_part}lsearch{/etc/aliases}} + +If the lookup fails, the expanded string in this example is empty. When the +expansion of data results in an empty string, the router declines. A forced +expansion failure also causes the router to decline; other expansion failures +cause delivery to be deferred. + +A configuration using file is commonly used for handling users' .forward files, +like this: + +userforward: + driver = redirect + check_local_user + file = $home/.forward + no_verify + +If the file does not exist, or causes no action to be taken (for example, it is +empty or consists only of comments), the router declines. Warning: This is not +the case when the file contains syntactically valid items that happen to yield +empty addresses, for example, items containing only RFC 2822 address comments. + + +22.2 Forward files and address verification +------------------------------------------- + +It is usual to set no_verify on redirect routers which handle users' .forward +files, as in the example above. There are two reasons for this: + + * When Exim is receiving an incoming SMTP message from a remote host, it is + running under the Exim uid, not as root. Exim is unable to change uid to + read the file as the user, and it may not be able to read it as the Exim + user. So in practice the router may not be able to operate. + + * However, even when the router can operate, the existence of a .forward file + is unimportant when verifying an address. What should be checked is whether + the local part is a valid user name or not. Cutting out the redirection + processing saves some resources. + + +22.3 Interpreting redirection data +---------------------------------- + +The contents of the data string, whether obtained from data or file, can be +interpreted in two different ways: + + * If the allow_filter option is set true, and the data begins with the text " + #Exim filter" or "#Sieve filter", it is interpreted as a list of filtering + instructions in the form of an Exim or Sieve filter file, respectively. + Details of the syntax and semantics of filter files are described in a + separate document entitled Exim's interfaces to mail filtering; this + document is intended for use by end users. + + * Otherwise, the data must be a comma-separated list of redirection items, as + described in the next section. + +When a message is redirected to a file (a "mail folder"), the filename given in +a non-filter redirection list must always be an absolute path. A filter may +generate a relative path - how this is handled depends on the transport's +configuration. See section 26.1 for a discussion of this issue for the +appendfile transport. + + +22.4 Items in a non-filter redirection list +------------------------------------------- + +When the redirection data is not an Exim or Sieve filter, for example, if it +comes from a conventional alias or forward file, it consists of a list of +addresses, filenames, pipe commands, or certain special items (see section 22.6 +below). The special items can be individually enabled or disabled by means of +options whose names begin with allow_ or forbid_, depending on their default +values. The items in the list are separated by commas or newlines. If a comma +is required in an item, the entire item must be enclosed in double quotes. + +Lines starting with a # character are comments, and are ignored, and # may also +appear following a comma, in which case everything between the # and the next +newline character is ignored. + +If an item is entirely enclosed in double quotes, these are removed. Otherwise +double quotes are retained because some forms of mail address require their use +(but never to enclose the entire address). In the following description, "item" +refers to what remains after any surrounding double quotes have been removed. + +Warning: If you use an Exim expansion to construct a redirection address, and +the expansion contains a reference to $local_part, you should make use of the +quote_local_part expansion operator, in case the local part contains special +characters. For example, to redirect all mail for the domain obsolete.example, +retaining the existing local part, you could use this setting: + +data = ${quote_local_part:$local_part}@newdomain.example + + +22.5 Redirecting to a local mailbox +----------------------------------- + +A redirection item may safely be the same as the address currently under +consideration. This does not cause a routing loop, because a router is +automatically skipped if any ancestor of the address that is being processed is +the same as the current address and was processed by the current router. Such +an address is therefore passed to the following routers, so it is handled as if +there were no redirection. When making this loop-avoidance test, the complete +local part, including any prefix or suffix, is used. + +Specifying the same local part without a domain is a common usage in personal +filter files when the user wants to have messages delivered to the local +mailbox and also forwarded elsewhere. For example, the user whose login is cleo +might have a .forward file containing this: + +cleo, cleopatra@egypt.example + +For compatibility with other MTAs, such unqualified local parts may be preceded +by "\", but this is not a requirement for loop prevention. However, it does +make a difference if more than one domain is being handled synonymously. + +If an item begins with "\" and the rest of the item parses as a valid RFC 2822 +address that does not include a domain, the item is qualified using the domain +of the incoming address. In the absence of a leading "\", unqualified addresses +are qualified using the value in qualify_recipient, but you can force the +incoming domain to be used by setting qualify_preserve_domain. + +Care must be taken if there are alias names for local users. Consider an MTA +handling a single local domain where the system alias file contains: + +Sam.Reman: spqr + +Now suppose that Sam (whose login id is spqr) wants to save copies of messages +in the local mailbox, and also forward copies elsewhere. He creates this +forward file: + +Sam.Reman, spqr@reme.elsewhere.example + +With these settings, an incoming message addressed to Sam.Reman fails. The +redirect router for system aliases does not process Sam.Reman the second time +round, because it has previously routed it, and the following routers +presumably cannot handle the alias. The forward file should really contain + +spqr, spqr@reme.elsewhere.example + +but because this is such a common error, the check_ancestor option (see below) +exists to provide a way to get round it. This is normally set on a redirect +router that is handling users' .forward files. + + +22.6 Special items in redirection lists +--------------------------------------- + +In addition to addresses, the following types of item may appear in redirection +lists (that is, in non-filter redirection data): + + * An item is treated as a pipe command if it begins with "|" and does not + parse as a valid RFC 2822 address that includes a domain. A transport for + running the command must be specified by the pipe_transport option. + Normally, either the router or the transport specifies a user and a group + under which to run the delivery. The default is to use the Exim user and + group. + + Single or double quotes can be used for enclosing the individual arguments + of the pipe command; no interpretation of escapes is done for single + quotes. If the command contains a comma character, it is necessary to put + the whole item in double quotes, for example: + + "|/some/command ready,steady,go" + + since items in redirection lists are terminated by commas. Do not, however, + quote just the command. An item such as + + |"/some/command ready,steady,go" + + is interpreted as a pipe with a rather strange command name, and no + arguments. + + Note that the above example assumes that the text comes from a lookup + source of some sort, so that the quotes are part of the data. If composing + a redirect router with a data option directly specifying this command, the + quotes will be used by the configuration parser to define the extent of one + string, but will not be passed down into the redirect router itself. There + are two main approaches to get around this: escape quotes to be part of the + data itself, or avoid using this mechanism and instead create a custom + transport with the command option set and reference that transport from an + accept router. + + * An item is interpreted as a path name if it begins with "/" and does not + parse as a valid RFC 2822 address that includes a domain. For example, + + /home/world/minbari + + is treated as a filename, but + + /s=molari/o=babylon/@x400gate.way + + is treated as an address. For a filename, a transport must be specified + using the file_transport option. However, if the generated path name ends + with a forward slash character, it is interpreted as a directory name + rather than a filename, and directory_transport is used instead. + + Normally, either the router or the transport specifies a user and a group + under which to run the delivery. The default is to use the Exim user and + group. + + However, if a redirection item is the path /dev/null, delivery to it is + bypassed at a high level, and the log entry shows "**bypassed**" instead of + a transport name. In this case the user and group are not used. + + * If an item is of the form + + :include:<path name> + + a list of further items is taken from the given file and included at that + point. Note: Such a file can not be a filter file; it is just an + out-of-line addition to the list. The items in the included list are + separated by commas or newlines and are not subject to expansion. If this + is the first item in an alias list in an lsearch file, a colon must be used + to terminate the alias name. This example is incorrect: + + list1 :include:/opt/lists/list1 + + It must be given as + + list1: :include:/opt/lists/list1 + + * Sometimes you want to throw away mail to a particular local part. Making + the data option expand to an empty string does not work, because that + causes the router to decline. Instead, the alias item + + :blackhole: + + can be used. It does what its name implies. No delivery is done, and no + error message is generated. This has the same effect as specifying /dev/ + null as a destination, but it can be independently disabled. + + Warning: If :blackhole: appears anywhere in a redirection list, no delivery + is done for the original local part, even if other redirection items are + present. If you are generating a multi-item list (for example, by reading a + database) and need the ability to provide a no-op item, you must use /dev/ + null. + + * An attempt to deliver a particular address can be deferred or forced to + fail by redirection items of the form + + :defer: + :fail: + + respectively. When a redirection list contains such an item, it applies to + the entire redirection; any other items in the list are ignored. Any text + following :fail: or :defer: is placed in the error text associated with the + failure. For example, an alias file might contain: + + X.Employee: :fail: Gone away, no forwarding address + + In the case of an address that is being verified from an ACL or as the + subject of a VRFY command, the text is included in the SMTP error response + by default. The text is not included in the response to an EXPN command. In + non-SMTP cases the text is included in the error message that Exim + generates. + + By default, Exim sends a 451 SMTP code for a :defer:, and 550 for :fail:. + However, if the message starts with three digits followed by a space, + optionally followed by an extended code of the form n.n.n, also followed by + a space, and the very first digit is the same as the default error code, + the code from the message is used instead. If the very first digit is + incorrect, a panic error is logged, and the default code is used. You can + suppress the use of the supplied code in a redirect router by setting the + forbid_smtp_code option true. In this case, any SMTP code is quietly + ignored. + + In an ACL, an explicitly provided message overrides the default, but the + default message is available in the variable $acl_verify_message and can + therefore be included in a custom message if this is desired. + + Normally the error text is the rest of the redirection list - a comma does + not terminate it - but a newline does act as a terminator. Newlines are not + normally present in alias expansions. In lsearch lookups they are removed + as part of the continuation process, but they may exist in other kinds of + lookup and in :include: files. + + During routing for message delivery (as opposed to verification), a + redirection containing :fail: causes an immediate failure of the incoming + address, whereas :defer: causes the message to remain in the queue so that + a subsequent delivery attempt can happen at a later time. If an address is + deferred for too long, it will ultimately fail, because the normal retry + rules still apply. + + * Sometimes it is useful to use a single-key search type with a default (see + chapter 9) to look up aliases. However, there may be a need for exceptions + to the default. These can be handled by aliasing them to :unknown:. This + differs from :fail: in that it causes the redirect router to decline, + whereas :fail: forces routing to fail. A lookup which results in an empty + redirection list has the same effect. + + +22.7 Duplicate addresses +------------------------ + +Exim removes duplicate addresses from the list to which it is delivering, so as +to deliver just one copy to each address. This does not apply to deliveries +routed to pipes by different immediate parent addresses, but an indirect +aliasing scheme of the type + +pipe: |/some/command $local_part +localpart1: pipe +localpart2: pipe + +does not work with a message that is addressed to both local parts, because +when the second is aliased to the intermediate local part "pipe" it gets +discarded as being the same as a previously handled address. However, a scheme +such as + +localpart1: |/some/command $local_part +localpart2: |/some/command $local_part + +does result in two different pipe deliveries, because the immediate parents of +the pipes are distinct. + + +22.8 Repeated redirection expansion +----------------------------------- + +When a message cannot be delivered to all of its recipients immediately, +leading to two or more delivery attempts, redirection expansion is carried out +afresh each time for those addresses whose children were not all previously +delivered. If redirection is being used as a mailing list, this can lead to new +members of the list receiving copies of old messages. The one_time option can +be used to avoid this. + + +22.9 Errors in redirection lists +-------------------------------- + +If skip_syntax_errors is set, a malformed address that causes a parsing error +is skipped, and an entry is written to the main log. This may be useful for +mailing lists that are automatically managed. Otherwise, if an error is +detected while generating the list of new addresses, the original address is +deferred. See also syntax_errors_to. + + +22.10 Private options for the redirect router +--------------------------------------------- + +The private options for the redirect router are as follows: + ++------------------------------------------------------+ +|allow_defer|Use: redirect|Type: boolean|Default: false| ++------------------------------------------------------+ + +Setting this option allows the use of :defer: in non-filter redirection data, +or the defer command in an Exim filter file. + ++-----------------------------------------------------+ +|allow_fail|Use: redirect|Type: boolean|Default: false| ++-----------------------------------------------------+ + +If this option is true, the :fail: item can be used in a redirection list, and +the fail command may be used in an Exim filter file. + ++-------------------------------------------------------+ +|allow_filter|Use: redirect|Type: boolean|Default: false| ++-------------------------------------------------------+ + +Setting this option allows Exim to interpret redirection data that starts with +"#Exim filter" or "#Sieve filter" as a set of filtering instructions. There are +some features of Exim filter files that some administrators may wish to lock +out; see the forbid_filter_xxx options below. + +It is also possible to lock out Exim filters or Sieve filters while allowing +the other type; see forbid_exim_filter and forbid_sieve_filter. + +The filter is run using the uid and gid set by the generic user and group +options. These take their defaults from the password data if check_local_user +is set, so in the normal case of users' personal filter files, the filter is +run as the relevant user. When allow_filter is set true, Exim insists that +either check_local_user or user is set. + ++-------------------------------------------------------+ +|allow_freeze|Use: redirect|Type: boolean|Default: false| ++-------------------------------------------------------+ + +Setting this option allows the use of the freeze command in an Exim filter. +This command is more normally encountered in system filters, and is disabled by +default for redirection filters because it isn't something you usually want to +let ordinary users do. + ++---------------------------------------------------------+ +|check_ancestor|Use: redirect|Type: boolean|Default: false| ++---------------------------------------------------------+ + +This option is concerned with handling generated addresses that are the same as +some address in the list of redirection ancestors of the current address. +Although it is turned off by default in the code, it is set in the default +configuration file for handling users' .forward files. It is recommended for +this use of the redirect router. + +When check_ancestor is set, if a generated address (including the domain) is +the same as any ancestor of the current address, it is replaced by a copy of +the current address. This helps in the case where local part A is aliased to B, +and B has a .forward file pointing back to A. For example, within a single +domain, the local part "Joe.Bloggs" is aliased to "jb" and jb/.forward +contains: + +\Joe.Bloggs, <other item(s)> + +Without the check_ancestor setting, either local part ("jb" or "joe.bloggs") +gets processed once by each router and so ends up as it was originally. If "jb" +is the real mailbox name, mail to "jb" gets delivered (having been turned into +"joe.bloggs" by the .forward file and back to "jb" by the alias), but mail to +"joe.bloggs" fails. Setting check_ancestor on the redirect router that handles +the .forward file prevents it from turning "jb" back into "joe.bloggs" when +that was the original address. See also the repeat_use option below. + ++----------------------------------------------------------+ +|check_group|Use: redirect|Type: boolean|Default: see below| ++----------------------------------------------------------+ + +When the file option is used, the group owner of the file is checked only when +this option is set. The permitted groups are those listed in the owngroups +option, together with the user's default group if check_local_user is set. If +the file has the wrong group, routing is deferred. The default setting for this +option is true if check_local_user is set and the modemask option permits the +group write bit, or if the owngroups option is set. Otherwise it is false, and +no group check occurs. + ++----------------------------------------------------------+ +|check_owner|Use: redirect|Type: boolean|Default: see below| ++----------------------------------------------------------+ + +When the file option is used, the owner of the file is checked only when this +option is set. If check_local_user is set, the local user is permitted; +otherwise the owner must be one of those listed in the owners option. The +default value for this option is true if check_local_user or owners is set. +Otherwise the default is false, and no owner check occurs. + ++-----------------------------------------------+ +|data|Use: redirect|Type: string*|Default: unset| ++-----------------------------------------------+ + +This option is mutually exclusive with file. One or other of them must be set, +but not both. The contents of data are expanded, and then used as the list of +forwarding items, or as a set of filtering instructions. If the expansion is +forced to fail, or the result is an empty string or a string that has no effect +(consists entirely of comments), the router declines. + +When filtering instructions are used, the string must begin with "#Exim +filter", and all comments in the string, including this initial one, must be +terminated with newline characters. For example: + +data = #Exim filter\n\ + if $h_to: contains Exim then save $home/mail/exim endif + +If you are reading the data from a database where newlines cannot be included, +you can use the ${sg} expansion item to turn the escape string of your choice +into a newline. + ++--------------------------------------------------------------+ +|directory_transport|Use: redirect|Type: string*|Default: unset| ++--------------------------------------------------------------+ + +A redirect router sets up a direct delivery to a directory when a path name +ending with a slash is specified as a new "address". The transport used is +specified by this option, which, after expansion, must be the name of a +configured transport. This should normally be an appendfile transport. + ++-----------------------------------------------+ +|file|Use: redirect|Type: string*|Default: unset| ++-----------------------------------------------+ + +This option specifies the name of a file that contains the redirection data. It +is mutually exclusive with the data option. The string is expanded before use; +if the expansion is forced to fail, the router declines. Other expansion +failures cause delivery to be deferred. The result of a successful expansion +must be an absolute path. The entire file is read and used as the redirection +data. If the data is an empty string or a string that has no effect (consists +entirely of comments), the router declines. + +If the attempt to open the file fails with a "does not exist" error, Exim runs +a check on the containing directory, unless ignore_enotdir is true (see below). +If the directory does not appear to exist, delivery is deferred. This can +happen when users' .forward files are in NFS-mounted directories, and there is +a mount problem. If the containing directory does exist, but the file does not, +the router declines. + ++---------------------------------------------------------+ +|file_transport|Use: redirect|Type: string*|Default: unset| ++---------------------------------------------------------+ + +A redirect router sets up a direct delivery to a file when a path name not +ending in a slash is specified as a new "address". The transport used is +specified by this option, which, after expansion, must be the name of a +configured transport. This should normally be an appendfile transport. When it +is running, the filename is in $address_file. + ++-------------------------------------------------------------+ +|filter_prepend_home|Use: redirect|Type: boolean|Default: true| ++-------------------------------------------------------------+ + +When this option is true, if a save command in an Exim filter specifies a +relative path, and $home is defined, it is automatically prepended to the +relative path. If this option is set false, this action does not happen. The +relative path is then passed to the transport unmodified. + ++-----------------------------------------------------------+ +|forbid_blackhole|Use: redirect|Type: boolean|Default: false| ++-----------------------------------------------------------+ + +If this option is true, the :blackhole: item may not appear in a redirection +list. + ++-------------------------------------------------------------+ +|forbid_exim_filter|Use: redirect|Type: boolean|Default: false| ++-------------------------------------------------------------+ + +If this option is set true, only Sieve filters are permitted when allow_filter +is true. + ++------------------------------------------------------+ +|forbid_file|Use: redirect|Type: boolean|Default: false| ++------------------------------------------------------+ + +If this option is true, this router may not generate a new address that +specifies delivery to a local file or directory, either from a filter or from a +conventional forward file. This option is forced to be true if one_time is set. +It applies to Sieve filters as well as to Exim filters, but if true, it locks +out the Sieve's "keep" facility. + ++---------------------------------------------------------------+ +|forbid_filter_dlfunc|Use: redirect|Type: boolean|Default: false| ++---------------------------------------------------------------+ + +If this option is true, string expansions in Exim filters are not allowed to +make use of the dlfunc expansion facility to run dynamically loaded functions. + ++-------------------------------------------------------------------+ +|forbid_filter_existstest|Use: redirect|Type: boolean|Default: false| ++-------------------------------------------------------------------+ + +If this option is true, string expansions in Exim filters are not allowed to +make use of the exists condition or the stat expansion item. + ++-----------------------------------------------------------------+ +|forbid_filter_logwrite|Use: redirect|Type: boolean|Default: false| ++-----------------------------------------------------------------+ + +If this option is true, use of the logging facility in Exim filters is not +permitted. Logging is in any case available only if the filter is being run +under some unprivileged uid (which is normally the case for ordinary users' +.forward files). + ++---------------------------------------------------------------+ +|forbid_filter_lookup|Use: redirect|Type: boolean|Default: false| ++---------------------------------------------------------------+ + +If this option is true, string expansions in Exim filter files are not allowed +to make use of lookup items. + ++-------------------------------------------------------------+ +|forbid_filter_perl|Use: redirect|Type: boolean|Default: false| ++-------------------------------------------------------------+ + +This option has an effect only if Exim is built with embedded Perl support. If +it is true, string expansions in Exim filter files are not allowed to make use +of the embedded Perl support. + ++-----------------------------------------------------------------+ +|forbid_filter_readfile|Use: redirect|Type: boolean|Default: false| ++-----------------------------------------------------------------+ + +If this option is true, string expansions in Exim filter files are not allowed +to make use of readfile items. + ++-------------------------------------------------------------------+ +|forbid_filter_readsocket|Use: redirect|Type: boolean|Default: false| ++-------------------------------------------------------------------+ + +If this option is true, string expansions in Exim filter files are not allowed +to make use of readsocket items. + ++--------------------------------------------------------------+ +|forbid_filter_reply|Use: redirect|Type: boolean|Default: false| ++--------------------------------------------------------------+ + +If this option is true, this router may not generate an automatic reply +message. Automatic replies can be generated only from Exim or Sieve filter +files, not from traditional forward files. This option is forced to be true if +one_time is set. + ++------------------------------------------------------------+ +|forbid_filter_run|Use: redirect|Type: boolean|Default: false| ++------------------------------------------------------------+ + +If this option is true, string expansions in Exim filter files are not allowed +to make use of run items. + ++---------------------------------------------------------+ +|forbid_include|Use: redirect|Type: boolean|Default: false| ++---------------------------------------------------------+ + +If this option is true, items of the form + +:include:<path name> + +are not permitted in non-filter redirection lists. + ++------------------------------------------------------+ +|forbid_pipe|Use: redirect|Type: boolean|Default: false| ++------------------------------------------------------+ + +If this option is true, this router may not generate a new address which +specifies delivery to a pipe, either from an Exim filter or from a conventional +forward file. This option is forced to be true if one_time is set. + ++--------------------------------------------------------------+ +|forbid_sieve_filter|Use: redirect|Type: boolean|Default: false| ++--------------------------------------------------------------+ + +If this option is set true, only Exim filters are permitted when allow_filter +is true. + ++-----------------------------------------------------------+ +|forbid_smtp_code|Use: redirect|Type: boolean|Default: false| ++-----------------------------------------------------------+ + +If this option is set true, any SMTP error codes that are present at the start +of messages specified for ":defer:" or ":fail:" are quietly ignored, and the +default codes (451 and 550, respectively) are always used. + ++---------------------------------------------------------------+ +|hide_child_in_errmsg|Use: redirect|Type: boolean|Default: false| ++---------------------------------------------------------------+ + +If this option is true, it prevents Exim from quoting a child address if it +generates a bounce or delay message for it. Instead it says "an address +generated from <the top level address>". Of course, this applies only to +bounces generated locally. If a message is forwarded to another host, its +bounce may well quote the generated address. + ++--------------------------------------------------------+ +|ignore_eacces|Use: redirect|Type: boolean|Default: false| ++--------------------------------------------------------+ + +If this option is set and an attempt to open a redirection file yields the +EACCES error (permission denied), the redirect router behaves as if the file +did not exist. + ++---------------------------------------------------------+ +|ignore_enotdir|Use: redirect|Type: boolean|Default: false| ++---------------------------------------------------------+ + +If this option is set and an attempt to open a redirection file yields the +ENOTDIR error (something on the path is not a directory), the redirect router +behaves as if the file did not exist. + +Setting ignore_enotdir has another effect as well: When a redirect router that +has the file option set discovers that the file does not exist (the ENOENT +error), it tries to stat() the parent directory, as a check against unmounted +NFS directories. If the parent can not be statted, delivery is deferred. +However, it seems wrong to do this check when ignore_enotdir is set, because +that option tells Exim to ignore "something on the path is not a directory" +(the ENOTDIR error). This is a confusing area, because it seems that some +operating systems give ENOENT where others give ENOTDIR. + ++-----------------------------------------------------------+ +|include_directory|Use: redirect|Type: string|Default: unset| ++-----------------------------------------------------------+ + +If this option is set, the path names of any :include: items in a redirection +list must start with this directory. + ++-------------------------------------------------------+ +|modemask|Use: redirect|Type: octal integer|Default: 022| ++-------------------------------------------------------+ + +This specifies mode bits which must not be set for a file specified by the file +option. If any of the forbidden bits are set, delivery is deferred. + ++---------------------------------------------------+ +|one_time|Use: redirect|Type: boolean|Default: false| ++---------------------------------------------------+ + +Sometimes the fact that Exim re-evaluates aliases and reprocesses redirection +files each time it tries to deliver a message causes a problem when one or more +of the generated addresses fails be delivered at the first attempt. The problem +is not one of duplicate delivery - Exim is clever enough to handle that - but +of what happens when the redirection list changes during the time that the +message is on Exim's queue. This is particularly true in the case of mailing +lists, where new subscribers might receive copies of messages that were posted +before they subscribed. + +If one_time is set and any addresses generated by the router fail to deliver at +the first attempt, the failing addresses are added to the message as "top +level" addresses, and the parent address that generated them is marked +"delivered". Thus, redirection does not happen again at the next delivery +attempt. + +Warning 1: Any header line addition or removal that is specified by this router +would be lost if delivery did not succeed at the first attempt. For this +reason, the headers_add and headers_remove generic options are not permitted +when one_time is set. + +Warning 2: To ensure that the router generates only addresses (as opposed to +pipe or file deliveries or auto-replies) forbid_file, forbid_pipe, and +forbid_filter_reply are forced to be true when one_time is set. + +Warning 3: The unseen generic router option may not be set with one_time. + +The original top-level address is remembered with each of the generated +addresses, and is output in any log messages. However, any intermediate parent +addresses are not recorded. This makes a difference to the log only if +all_parents log selector is set. It is expected that one_time will typically be +used for mailing lists, where there is normally just one level of expansion. + ++-----------------------------------------------------+ +|owners|Use: redirect|Type: string list|Default: unset| ++-----------------------------------------------------+ + +This specifies a list of permitted owners for the file specified by file. This +list is in addition to the local user when check_local_user is set. See +check_owner above. + ++--------------------------------------------------------+ +|owngroups|Use: redirect|Type: string list|Default: unset| ++--------------------------------------------------------+ + +This specifies a list of permitted groups for the file specified by file. The +list is in addition to the local user's primary group when check_local_user is +set. See check_group above. + ++---------------------------------------------------------+ +|pipe_transport|Use: redirect|Type: string*|Default: unset| ++---------------------------------------------------------+ + +A redirect router sets up a direct delivery to a pipe when a string starting +with a vertical bar character is specified as a new "address". The transport +used is specified by this option, which, after expansion, must be the name of a +configured transport. This should normally be a pipe transport. When the +transport is run, the pipe command is in $address_pipe. + ++---------------------------------------------------------+ +|qualify_domain|Use: redirect|Type: string*|Default: unset| ++---------------------------------------------------------+ + +If this option is set, and an unqualified address (one without a domain) is +generated, and that address would normally be qualified by the global setting +in qualify_recipient, it is instead qualified with the domain specified by +expanding this string. If the expansion fails, the router declines. If you want +to revert to the default, you can have the expansion generate +$qualify_recipient. + +This option applies to all unqualified addresses generated by Exim filters, but +for traditional .forward files, it applies only to addresses that are not +preceded by a backslash. Sieve filters cannot generate unqualified addresses. + ++------------------------------------------------------------------+ +|qualify_preserve_domain|Use: redirect|Type: boolean|Default: false| ++------------------------------------------------------------------+ + +If this option is set, the router's local qualify_domain option must not be set +(a configuration error occurs if it is). If an unqualified address (one without +a domain) is generated, it is qualified with the domain of the parent address +(the immediately preceding ancestor) instead of the global qualify_recipient +value. In the case of a traditional .forward file, this applies whether or not +the address is preceded by a backslash. + ++----------------------------------------------------+ +|repeat_use|Use: redirect|Type: boolean|Default: true| ++----------------------------------------------------+ + +If this option is set false, the router is skipped for a child address that has +any ancestor that was routed by this router. This test happens before any of +the other preconditions are tested. Exim's default anti-looping rules skip only +when the ancestor is the same as the current address. See also check_ancestor +above and the generic redirect_router option. + ++----------------------------------------------------------+ +|reply_transport|Use: redirect|Type: string*|Default: unset| ++----------------------------------------------------------+ + +A redirect router sets up an automatic reply when a mail or vacation command is +used in a filter file. The transport used is specified by this option, which, +after expansion, must be the name of a configured transport. This should +normally be an autoreply transport. Other transports are unlikely to do +anything sensible or useful. + ++-------------------------------------------------+ +|rewrite|Use: redirect|Type: boolean|Default: true| ++-------------------------------------------------+ + +If this option is set false, addresses generated by the router are not subject +to address rewriting. Otherwise, they are treated like new addresses and are +rewritten according to the global rewriting rules. + ++-----------------------------------------------------------+ +|sieve_subaddress|Use: redirect|Type: string*|Default: unset| ++-----------------------------------------------------------+ + +The value of this option is passed to a Sieve filter to specify the :subaddress +part of an address. + ++------------------------------------------------------------+ +|sieve_useraddress|Use: redirect|Type: string*|Default: unset| ++------------------------------------------------------------+ + +The value of this option is passed to a Sieve filter to specify the :user part +of an address. However, if it is unset, the entire original local part +(including any prefix or suffix) is used for :user. + ++-------------------------------------------------------------------+ +|sieve_vacation_directory|Use: redirect|Type: string*|Default: unset| ++-------------------------------------------------------------------+ + +To enable the "vacation" extension for Sieve filters, you must set +sieve_vacation_directory to the directory where vacation databases are held (do +not put anything else in that directory), and ensure that the reply_transport +option refers to an autoreply transport. Each user needs their own directory; +Exim will create it if necessary. + ++-------------------------------------------------------------+ +|skip_syntax_errors|Use: redirect|Type: boolean|Default: false| ++-------------------------------------------------------------+ + +If skip_syntax_errors is set, syntactically malformed addresses in non-filter +redirection data are skipped, and each failing address is logged. If +syntax_errors_to is set, a message is sent to the address it defines, giving +details of the failures. If syntax_errors_text is set, its contents are +expanded and placed at the head of the error message generated by +syntax_errors_to. Usually it is appropriate to set syntax_errors_to to be the +same address as the generic errors_to option. The skip_syntax_errors option is +often used when handling mailing lists. + +If all the addresses in a redirection list are skipped because of syntax +errors, the router declines to handle the original address, and it is passed to +the following routers. + +If skip_syntax_errors is set when an Exim filter is interpreted, any syntax +error in the filter causes filtering to be abandoned without any action being +taken. The incident is logged, and the router declines to handle the address, +so it is passed to the following routers. + +Syntax errors in a Sieve filter file cause the "keep" action to occur. This +action is specified by RFC 3028. The values of skip_syntax_errors, +syntax_errors_to, and syntax_errors_text are not used. + +skip_syntax_errors can be used to specify that errors in users' forward lists +or filter files should not prevent delivery. The syntax_errors_to option, used +with an address that does not get redirected, can be used to notify users of +these errors, by means of a router like this: + +userforward: + driver = redirect + allow_filter + check_local_user + file = $home/.forward + file_transport = address_file + pipe_transport = address_pipe + reply_transport = address_reply + no_verify + skip_syntax_errors + syntax_errors_to = real-$local_part@$domain + syntax_errors_text = \ + This is an automatically generated message. An error has\n\ + been found in your .forward file. Details of the error are\n\ + reported below. While this error persists, you will receive\n\ + a copy of this message for every message that is addressed\n\ + to you. If your .forward file is a filter file, or if it is\n\ + a non-filter file containing no valid forwarding addresses,\n\ + a copy of each incoming message will be put in your normal\n\ + mailbox. If a non-filter file contains at least one valid\n\ + forwarding address, forwarding to the valid addresses will\n\ + happen, and those will be the only deliveries that occur. + +You also need a router to ensure that local addresses that are prefixed by +"real-" are recognized, but not forwarded or filtered. For example, you could +put this immediately before the userforward router: + +real_localuser: + driver = accept + check_local_user + local_part_prefix = real- + transport = local_delivery + +For security, it would probably be a good idea to restrict the use of this +router to locally-generated messages, using a condition such as this: + + condition = ${if match {$sender_host_address}\ + {\N^(|127\.0\.0\.1)$\N}} + ++-------------------------------------------------------------+ +|syntax_errors_text|Use: redirect|Type: string*|Default: unset| ++-------------------------------------------------------------+ + +See skip_syntax_errors above. + ++----------------------------------------------------------+ +|syntax_errors_to|Use: redirect|Type: string|Default: unset| ++----------------------------------------------------------+ + +See skip_syntax_errors above. + + + +=============================================================================== +23. ENVIRONMENT FOR RUNNING LOCAL TRANSPORTS + +Local transports handle deliveries to files and pipes. (The autoreply transport +can be thought of as similar to a pipe.) Exim always runs transports in +subprocesses, under specified uids and gids. Typical deliveries to local +mailboxes run under the uid and gid of the local user. + +Exim also sets a specific current directory while running the transport; for +some transports a home directory setting is also relevant. The pipe transport +is the only one that sets up environment variables; see section 29.4 for +details. + +The values used for the uid, gid, and the directories may come from several +different places. In many cases, the router that handles the address associates +settings with that address as a result of its check_local_user, group, or user +options. However, values may also be given in the transport's own +configuration, and these override anything that comes from the router. + + +23.1 Concurrent deliveries +-------------------------- + +If two different messages for the same local recipient arrive more or less +simultaneously, the two delivery processes are likely to run concurrently. When +the appendfile transport is used to write to a file, Exim applies locking rules +to stop concurrent processes from writing to the same file at the same time. + +However, when you use a pipe transport, it is up to you to arrange any locking +that is needed. Here is a silly example: + +my_transport: + driver = pipe + command = /bin/sh -c 'cat >>/some/file' + +This is supposed to write the message at the end of the file. However, if two +messages arrive at the same time, the file will be scrambled. You can use the +exim_lock utility program (see section 53.15) to lock a file using the same +algorithm that Exim itself uses. + + +23.2 Uids and gids +------------------ + +All transports have the options group and user. If group is set, it overrides +any group that the router set in the address, even if user is not set for the +transport. This makes it possible, for example, to run local mail delivery +under the uid of the recipient (set by the router), but in a special group (set +by the transport). For example: + +# Routers ... +# User/group are set by check_local_user in this router +local_users: + driver = accept + check_local_user + transport = group_delivery + +# Transports ... +# This transport overrides the group +group_delivery: + driver = appendfile + file = /var/spool/mail/$local_part + group = mail + +If user is set for a transport, its value overrides what is set in the address +by the router. If user is non-numeric and group is not set, the gid associated +with the user is used. If user is numeric, group must be set. + +When the uid is taken from the transport's configuration, the initgroups() +function is called for the groups associated with that uid if the initgroups +option is set for the transport. When the uid is not specified by the +transport, but is associated with the address by a router, the option for +calling initgroups() is taken from the router configuration. + +The pipe transport contains the special option pipe_as_creator. If this is set +and user is not set, the uid of the process that called Exim to receive the +message is used, and if group is not set, the corresponding original gid is +also used. + +This is the detailed preference order for obtaining a gid; the first of the +following that is set is used: + + * A group setting of the transport; + + * A group setting of the router; + + * A gid associated with a user setting of the router, either as a result of + check_local_user or an explicit non-numeric user setting; + + * The group associated with a non-numeric user setting of the transport; + + * In a pipe transport, the creator's gid if deliver_as_creator is set and the + uid is the creator's uid; + + * The Exim gid if the Exim uid is being used as a default. + +If, for example, the user is specified numerically on the router and there are +no group settings, no gid is available. In this situation, an error occurs. +This is different for the uid, for which there always is an ultimate default. +The first of the following that is set is used: + + * A user setting of the transport; + + * In a pipe transport, the creator's uid if deliver_as_creator is set; + + * A user setting of the router; + + * A check_local_user setting of the router; + + * The Exim uid. + +Of course, an error will still occur if the uid that is chosen is on the +never_users list. + + +23.3 Current and home directories +--------------------------------- + +Routers may set current and home directories for local transports by means of +the transport_current_directory and transport_home_directory options. However, +if the transport's current_directory or home_directory options are set, they +override the router's values. In detail, the home directory for a local +transport is taken from the first of these values that is set: + + * The home_directory option on the transport; + + * The transport_home_directory option on the router; + + * The password data if check_local_user is set on the router; + + * The router_home_directory option on the router. + +The current directory is taken from the first of these values that is set: + + * The current_directory option on the transport; + + * The transport_current_directory option on the router. + +If neither the router nor the transport sets a current directory, Exim uses the +value of the home directory, if it is set. Otherwise it sets the current +directory to / before running a local transport. + + +23.4 Expansion variables derived from the address +------------------------------------------------- + +Normally a local delivery is handling a single address, and in that case the +variables such as $domain and $local_part are set during local deliveries. +However, in some circumstances more than one address may be handled at once +(for example, while writing batch SMTP for onward transmission by some other +means). In this case, the variables associated with the local part are never +set, $domain is set only if all the addresses have the same domain, and +$original_domain is never set. + + + +=============================================================================== +24. GENERIC OPTIONS FOR TRANSPORTS + +The following generic options apply to all transports: + ++------------------------------------------------------+ +|body_only|Use: transports|Type: boolean|Default: false| ++------------------------------------------------------+ + +If this option is set, the message's headers are not transported. It is +mutually exclusive with headers_only. If it is used with the appendfile or pipe +transports, the settings of message_prefix and message_suffix should be +checked, because this option does not automatically suppress them. + ++--------------------------------------------------------------+ +|current_directory|Use: transports|Type: string*|Default: unset| ++--------------------------------------------------------------+ + +This specifies the current directory that is to be set while running the +transport, overriding any value that may have been set by the router. If the +expansion fails for any reason, including forced failure, an error is logged, +and delivery is deferred. + ++------------------------------------------------------------+ +|disable_logging|Use: transports|Type: boolean|Default: false| ++------------------------------------------------------------+ + +If this option is set true, nothing is logged for any deliveries by the +transport or for any transport errors. You should not set this option unless +you really, really know what you are doing. + ++--------------------------------------------------------+ +|debug_print|Use: transports|Type: string*|Default: unset| ++--------------------------------------------------------+ + +If this option is set and debugging is enabled (see the -d command line +option), the string is expanded and included in the debugging output when the +transport is run. If expansion of the string fails, the error message is +written to the debugging output, and Exim carries on processing. This facility +is provided to help with checking out the values of variables and so on when +debugging driver configurations. For example, if a headers_add option is not +working properly, debug_print could be used to output the variables it +references. A newline is added to the text if it does not end with one. The +variables $transport_name and $router_name contain the name of the transport +and the router that called it. + ++--------------------------------------------------------------+ +|delivery_date_add|Use: transports|Type: boolean|Default: false| ++--------------------------------------------------------------+ + +If this option is true, a Delivery-date: header is added to the message. This +gives the actual time the delivery was made. As this is not a standard header, +Exim has a configuration option (delivery_date_remove) which requests its +removal from incoming messages, so that delivered messages can safely be resent +to other recipients. + ++--------------------------------------------------+ +|driver|Use: transports|Type: string|Default: unset| ++--------------------------------------------------+ + +This specifies which of the available transport drivers is to be used. There is +no default, and this option must be set for every transport. + ++------------------------------------------------------------+ +|envelope_to_add|Use: transports|Type: boolean|Default: false| ++------------------------------------------------------------+ + +If this option is true, an Envelope-to: header is added to the message. This +gives the original address(es) in the incoming envelope that caused this +delivery to happen. More than one address may be present if the transport is +configured to handle several addresses at once, or if more than one original +address was redirected to the same final address. As this is not a standard +header, Exim has a configuration option (envelope_to_remove) which requests its +removal from incoming messages, so that delivered messages can safely be resent +to other recipients. + ++---------------------------------------------------------+ +|event_action|Use: transports|Type: string*|Default: unset| ++---------------------------------------------------------+ + +This option declares a string to be expanded for Exim's events mechanism. For +details see chapter 60. + ++-------------------------------------------------------+ +|group|Use: transports|Type: string*|Default: Exim group| ++-------------------------------------------------------+ + +This option specifies a gid for running the transport process, overriding any +value that the router supplies, and also overriding any value associated with +user (see below). + ++------------------------------------------------------+ +|headers_add|Use: transports|Type: list*|Default: unset| ++------------------------------------------------------+ + +This option specifies a list of text headers, newline-separated (by default, +changeable in the usual way 6.21), which are (separately) expanded and added to +the header portion of a message as it is transported, as described in section +47.17. Additional header lines can also be specified by routers. If the result +of the expansion is an empty string, or if the expansion is forced to fail, no +action is taken. Other expansion failures are treated as errors and cause the +delivery to be deferred. + +Unlike most options, headers_add can be specified multiple times for a +transport; all listed headers are added. + ++---------------------------------------------------------+ +|headers_only|Use: transports|Type: boolean|Default: false| ++---------------------------------------------------------+ + +If this option is set, the message's body is not transported. It is mutually +exclusive with body_only. If it is used with the appendfile or pipe transports, +the settings of message_prefix and message_suffix should be checked, since this +option does not automatically suppress them. + ++---------------------------------------------------------+ +|headers_remove|Use: transports|Type: list*|Default: unset| ++---------------------------------------------------------+ + +This option specifies a list of header names, colon-separated (by default, +changeable in the usual way 6.21); these headers are omitted from the message +as it is transported, as described in section 47.17. Header removal can also be +specified by routers. Each list item is separately expanded. If the result of +the expansion is an empty string, or if the expansion is forced to fail, no +action is taken. Other expansion failures are treated as errors and cause the +delivery to be deferred. + +Unlike most options, headers_remove can be specified multiple times for a +transport; all listed headers are removed. + +Warning: Because of the separate expansion of the list items, items that +contain a list separator must have it doubled. To avoid this, change the list +separator (6.21). + ++-----------------------------------------------------------+ +|headers_rewrite|Use: transports|Type: string|Default: unset| ++-----------------------------------------------------------+ + +This option allows addresses in header lines to be rewritten at transport time, +that is, as the message is being copied to its destination. The contents of the +option are a colon-separated list of rewriting rules. Each rule is in exactly +the same form as one of the general rewriting rules that are applied when a +message is received. These are described in chapter 31. For example, + +headers_rewrite = a@b c@d f : \ + x@y w@z + +changes a@b into c@d in From: header lines, and x@y into w@z in all +address-bearing header lines. The rules are applied to the header lines just +before they are written out at transport time, so they affect only those copies +of the message that pass through the transport. However, only the message's +original header lines, and any that were added by a system filter, are +rewritten. If a router or transport adds header lines, they are not affected by +this option. These rewriting rules are not applied to the envelope. You can +change the return path using return_path, but you cannot change envelope +recipients at this time. + ++-----------------------------------------------------------+ +|home_directory|Use: transports|Type: string*|Default: unset| ++-----------------------------------------------------------+ + +This option specifies a home directory setting for a local transport, +overriding any value that may be set by the router. The home directory is +placed in $home while expanding the transport's private options. It is also +used as the current directory if no current directory is set by the +current_directory option on the transport or the transport_current_directory +option on the router. If the expansion fails for any reason, including forced +failure, an error is logged, and delivery is deferred. + ++-------------------------------------------------------+ +|initgroups|Use: transports|Type: boolean|Default: false| ++-------------------------------------------------------+ + +If this option is true and the uid for the delivery process is provided by the +transport, the initgroups() function is called when running the transport to +ensure that any additional groups associated with the uid are set up. + ++----------------------------------------------------------+ +|max_parallel|Use: transports|Type: integer*|Default: unset| ++----------------------------------------------------------+ + +If this option is set and expands to an integer greater than zero it limits the +number of concurrent runs of the transport. The control does not apply to +shadow transports. + +Exim implements this control by means of a hints database in which a record is +incremented whenever a transport process is being created. The record is +decremented and possibly removed when the process terminates. Obviously there +is scope for records to get left lying around if there is a system or program +crash. To guard against this, Exim ignores any records that are more than six +hours old. + +If you use this option, you should also arrange to delete the relevant hints +database whenever your system reboots. The names of the files start with misc +and they are kept in the spool/db directory. There may be one or two files, +depending on the type of DBM in use. The same files are used for ETRN and smtp +transport serialization. + ++-----------------------------------------------------------+ +|message_size_limit|Use: transports|Type: string*|Default: 0| ++-----------------------------------------------------------+ + +This option controls the size of messages passed through the transport. It is +expanded before use; the result of the expansion must be a sequence of decimal +digits, optionally followed by K or M. If the expansion fails for any reason, +including forced failure, or if the result is not of the required form, +delivery is deferred. If the value is greater than zero and the size of a +message exceeds this limit, the address is failed. If there is any chance that +the resulting bounce message could be routed to the same transport, you should +ensure that return_size_limit is less than the transport's message_size_limit, +as otherwise the bounce message will fail to get delivered. + ++-----------------------------------------------------------------+ +|rcpt_include_affixes|Use: transports|Type: boolean|Default: false| ++-----------------------------------------------------------------+ + +When this option is false (the default), and an address that has had any +affixes (prefixes or suffixes) removed from the local part is delivered by any +form of SMTP or LMTP, the affixes are not included. For example, if a router +that contains + +local_part_prefix = *- + +routes the address abc-xyz@some.domain to an SMTP transport, the envelope is +delivered with + +RCPT TO:<xyz@some.domain> + +This is also the case when an ACL-time callout is being used to verify a +recipient address. However, if rcpt_include_affixes is set true, the whole +local part is included in the RCPT command. This option applies to BSMTP +deliveries by the appendfile and pipe transports as well as to the lmtp and +smtp transports. + ++---------------------------------------------------------------------+ +|retry_use_local_part|Use: transports|Type: boolean|Default: see below| ++---------------------------------------------------------------------+ + +When a delivery suffers a temporary failure, a retry record is created in +Exim's hints database. For remote deliveries, the key for the retry record is +based on the name and/or IP address of the failing remote host. For local +deliveries, the key is normally the entire address, including both the local +part and the domain. This is suitable for most common cases of local delivery +temporary failure - for example, exceeding a mailbox quota should delay only +deliveries to that mailbox, not to the whole domain. + +However, in some special cases you may want to treat a temporary local delivery +as a failure associated with the domain, and not with a particular local part. +(For example, if you are storing all mail for some domain in files.) You can do +this by setting retry_use_local_part false. + +For all the local transports, its default value is true. For remote transports, +the default value is false for tidiness, but changing the value has no effect +on a remote transport in the current implementation. + ++--------------------------------------------------------+ +|return_path|Use: transports|Type: string*|Default: unset| ++--------------------------------------------------------+ + +If this option is set, the string is expanded at transport time and replaces +the existing return path (envelope sender) value in the copy of the message +that is being delivered. An empty return path is permitted. This feature is +designed for remote deliveries, where the value of this option is used in the +SMTP MAIL command. If you set return_path for a local transport, the only +effect is to change the address that is placed in the Return-path: header line, +if one is added to the message (see the next option). + +Note: A changed return path is not logged unless you add +return_path_on_delivery to the log selector. + +The expansion can refer to the existing value via $return_path. This is either +the message's envelope sender, or an address set by the errors_to option on a +router. If the expansion is forced to fail, no replacement occurs; if it fails +for another reason, delivery is deferred. This option can be used to support +VERP (Variable Envelope Return Paths) - see section 50.6. + +Note: If a delivery error is detected locally, including the case when a remote +server rejects a message at SMTP time, the bounce message is not sent to the +value of this option. It is sent to the previously set errors address. This +defaults to the incoming sender address, but can be changed by setting +errors_to in a router. + ++------------------------------------------------------------+ +|return_path_add|Use: transports|Type: boolean|Default: false| ++------------------------------------------------------------+ + +If this option is true, a Return-path: header is added to the message. Although +the return path is normally available in the prefix line of BSD mailboxes, this +is commonly not displayed by MUAs, and so the user does not have easy access to +it. + +RFC 2821 states that the Return-path: header is added to a message "when the +delivery SMTP server makes the final delivery". This implies that this header +should not be present in incoming messages. Exim has a configuration option, +return_path_remove, which requests removal of this header from incoming +messages, so that delivered messages can safely be resent to other recipients. + ++-------------------------------------------------------------+ +|shadow_condition|Use: transports|Type: string*|Default: unset| ++-------------------------------------------------------------+ + +See shadow_transport below. + ++------------------------------------------------------------+ +|shadow_transport|Use: transports|Type: string|Default: unset| ++------------------------------------------------------------+ + +A local transport may set the shadow_transport option to the name of another +local transport. Shadow remote transports are not supported. + +Whenever a delivery to the main transport succeeds, and either shadow_condition +is unset, or its expansion does not result in the empty string or one of the +strings "0" or "no" or "false", the message is also passed to the shadow +transport, with the same delivery address or addresses. If expansion fails, no +action is taken except that non-forced expansion failures cause a log line to +be written. + +The result of the shadow transport is discarded and does not affect the +subsequent processing of the message. Only a single level of shadowing is +provided; the shadow_transport option is ignored on any transport when it is +running as a shadow. Options concerned with output from pipes are also ignored. +The log line for the successful delivery has an item added on the end, of the +form + +ST=<shadow transport name> + +If the shadow transport did not succeed, the error message is put in +parentheses afterwards. Shadow transports can be used for a number of different +purposes, including keeping more detailed log information than Exim normally +provides, and implementing automatic acknowledgment policies based on message +headers that some sites insist on. + ++-------------------------------------------------------------+ +|transport_filter|Use: transports|Type: string*|Default: unset| ++-------------------------------------------------------------+ + +This option sets up a filtering (in the Unix shell sense) process for messages +at transport time. It should not be confused with mail filtering as set up by +individual users or via a system filter. If unset, or expanding to an empty +string, no filtering is done. + +When the message is about to be written out, the command specified by +transport_filter is started up in a separate, parallel process, and the entire +message, including the header lines, is passed to it on its standard input +(this in fact is done from a third process, to avoid deadlock). The command +must be specified as an absolute path. + +The lines of the message that are written to the transport filter are +terminated by newline ("\n"). The message is passed to the filter before any +SMTP-specific processing, such as turning "\n" into "\r\n" and escaping lines +beginning with a dot, and also before any processing implied by the settings of +check_string and escape_string in the appendfile or pipe transports. + +The standard error for the filter process is set to the same destination as its +standard output; this is read and written to the message's ultimate +destination. The process that writes the message to the filter, the filter +itself, and the original process that reads the result and delivers it are all +run in parallel, like a shell pipeline. + +The filter can perform any transformations it likes, but of course should take +care not to break RFC 2822 syntax. Exim does not check the result, except to +test for a final newline when SMTP is in use. All messages transmitted over +SMTP must end with a newline, so Exim supplies one if it is missing. + +A transport filter can be used to provide content-scanning on a per-user basis +at delivery time if the only required effect of the scan is to modify the +message. For example, a content scan could insert a new header line containing +a spam score. This could be interpreted by a filter in the user's MUA. It is +not possible to discard a message at this stage. + +A problem might arise if the filter increases the size of a message that is +being sent down an SMTP connection. If the receiving SMTP server has indicated +support for the SIZE parameter, Exim will have sent the size of the message at +the start of the SMTP session. If what is actually sent is substantially more, +the server might reject the message. This can be worked round by setting the +size_addition option on the smtp transport, either to allow for additions to +the message, or to disable the use of SIZE altogether. + +The value of the transport_filter option is the command string for starting the +filter, which is run directly from Exim, not under a shell. The string is +parsed by Exim in the same way as a command string for the pipe transport: Exim +breaks it up into arguments and then expands each argument separately (see +section 29.3). Any kind of expansion failure causes delivery to be deferred. +The special argument $pipe_addresses is replaced by a number of arguments, one +for each address that applies to this delivery. (This isn't an ideal name for +this feature here, but as it was already implemented for the pipe transport, it +seemed sensible not to change it.) + +The expansion variables $host and $host_address are available when the +transport is a remote one. They contain the name and IP address of the host to +which the message is being sent. For example: + +transport_filter = /some/directory/transport-filter.pl \ + $host $host_address $sender_address $pipe_addresses + +Two problems arise if you want to use more complicated expansion items to +generate transport filter commands, both of which due to the fact that the +command is split up before expansion. + + * If an expansion item contains white space, you must quote it, so that it is + all part of the same command item. If the entire option setting is one such + expansion item, you have to take care what kind of quoting you use. For + example: + + transport_filter = '/bin/cmd${if eq{$host}{a.b.c}{1}{2}}' + + This runs the command /bin/cmd1 if the host name is a.b.c, and /bin/cmd2 + otherwise. If double quotes had been used, they would have been stripped by + Exim when it read the option's value. When the value is used, if the single + quotes were missing, the line would be split into two items, "/bin/cmd${if" + and "eq{$host}{a.b.c}{1}{2}", and an error would occur when Exim tried to + expand the first one. + + * Except for the special case of $pipe_addresses that is mentioned above, an + expansion cannot generate multiple arguments, or a command name followed by + arguments. Consider this example: + + transport_filter = ${lookup{$host}lsearch{/a/file}\ + {$value}{/bin/cat}} + + The result of the lookup is interpreted as the name of the command, even if + it contains white space. The simplest way round this is to use a shell: + + transport_filter = /bin/sh -c ${lookup{$host}lsearch{/a/file}\ + {$value}{/bin/cat}} + +The filter process is run under the same uid and gid as the normal delivery. +For remote deliveries this is the Exim uid/gid by default. The command should +normally yield a zero return code. Transport filters are not supposed to fail. +A non-zero code is taken to mean that the transport filter encountered some +serious problem. Delivery of the message is deferred; the message remains on +the queue and is tried again later. It is not possible to cause a message to be +bounced from a transport filter. + +If a transport filter is set on an autoreply transport, the original message is +passed through the filter as it is being copied into the newly generated +message, which happens if the return_message option is set. + ++---------------------------------------------------------------+ +|transport_filter_timeout|Use: transports|Type: time|Default: 5m| ++---------------------------------------------------------------+ + +When Exim is reading the output of a transport filter, it applies a timeout +that can be set by this option. Exceeding the timeout is normally treated as a +temporary delivery failure. However, if a transport filter is used with a pipe +transport, a timeout in the transport filter is treated in the same way as a +timeout in the pipe command itself. By default, a timeout is a hard error, but +if the pipe transport's timeout_defer option is set true, it becomes a +temporary error. + ++-----------------------------------------------------+ +|user|Use: transports|Type: string*|Default: Exim user| ++-----------------------------------------------------+ + +This option specifies the user under whose uid the delivery process is to be +run, overriding any uid that may have been set by the router. If the user is +given as a name, the uid is looked up from the password data, and the +associated group is taken as the value of the gid to be used if the group +option is not set. + +For deliveries that use local transports, a user and group are normally +specified explicitly or implicitly (for example, as a result of +check_local_user) by the router or transport. + +For remote transports, you should leave this option unset unless you really are +sure you know what you are doing. When a remote transport is running, it needs +to be able to access Exim's hints databases, because each host may have its own +retry data. + + + +=============================================================================== +25. ADDRESS BATCHING IN LOCAL TRANSPORTS + +The only remote transport (smtp) is normally configured to handle more than one +address at a time, so that when several addresses are routed to the same remote +host, just one copy of the message is sent. Local transports, however, normally +handle one address at a time. That is, a separate instance of the transport is +run for each address that is routed to the transport. A separate copy of the +message is delivered each time. + +In special cases, it may be desirable to handle several addresses at once in a +local transport, for example: + + * In an appendfile transport, when storing messages in files for later + delivery by some other means, a single copy of the message with multiple + recipients saves space. + + * In an lmtp transport, when delivering over "local SMTP" to some process, a + single copy saves time, and is the normal way LMTP is expected to work. + + * In a pipe transport, when passing the message to a scanner program or to + some other delivery mechanism such as UUCP, multiple recipients may be + acceptable. + +These three local transports all have the same options for controlling multiple +("batched") deliveries, namely batch_max and batch_id. To save repeating the +information for each transport, these options are described here. + +The batch_max option specifies the maximum number of addresses that can be +delivered together in a single run of the transport. Its default value is one +(no batching). When more than one address is routed to a transport that has a +batch_max value greater than one, the addresses are delivered in a batch (that +is, in a single run of the transport with multiple recipients), subject to +certain conditions: + + * If any of the transport's options contain a reference to $local_part, no + batching is possible. + + * If any of the transport's options contain a reference to $domain, only + addresses with the same domain are batched. + + * If batch_id is set, it is expanded for each address, and only those + addresses with the same expanded value are batched. This allows you to + specify customized batching conditions. Failure of the expansion for any + reason, including forced failure, disables batching, but it does not stop + the delivery from taking place. + + * Batched addresses must also have the same errors address (where to send + delivery errors), the same header additions and removals, the same user and + group for the transport, and if a host list is present, the first host must + be the same. + +In the case of the appendfile and pipe transports, batching applies both when +the file or pipe command is specified in the transport, and when it is +specified by a redirect router, but all the batched addresses must of course be +routed to the same file or pipe command. These two transports have an option +called use_bsmtp, which causes them to deliver the message in "batched SMTP" +format, with the envelope represented as SMTP commands. The check_string and +escape_string options are forced to the values + +check_string = "." +escape_string = ".." + +when batched SMTP is in use. A full description of the batch SMTP mechanism is +given in section 48.10. The lmtp transport does not have a use_bsmtp option, +because it always delivers using the SMTP protocol. + +If the generic envelope_to_add option is set for a batching transport, the +Envelope-to: header that is added to the message contains all the addresses +that are being processed together. If you are using a batching appendfile +transport without use_bsmtp, the only way to preserve the recipient addresses +is to set the envelope_to_add option. + +If you are using a pipe transport without BSMTP, and setting the transport's +command option, you can include $pipe_addresses as part of the command. This is +not a true variable; it is a bit of magic that causes each of the recipient +addresses to be inserted into the command as a separate argument. This provides +a way of accessing all the addresses that are being delivered in the batch. +Note: This is not possible for pipe commands that are specified by a redirect +router. + + + +=============================================================================== +26. THE APPENDFILE TRANSPORT + +The appendfile transport delivers a message by appending it to an existing +file, or by creating an entirely new file in a specified directory. Single +files to which messages are appended can be in the traditional Unix mailbox +format, or optionally in the MBX format supported by the Pine MUA and +University of Washington IMAP daemon, inter alia. When each message is being +delivered as a separate file, "maildir" format can optionally be used to give +added protection against failures that happen part-way through the delivery. A +third form of separate-file delivery known as "mailstore" is also supported. +For all file formats, Exim attempts to create as many levels of directory as +necessary, provided that create_directory is set. + +The code for the optional formats is not included in the Exim binary by +default. It is necessary to set SUPPORT_MBX, SUPPORT_MAILDIR and/or +SUPPORT_MAILSTORE in Local/Makefile to have the appropriate code included. + +Exim recognizes system quota errors, and generates an appropriate message. Exim +also supports its own quota control within the transport, for use when the +system facility is unavailable or cannot be used for some reason. + +If there is an error while appending to a file (for example, quota exceeded or +partition filled), Exim attempts to reset the file's length and last +modification time back to what they were before. If there is an error while +creating an entirely new file, the new file is removed. + +Before appending to a file, a number of security checks are made, and the file +is locked. A detailed description is given below, after the list of private +options. + +The appendfile transport is most commonly used for local deliveries to users' +mailboxes. However, it can also be used as a pseudo-remote transport for +putting messages into files for remote delivery by some means other than Exim. +"Batch SMTP" format is often used in this case (see the use_bsmtp option). + + +26.1 The file and directory options +----------------------------------- + +The file option specifies a single file, to which the message is appended; the +directory option specifies a directory, in which a new file containing the +message is created. Only one of these two options can be set, and for normal +deliveries to mailboxes, one of them must be set. + +However, appendfile is also used for delivering messages to files or +directories whose names (or parts of names) are obtained from alias, +forwarding, or filtering operations (for example, a save command in a user's +Exim filter). When such a transport is running, $local_part contains the local +part that was aliased or forwarded, and $address_file contains the name (or +partial name) of the file or directory generated by the redirection operation. +There are two cases: + + * If neither file nor directory is set, the redirection operation must + specify an absolute path (one that begins with "/"). This is the most + common case when users with local accounts use filtering to sort mail into + different folders. See for example, the address_file transport in the + default configuration. If the path ends with a slash, it is assumed to be + the name of a directory. A delivery to a directory can also be forced by + setting maildir_format or mailstore_format. + + * If file or directory is set for a delivery from a redirection, it is used + to determine the file or directory name for the delivery. Normally, the + contents of $address_file are used in some way in the string expansion. + +As an example of the second case, consider an environment where users do not +have home directories. They may be permitted to use Exim filter commands of the +form: + +save folder23 + +or Sieve filter commands of the form: + +require "fileinto"; +fileinto "folder23"; + +In this situation, the expansion of file or directory in the transport must +transform the relative path into an appropriate absolute filename. In the case +of Sieve filters, the name inbox must be handled. It is the name that is used +as a result of a "keep" action in the filter. This example shows one way of +handling this requirement: + +file = ${if eq{$address_file}{inbox} \ + {/var/mail/$local_part} \ + {${if eq{${substr_0_1:$address_file}}{/} \ + {$address_file} \ + {$home/mail/$address_file} \ + }} \ + } + +With this setting of file, inbox refers to the standard mailbox location, +absolute paths are used without change, and other folders are in the mail +directory within the home directory. + +Note 1: While processing an Exim filter, a relative path such as folder23 is +turned into an absolute path if a home directory is known to the router. In +particular, this is the case if check_local_user is set. If you want to prevent +this happening at routing time, you can set router_home_directory empty. This +forces the router to pass the relative path to the transport. + +Note 2: An absolute path in $address_file is not treated specially; the file or +directory option is still used if it is set. + + +26.2 Private options for appendfile +----------------------------------- + ++-------------------------------------------------------+ +|allow_fifo|Use: appendfile|Type: boolean|Default: false| ++-------------------------------------------------------+ + +Setting this option permits delivery to named pipes (FIFOs) as well as to +regular files. If no process is reading the named pipe at delivery time, the +delivery is deferred. + ++----------------------------------------------------------+ +|allow_symlink|Use: appendfile|Type: boolean|Default: false| ++----------------------------------------------------------+ + +By default, appendfile will not deliver if the path name for the file is that +of a symbolic link. Setting this option relaxes that constraint, but there are +security issues involved in the use of symbolic links. Be sure you know what +you are doing if you set this. Details of exactly what this option affects are +included in the discussion which follows this list of options. + ++-----------------------------------------------------+ +|batch_id|Use: appendfile|Type: string*|Default: unset| ++-----------------------------------------------------+ + +See the description of local delivery batching in chapter 25. However, batching +is automatically disabled for appendfile deliveries that happen as a result of +forwarding or aliasing or other redirection directly to a file. + ++--------------------------------------------------+ +|batch_max|Use: appendfile|Type: integer|Default: 1| ++--------------------------------------------------+ + +See the description of local delivery batching in chapter 25. + ++--------------------------------------------------------+ +|check_group|Use: appendfile|Type: boolean|Default: false| ++--------------------------------------------------------+ + +When this option is set, the group owner of the file defined by the file option +is checked to see that it is the same as the group under which the delivery +process is running. The default setting is false because the default file mode +is 0600, which means that the group is irrelevant. + ++-------------------------------------------------------+ +|check_owner|Use: appendfile|Type: boolean|Default: true| ++-------------------------------------------------------+ + +When this option is set, the owner of the file defined by the file option is +checked to ensure that it is the same as the user under which the delivery +process is running. + ++------------------------------------------------------------+ +|check_string|Use: appendfile|Type: string|Default: see below| ++------------------------------------------------------------+ + +As appendfile writes the message, the start of each line is tested for matching +check_string, and if it does, the initial matching characters are replaced by +the contents of escape_string. The value of check_string is a literal string, +not a regular expression, and the case of any letters it contains is +significant. + +If use_bsmtp is set the values of check_string and escape_string are forced to +"." and ".." respectively, and any settings in the configuration are ignored. +Otherwise, they default to "From " and ">From " when the file option is set, +and unset when any of the directory, maildir, or mailstore options are set. + +The default settings, along with message_prefix and message_suffix, are +suitable for traditional "BSD" mailboxes, where a line beginning with "From " +indicates the start of a new message. All four options need changing if another +format is used. For example, to deliver to mailboxes in MMDF format: + +check_string = "\1\1\1\1\n" +escape_string = "\1\1\1\1 \n" +message_prefix = "\1\1\1\1\n" +message_suffix = "\1\1\1\1\n" + ++------------------------------------------------------------+ +|create_directory|Use: appendfile|Type: boolean|Default: true| ++------------------------------------------------------------+ + +When this option is true, Exim attempts to create any missing superior +directories for the file that it is about to write. A created directory's mode +is given by the directory_mode option. + +The group ownership of a newly created directory is highly dependent on the +operating system (and possibly the file system) that is being used. For +example, in Solaris, if the parent directory has the setgid bit set, its group +is propagated to the child; if not, the currently set group is used. However, +in FreeBSD, the parent's group is always used. + ++----------------------------------------------------------+ +|create_file|Use: appendfile|Type: string|Default: anywhere| ++----------------------------------------------------------+ + +This option constrains the location of files and directories that are created +by this transport. It applies to files defined by the file option and +directories defined by the directory option. In the case of maildir delivery, +it applies to the top level directory, not the maildir directories beneath. + +The option must be set to one of the words "anywhere", "inhome", or +"belowhome". In the second and third cases, a home directory must have been set +for the transport. This option is not useful when an explicit filename is given +for normal mailbox deliveries. It is intended for the case when filenames are +generated from users' .forward files. These are usually handled by an +appendfile transport called address_file. See also file_must_exist. + ++------------------------------------------------------+ +|directory|Use: appendfile|Type: string*|Default: unset| ++------------------------------------------------------+ + +This option is mutually exclusive with the file option, but one of file or +directory must be set, unless the delivery is the direct result of a +redirection (see section 26.1). + +When directory is set, the string is expanded, and the message is delivered +into a new file or files in or below the given directory, instead of being +appended to a single mailbox file. A number of different formats are provided +(see maildir_format and mailstore_format), and see section 26.4 for further +details of this form of delivery. + ++---------------------------------------------------------------+ +|directory_file|Use: appendfile|Type: string*|Default: see below| ++---------------------------------------------------------------+ + +When directory is set, but neither maildir_format nor mailstore_format is set, +appendfile delivers each message into a file whose name is obtained by +expanding this string. The default value is: + +q${base62:$tod_epoch}-$inode + +This generates a unique name from the current time, in base 62 form, and the +inode of the file. The variable $inode is available only when expanding this +option. + ++----------------------------------------------------------------+ +|directory_mode|Use: appendfile|Type: octal integer|Default: 0700| ++----------------------------------------------------------------+ + +If appendfile creates any directories as a result of the create_directory +option, their mode is specified by this option. + ++-------------------------------------------------------------------+ +|escape_string|Use: appendfile|Type: string|Default: see description| ++-------------------------------------------------------------------+ + +See check_string above. + ++-------------------------------------------------+ +|file|Use: appendfile|Type: string*|Default: unset| ++-------------------------------------------------+ + +This option is mutually exclusive with the directory option, but one of file or +directory must be set, unless the delivery is the direct result of a +redirection (see section 26.1). The file option specifies a single file, to +which the message is appended. One or more of use_fcntl_lock, use_flock_lock, +or use_lockfile must be set with file. + +If you are using more than one host to deliver over NFS into the same +mailboxes, you should always use lock files. + +The string value is expanded for each delivery, and must yield an absolute +path. The most common settings of this option are variations on one of these +examples: + +file = /var/spool/mail/$local_part +file = /home/$local_part/inbox +file = $home/inbox + +In the first example, all deliveries are done into the same directory. If Exim +is configured to use lock files (see use_lockfile below) it must be able to +create a file in the directory, so the "sticky" bit must be turned on for +deliveries to be possible, or alternatively the group option can be used to run +the delivery under a group id which has write access to the directory. + ++-------------------------------------------------------+ +|file_format|Use: appendfile|Type: string|Default: unset| ++-------------------------------------------------------+ + +This option requests the transport to check the format of an existing file +before adding to it. The check consists of matching a specific string at the +start of the file. The value of the option consists of an even number of +colon-separated strings. The first of each pair is the test string, and the +second is the name of a transport. If the transport associated with a matched +string is not the current transport, control is passed over to the other +transport. For example, suppose the standard local_delivery transport has this +added to it: + +file_format = "From : local_delivery :\ + \1\1\1\1\n : local_mmdf_delivery" + +Mailboxes that begin with "From" are still handled by this transport, but if a +mailbox begins with four binary ones followed by a newline, control is passed +to a transport called local_mmdf_delivery, which presumably is configured to do +the delivery in MMDF format. If a mailbox does not exist or is empty, it is +assumed to match the current transport. If the start of a mailbox doesn't match +any string, or if the transport named for a given string is not defined, +delivery is deferred. + ++------------------------------------------------------------+ +|file_must_exist|Use: appendfile|Type: boolean|Default: false| ++------------------------------------------------------------+ + +If this option is true, the file specified by the file option must exist. A +temporary error occurs if it does not, causing delivery to be deferred. If this +option is false, the file is created if it does not exist. + ++---------------------------------------------------------+ +|lock_fcntl_timeout|Use: appendfile|Type: time|Default: 0s| ++---------------------------------------------------------+ + +By default, the appendfile transport uses non-blocking calls to fcntl() when +locking an open mailbox file. If the call fails, the delivery process sleeps +for lock_interval and tries again, up to lock_retries times. Non-blocking calls +are used so that the file is not kept open during the wait for the lock; the +reason for this is to make it as safe as possible for deliveries over NFS in +the case when processes might be accessing an NFS mailbox without using a lock +file. This should not be done, but misunderstandings and hence +misconfigurations are not unknown. + +On a busy system, however, the performance of a non-blocking lock approach is +not as good as using a blocking lock with a timeout. In this case, the waiting +is done inside the system call, and Exim's delivery process acquires the lock +and can proceed as soon as the previous lock holder releases it. + +If lock_fcntl_timeout is set to a non-zero time, blocking locks, with that +timeout, are used. There may still be some retrying: the maximum number of +retries is + +(lock_retries * lock_interval) / lock_fcntl_timeout + +rounded up to the next whole number. In other words, the total time during +which appendfile is trying to get a lock is roughly the same, unless +lock_fcntl_timeout is set very large. + +You should consider setting this option if you are getting a lot of delayed +local deliveries because of errors of the form + +failed to lock mailbox /some/file (fcntl) + ++---------------------------------------------------------+ +|lock_flock_timeout|Use: appendfile|Type: time|Default: 0s| ++---------------------------------------------------------+ + +This timeout applies to file locking when using flock() (see use_flock); the +timeout operates in a similar manner to lock_fcntl_timeout. + ++----------------------------------------------------+ +|lock_interval|Use: appendfile|Type: time|Default: 3s| ++----------------------------------------------------+ + +This specifies the time to wait between attempts to lock the file. See below +for details of locking. + ++------------------------------------------------------+ +|lock_retries|Use: appendfile|Type: integer|Default: 10| ++------------------------------------------------------+ + +This specifies the maximum number of attempts to lock the file. A value of zero +is treated as 1. See below for details of locking. + ++---------------------------------------------------------------+ +|lockfile_mode|Use: appendfile|Type: octal integer|Default: 0600| ++---------------------------------------------------------------+ + +This specifies the mode of the created lock file, when a lock file is being +used (see use_lockfile and use_mbx_lock). + ++--------------------------------------------------------+ +|lockfile_timeout|Use: appendfile|Type: time|Default: 30m| ++--------------------------------------------------------+ + +When a lock file is being used (see use_lockfile), if a lock file already +exists and is older than this value, it is assumed to have been left behind by +accident, and Exim attempts to remove it. + ++--------------------------------------------------------------+ +|mailbox_filecount|Use: appendfile|Type: string*|Default: unset| ++--------------------------------------------------------------+ + +If this option is set, it is expanded, and the result is taken as the current +number of files in the mailbox. It must be a decimal number, optionally +followed by K or M. This provides a way of obtaining this information from an +external source that maintains the data. + ++---------------------------------------------------------+ +|mailbox_size|Use: appendfile|Type: string*|Default: unset| ++---------------------------------------------------------+ + +If this option is set, it is expanded, and the result is taken as the current +size the mailbox. It must be a decimal number, optionally followed by K or M. +This provides a way of obtaining this information from an external source that +maintains the data. This is likely to be helpful for maildir deliveries where +it is computationally expensive to compute the size of a mailbox. + ++-----------------------------------------------------------+ +|maildir_format|Use: appendfile|Type: boolean|Default: false| ++-----------------------------------------------------------+ + +If this option is set with the directory option, the delivery is into a new +file, in the "maildir" format that is used by other mail software. When the +transport is activated directly from a redirect router (for example, the +address_file transport in the default configuration), setting maildir_format +causes the path received from the router to be treated as a directory, whether +or not it ends with "/". This option is available only if SUPPORT_MAILDIR is +present in Local/Makefile. See section 26.5 below for further details. + ++-----------------------------------------------------------------------------+ +|maildir_quota_directory_regex|Use: appendfile|Type: string|Default: See below| ++-----------------------------------------------------------------------------+ + +This option is relevant only when maildir_use_size_file is set. It defines a +regular expression for specifying directories, relative to the quota directory +(see quota_directory), that should be included in the quota calculation. The +default value is: + +maildir_quota_directory_regex = ^(?:cur|new|\..*)$ + +This includes the cur and new directories, and any maildir++ folders +(directories whose names begin with a dot). If you want to exclude the Trash +folder from the count (as some sites do), you need to change this setting to + +maildir_quota_directory_regex = ^(?:cur|new|\.(?!Trash).*)$ + +This uses a negative lookahead in the regular expression to exclude the +directory whose name is .Trash. When a directory is excluded from quota +calculations, quota processing is bypassed for any messages that are delivered +directly into that directory. + ++---------------------------------------------------------+ +|maildir_retries|Use: appendfile|Type: integer|Default: 10| ++---------------------------------------------------------+ + +This option specifies the number of times to retry when writing a file in +"maildir" format. See section 26.5 below. + ++--------------------------------------------------------+ +|maildir_tag|Use: appendfile|Type: string*|Default: unset| ++--------------------------------------------------------+ + +This option applies only to deliveries in maildir format, and is described in +section 26.5 below. + ++-------------------------------------------------------------------+ +|maildir_use_size_file|Use: appendfile*|Type: boolean|Default: false| ++-------------------------------------------------------------------+ + +The result of string expansion for this option must be a valid boolean value. +If it is true, it enables support for maildirsize files. Exim creates a +maildirsize file in a maildir if one does not exist, taking the quota from the +quota option of the transport. If quota is unset, the value is zero. See +maildir_quota_directory_regex above and section 26.5 below for further details. + ++----------------------------------------------------------------------+ +|maildirfolder_create_regex|Use: appendfile|Type: string|Default: unset| ++----------------------------------------------------------------------+ + +The value of this option is a regular expression. If it is unset, it has no +effect. Otherwise, before a maildir delivery takes place, the pattern is +matched against the name of the maildir directory, that is, the directory +containing the new and tmp subdirectories that will be used for the delivery. +If there is a match, Exim checks for the existence of a file called +maildirfolder in the directory, and creates it if it does not exist. See +section 26.5 for more details. + ++-------------------------------------------------------------+ +|mailstore_format|Use: appendfile|Type: boolean|Default: false| ++-------------------------------------------------------------+ + +If this option is set with the directory option, the delivery is into two new +files in "mailstore" format. The option is available only if SUPPORT_MAILSTORE +is present in Local/Makefile. See section 26.4 below for further details. + ++-------------------------------------------------------------+ +|mailstore_prefix|Use: appendfile|Type: string*|Default: unset| ++-------------------------------------------------------------+ + +This option applies only to deliveries in mailstore format, and is described in +section 26.4 below. + ++-------------------------------------------------------------+ +|mailstore_suffix|Use: appendfile|Type: string*|Default: unset| ++-------------------------------------------------------------+ + +This option applies only to deliveries in mailstore format, and is described in +section 26.4 below. + ++-------------------------------------------------------+ +|mbx_format|Use: appendfile|Type: boolean|Default: false| ++-------------------------------------------------------+ + +This option is available only if Exim has been compiled with SUPPORT_MBX set in +Local/Makefile. If mbx_format is set with the file option, the message is +appended to the mailbox file in MBX format instead of traditional Unix format. +This format is supported by Pine4 and its associated IMAP and POP daemons, by +means of the c-client library that they all use. + +Note: The message_prefix and message_suffix options are not automatically +changed by the use of mbx_format. They should normally be set empty when using +MBX format, so this option almost always appears in this combination: + +mbx_format = true +message_prefix = +message_suffix = + +If none of the locking options are mentioned in the configuration, use_mbx_lock +is assumed and the other locking options default to false. It is possible to +specify the other kinds of locking with mbx_format, but use_fcntl_lock and +use_mbx_lock are mutually exclusive. MBX locking interworks with c-client, +providing for shared access to the mailbox. It should not be used if any +program that does not use this form of locking is going to access the mailbox, +nor should it be used if the mailbox file is NFS mounted, because it works only +when the mailbox is accessed from a single host. + +If you set use_fcntl_lock with an MBX-format mailbox, you cannot use the +standard version of c-client, because as long as it has a mailbox open (this +means for the whole of a Pine or IMAP session), Exim will not be able to append +messages to it. + ++---------------------------------------------------------------+ +|message_prefix|Use: appendfile|Type: string*|Default: see below| ++---------------------------------------------------------------+ + +The string specified here is expanded and output at the start of every message. +The default is unset unless file is specified and use_bsmtp is not set, in +which case it is: + +message_prefix = "From ${if def:return_path{$return_path}\ + {MAILER-DAEMON}} $tod_bsdinbox\n" + +Note: If you set use_crlf true, you must change any occurrences of "\n" to "\r\ +n" in message_prefix. + ++---------------------------------------------------------------+ +|message_suffix|Use: appendfile|Type: string*|Default: see below| ++---------------------------------------------------------------+ + +The string specified here is expanded and output at the end of every message. +The default is unset unless file is specified and use_bsmtp is not set, in +which case it is a single newline character. The suffix can be suppressed by +setting + +message_suffix = + +Note: If you set use_crlf true, you must change any occurrences of "\n" to "\r\ +n" in message_suffix. + ++------------------------------------------------------+ +|mode|Use: appendfile|Type: octal integer|Default: 0600| ++------------------------------------------------------+ + +If the output file is created, it is given this mode. If it already exists and +has wider permissions, they are reduced to this mode. If it has narrower +permissions, an error occurs unless mode_fail_narrower is false. However, if +the delivery is the result of a save command in a filter file specifying a +particular mode, the mode of the output file is always forced to take that +value, and this option is ignored. + ++--------------------------------------------------------------+ +|mode_fail_narrower|Use: appendfile|Type: boolean|Default: true| ++--------------------------------------------------------------+ + +This option applies in the case when an existing mailbox file has a narrower +mode than that specified by the mode option. If mode_fail_narrower is true, the +delivery is deferred ("mailbox has the wrong mode"); otherwise Exim continues +with the delivery attempt, using the existing mode of the file. + ++----------------------------------------------------------+ +|notify_comsat|Use: appendfile|Type: boolean|Default: false| ++----------------------------------------------------------+ + +If this option is true, the comsat daemon is notified after every successful +delivery to a user mailbox. This is the daemon that notifies logged on users +about incoming mail. + ++--------------------------------------------------+ +|quota|Use: appendfile|Type: string*|Default: unset| ++--------------------------------------------------+ + +This option imposes a limit on the size of the file to which Exim is appending, +or to the total space used in the directory tree when the directory option is +set. In the latter case, computation of the space used is expensive, because +all the files in the directory (and any sub-directories) have to be +individually inspected and their sizes summed. (See quota_size_regex and +maildir_use_size_file for ways to avoid this in environments where users have +no shell access to their mailboxes). + +As there is no interlock against two simultaneous deliveries into a multi-file +mailbox, it is possible for the quota to be overrun in this case. For +single-file mailboxes, of course, an interlock is a necessity. + +A file's size is taken as its used value. Because of blocking effects, this may +be a lot less than the actual amount of disk space allocated to the file. If +the sizes of a number of files are being added up, the rounding effect can +become quite noticeable, especially on systems that have large block sizes. +Nevertheless, it seems best to stick to the used figure, because this is the +obvious value which users understand most easily. + +The value of the option is expanded, and must then be a numerical value +(decimal point allowed), optionally followed by one of the letters K, M, or G, +for kilobytes, megabytes, or gigabytes, optionally followed by a slash and +further option modifiers. If Exim is running on a system with large file +support (Linux and FreeBSD have this), mailboxes larger than 2G can be handled. + +The option modifier no_check can be used to force delivery even if the over +quota condition is met. The quota gets updated as usual. + +Note: A value of zero is interpreted as "no quota". + +The expansion happens while Exim is running as root, before it changes uid for +the delivery. This means that files that are inaccessible to the end user can +be used to hold quota values that are looked up in the expansion. When delivery +fails because this quota is exceeded, the handling of the error is as for +system quota failures. + +By default, Exim's quota checking mimics system quotas, and restricts the +mailbox to the specified maximum size, though the value is not accurate to the +last byte, owing to separator lines and additional headers that may get added +during message delivery. When a mailbox is nearly full, large messages may get +refused even though small ones are accepted, because the size of the current +message is added to the quota when the check is made. This behaviour can be +changed by setting quota_is_inclusive false. When this is done, the check for +exceeding the quota does not include the current message. Thus, deliveries +continue until the quota has been exceeded; thereafter, no further messages are +delivered. See also quota_warn_threshold. + ++------------------------------------------------------------+ +|quota_directory|Use: appendfile|Type: string*|Default: unset| ++------------------------------------------------------------+ + +This option defines the directory to check for quota purposes when delivering +into individual files. The default is the delivery directory, or, if a file +called maildirfolder exists in a maildir directory, the parent of the delivery +directory. + ++--------------------------------------------------------+ +|quota_filecount|Use: appendfile|Type: string*|Default: 0| ++--------------------------------------------------------+ + +This option applies when the directory option is set. It limits the total +number of files in the directory (compare the inode limit in system quotas). It +can only be used if quota is also set. The value is expanded; an expansion +failure causes delivery to be deferred. A value of zero is interpreted as "no +quota". + +The option modifier no_check can be used to force delivery even if the over +quota condition is met. The quota gets updated as usual. + ++--------------------------------------------------------------+ +|quota_is_inclusive|Use: appendfile|Type: boolean|Default: true| ++--------------------------------------------------------------+ + +See quota above. + ++------------------------------------------------------------+ +|quota_size_regex|Use: appendfile|Type: string|Default: unset| ++------------------------------------------------------------+ + +This option applies when one of the delivery modes that writes a separate file +for each message is being used. When Exim wants to find the size of one of +these files in order to test the quota, it first checks quota_size_regex. If +this is set to a regular expression that matches the filename, and it captures +one string, that string is interpreted as a representation of the file's size. +The value of quota_size_regex is not expanded. + +This feature is useful only when users have no shell access to their mailboxes +- otherwise they could defeat the quota simply by renaming the files. This +facility can be used with maildir deliveries, by setting maildir_tag to add the +file length to the filename. For example: + +maildir_tag = ,S=$message_size +quota_size_regex = ,S=(\d+) + +An alternative to $message_size is $message_linecount, which contains the +number of lines in the message. + +The regular expression should not assume that the length is at the end of the +filename (even though maildir_tag puts it there) because maildir MUAs sometimes +add other information onto the ends of message filenames. + +Section 26.7 contains further information. + ++-------------------------------------------------------------------+ +|quota_warn_message|Use: appendfile|Type: string*|Default: see below| ++-------------------------------------------------------------------+ + +See below for the use of this option. If it is not set when +quota_warn_threshold is set, it defaults to + +quota_warn_message = "\ + To: $local_part@$domain\n\ + Subject: Your mailbox\n\n\ + This message is automatically created \ + by mail delivery software.\n\n\ + The size of your mailbox has exceeded \ + a warning threshold that is\n\ + set by the system administrator.\n" + ++-------------------------------------------------------------+ +|quota_warn_threshold|Use: appendfile|Type: string*|Default: 0| ++-------------------------------------------------------------+ + +This option is expanded in the same way as quota (see above). If the resulting +value is greater than zero, and delivery of the message causes the size of the +file or total space in the directory tree to cross the given threshold, a +warning message is sent. If quota is also set, the threshold may be specified +as a percentage of it by following the value with a percent sign. For example: + +quota = 10M +quota_warn_threshold = 75% + +If quota is not set, a setting of quota_warn_threshold that ends with a percent +sign is ignored. + +The warning message itself is specified by the quota_warn_message option, and +it must start with a To: header line containing the recipient(s) of the warning +message. These do not necessarily have to include the recipient(s) of the +original message. A Subject: line should also normally be supplied. You can +include any other header lines that you want. If you do not include a From: +line, the default is: + +From: Mail Delivery System <mailer-daemon@$qualify_domain_sender> + +If you supply a Reply-To: line, it overrides the global errors_reply_to option. + +The quota option does not have to be set in order to use this option; they are +independent of one another except when the threshold is specified as a +percentage. + ++------------------------------------------------------+ +|use_bsmtp|Use: appendfile|Type: boolean|Default: false| ++------------------------------------------------------+ + +If this option is set true, appendfile writes messages in "batch SMTP" format, +with the envelope sender and recipient(s) included as SMTP commands. If you +want to include a leading HELO command with such messages, you can do so by +setting the message_prefix option. See section 48.10 for details of batch SMTP. + ++-----------------------------------------------------+ +|use_crlf|Use: appendfile|Type: boolean|Default: false| ++-----------------------------------------------------+ + +This option causes lines to be terminated with the two-character CRLF sequence +(carriage return, linefeed) instead of just a linefeed character. In the case +of batched SMTP, the byte sequence written to the file is then an exact image +of what would be sent down a real SMTP connection. + +Note: The contents of the message_prefix and message_suffix options (which are +used to supply the traditional "From " and blank line separators in +Berkeley-style mailboxes) are written verbatim, so must contain their own +carriage return characters if these are needed. In cases where these options +have non-empty defaults, the values end with a single linefeed, so they must be +changed to end with "\r\n" if use_crlf is set. + ++---------------------------------------------------------------+ +|use_fcntl_lock|Use: appendfile|Type: boolean|Default: see below| ++---------------------------------------------------------------+ + +This option controls the use of the fcntl() function to lock a file for +exclusive use when a message is being appended. It is set by default unless +use_flock_lock is set. Otherwise, it should be turned off only if you know that +all your MUAs use lock file locking. When both use_fcntl_lock and +use_flock_lock are unset, use_lockfile must be set. + ++-----------------------------------------------------------+ +|use_flock_lock|Use: appendfile|Type: boolean|Default: false| ++-----------------------------------------------------------+ + +This option is provided to support the use of flock() for file locking, for the +few situations where it is needed. Most modern operating systems support fcntl +() and lockf() locking, and these two functions interwork with each other. Exim +uses fcntl() locking by default. + +This option is required only if you are using an operating system where flock() +is used by programs that access mailboxes (typically MUAs), and where flock() +does not correctly interwork with fcntl(). You can use both fcntl() and flock() +locking simultaneously if you want. + +Not all operating systems provide flock(). Some versions of Solaris do not have +it (and some, I think, provide a not quite right version built on top of lockf +()). If the OS does not have flock(), Exim will be built without the ability to +use it, and any attempt to do so will cause a configuration error. + +Warning: flock() locks do not work on NFS files (unless flock() is just being +mapped onto fcntl() by the OS). + ++-------------------------------------------------------------+ +|use_lockfile|Use: appendfile|Type: boolean|Default: see below| ++-------------------------------------------------------------+ + +If this option is turned off, Exim does not attempt to create a lock file when +appending to a mailbox file. In this situation, the only locking is by fcntl(). +You should only turn use_lockfile off if you are absolutely sure that every MUA +that is ever going to look at your users' mailboxes uses fcntl() rather than a +lock file, and even then only when you are not delivering over NFS from more +than one host. + +In order to append to an NFS file safely from more than one host, it is +necessary to take out a lock before opening the file, and the lock file +achieves this. Otherwise, even with fcntl() locking, there is a risk of file +corruption. + +The use_lockfile option is set by default unless use_mbx_lock is set. It is not +possible to turn both use_lockfile and use_fcntl_lock off, except when +mbx_format is set. + ++-------------------------------------------------------------+ +|use_mbx_lock|Use: appendfile|Type: boolean|Default: see below| ++-------------------------------------------------------------+ + +This option is available only if Exim has been compiled with SUPPORT_MBX set in +Local/Makefile. Setting the option specifies that special MBX locking rules be +used. It is set by default if mbx_format is set and none of the locking options +are mentioned in the configuration. The locking rules are the same as are used +by the c-client library that underlies Pine and the IMAP4 and POP daemons that +come with it (see the discussion below). The rules allow for shared access to +the mailbox. However, this kind of locking does not work when the mailbox is +NFS mounted. + +You can set use_mbx_lock with either (or both) of use_fcntl_lock and +use_flock_lock to control what kind of locking is used in implementing the MBX +locking rules. The default is to use fcntl() if use_mbx_lock is set without +use_fcntl_lock or use_flock_lock. + + +26.3 Operational details for appending +-------------------------------------- + +Before appending to a file, the following preparations are made: + + * If the name of the file is /dev/null, no action is taken, and a success + return is given. + + * If any directories on the file's path are missing, Exim creates them if the + create_directory option is set. A created directory's mode is given by the + directory_mode option. + + * If file_format is set, the format of an existing file is checked. If this + indicates that a different transport should be used, control is passed to + that transport. + + * If use_lockfile is set, a lock file is built in a way that will work + reliably over NFS, as follows: + + 1. Create a "hitching post" file whose name is that of the lock file with + the current time, primary host name, and process id added, by opening + for writing as a new file. If this fails with an access error, delivery + is deferred. + + 2. Close the hitching post file, and hard link it to the lock filename. + + 3. If the call to link() succeeds, creation of the lock file has + succeeded. Unlink the hitching post name. + + 4. Otherwise, use stat() to get information about the hitching post file, + and then unlink hitching post name. If the number of links is exactly + two, creation of the lock file succeeded but something (for example, an + NFS server crash and restart) caused this fact not to be communicated + to the link() call. + + 5. If creation of the lock file failed, wait for lock_interval and try + again, up to lock_retries times. However, since any program that writes + to a mailbox should complete its task very quickly, it is reasonable to + time out old lock files that are normally the result of user agent and + system crashes. If an existing lock file is older than lockfile_timeout + Exim attempts to unlink it before trying again. + + * A call is made to lstat() to discover whether the main file exists, and if + so, what its characteristics are. If lstat() fails for any reason other + than non-existence, delivery is deferred. + + * If the file does exist and is a symbolic link, delivery is deferred, unless + the allow_symlink option is set, in which case the ownership of the link is + checked, and then stat() is called to find out about the real file, which + is then subjected to the checks below. The check on the top-level link + ownership prevents one user creating a link for another's mailbox in a + sticky directory, though allowing symbolic links in this case is definitely + not a good idea. If there is a chain of symbolic links, the intermediate + ones are not checked. + + * If the file already exists but is not a regular file, or if the file's + owner and group (if the group is being checked - see check_group above) are + different from the user and group under which the delivery is running, + delivery is deferred. + + * If the file's permissions are more generous than specified, they are + reduced. If they are insufficient, delivery is deferred, unless + mode_fail_narrower is set false, in which case the delivery is tried using + the existing permissions. + + * The file's inode number is saved, and the file is then opened for + appending. If this fails because the file has vanished, appendfile behaves + as if it hadn't existed (see below). For any other failures, delivery is + deferred. + + * If the file is opened successfully, check that the inode number hasn't + changed, that it is still a regular file, and that the owner and + permissions have not changed. If anything is wrong, defer delivery and + freeze the message. + + * If the file did not exist originally, defer delivery if the file_must_exist + option is set. Otherwise, check that the file is being created in a + permitted directory if the create_file option is set (deferring on + failure), and then open for writing as a new file, with the O_EXCL and + O_CREAT options, except when dealing with a symbolic link (the + allow_symlink option must be set). In this case, which can happen if the + link points to a non-existent file, the file is opened for writing using + O_CREAT but not O_EXCL, because that prevents link following. + + * If opening fails because the file exists, obey the tests given above for + existing files. However, to avoid looping in a situation where the file is + being continuously created and destroyed, the exists/not-exists loop is + broken after 10 repetitions, and the message is then frozen. + + * If opening fails with any other error, defer delivery. + + * Once the file is open, unless both use_fcntl_lock and use_flock_lock are + false, it is locked using fcntl() or flock() or both. If use_mbx_lock is + false, an exclusive lock is requested in each case. However, if + use_mbx_lock is true, Exim takes out a shared lock on the open file, and an + exclusive lock on the file whose name is + + /tmp/.<device-number>.<inode-number> + + using the device and inode numbers of the open mailbox file, in accordance + with the MBX locking rules. This file is created with a mode that is + specified by the lockfile_mode option. + + If Exim fails to lock the file, there are two possible courses of action, + depending on the value of the locking timeout. This is obtained from + lock_fcntl_timeout or lock_flock_timeout, as appropriate. + + If the timeout value is zero, the file is closed, Exim waits for + lock_interval, and then goes back and re-opens the file as above and tries + to lock it again. This happens up to lock_retries times, after which the + delivery is deferred. + + If the timeout has a value greater than zero, blocking calls to fcntl() or + flock() are used (with the given timeout), so there has already been some + waiting involved by the time locking fails. Nevertheless, Exim does not + give up immediately. It retries up to + + (lock_retries * lock_interval) / <timeout> + + times (rounded up). + +At the end of delivery, Exim closes the file (which releases the fcntl() and/or +flock() locks) and then deletes the lock file if one was created. + + +26.4 Operational details for delivery to a new file +--------------------------------------------------- + +When the directory option is set instead of file, each message is delivered +into a newly-created file or set of files. When appendfile is activated +directly from a redirect router, neither file nor directory is normally set, +because the path for delivery is supplied by the router. (See for example, the +address_file transport in the default configuration.) In this case, delivery is +to a new file if either the path name ends in "/", or the maildir_format or +mailstore_format option is set. + +No locking is required while writing the message to a new file, so the various +locking options of the transport are ignored. The "From" line that by default +separates messages in a single file is not normally needed, nor is the escaping +of message lines that start with "From", and there is no need to ensure a +newline at the end of each message. Consequently, the default values for +check_string, message_prefix, and message_suffix are all unset when any of +directory, maildir_format, or mailstore_format is set. + +If Exim is required to check a quota setting, it adds up the sizes of all the +files in the delivery directory by default. However, you can specify a +different directory by setting quota_directory. Also, for maildir deliveries +(see below) the maildirfolder convention is honoured. + +There are three different ways in which delivery to individual files can be +done, controlled by the settings of the maildir_format and mailstore_format +options. Note that code to support maildir or mailstore formats is not included +in the binary unless SUPPORT_MAILDIR or SUPPORT_MAILSTORE, respectively, is set +in Local/Makefile. + +In all three cases an attempt is made to create the directory and any necessary +sub-directories if they do not exist, provided that the create_directory option +is set (the default). The location of a created directory can be constrained by +setting create_file. A created directory's mode is given by the directory_mode +option. If creation fails, or if the create_directory option is not set when +creation is required, delivery is deferred. + + +26.5 Maildir delivery +--------------------- + +If the maildir_format option is true, Exim delivers each message by writing it +to a file whose name is tmp/<stime>.H<mtime>P<pid>.<host> in the directory that +is defined by the directory option (the "delivery directory"). If the delivery +is successful, the file is renamed into the new subdirectory. + +In the filename, <stime> is the current time of day in seconds, and <mtime> is +the microsecond fraction of the time. After a maildir delivery, Exim checks +that the time-of-day clock has moved on by at least one microsecond before +terminating the delivery process. This guarantees uniqueness for the filename. +However, as a precaution, Exim calls stat() for the file before opening it. If +any response other than ENOENT (does not exist) is given, Exim waits 2 seconds +and tries again, up to maildir_retries times. + +Before Exim carries out a maildir delivery, it ensures that subdirectories +called new, cur, and tmp exist in the delivery directory. If they do not exist, +Exim tries to create them and any superior directories in their path, subject +to the create_directory and create_file options. If the +maildirfolder_create_regex option is set, and the regular expression it +contains matches the delivery directory, Exim also ensures that a file called +maildirfolder exists in the delivery directory. If a missing directory or +maildirfolder file cannot be created, delivery is deferred. + +These features make it possible to use Exim to create all the necessary files +and directories in a maildir mailbox, including subdirectories for maildir++ +folders. Consider this example: + +maildir_format = true +directory = /var/mail/$local_part\ + ${if eq{$local_part_suffix}{}{}\ + {/.${substr_1:$local_part_suffix}}} +maildirfolder_create_regex = /\.[^/]+$ + +If $local_part_suffix is empty (there was no suffix for the local part), +delivery is into a toplevel maildir with a name like /var/mail/pimbo (for the +user called pimbo). The pattern in maildirfolder_create_regex does not match +this name, so Exim will not look for or create the file /var/mail/pimbo/ +maildirfolder, though it will create /var/mail/pimbo/{cur,new,tmp} if +necessary. + +However, if $local_part_suffix contains "-eximusers" (for example), delivery is +into the maildir++ folder /var/mail/pimbo/.eximusers, which does match +maildirfolder_create_regex. In this case, Exim will create /var/mail/pimbo +/.eximusers/maildirfolder as well as the three maildir directories /var/mail/ +pimbo/.eximusers/{cur,new,tmp}. + +Warning: Take care when setting maildirfolder_create_regex that it does not +inadvertently match the toplevel maildir directory, because a maildirfolder +file at top level would completely break quota calculations. + +If Exim is required to check a quota setting before a maildir delivery, and +quota_directory is not set, it looks for a file called maildirfolder in the +maildir directory (alongside new, cur, tmp). If this exists, Exim assumes the +directory is a maildir++ folder directory, which is one level down from the +user's top level mailbox directory. This causes it to start at the parent +directory instead of the current directory when calculating the amount of space +used. + +One problem with delivering into a multi-file mailbox is that it is +computationally expensive to compute the size of the mailbox for quota +checking. Various approaches have been taken to reduce the amount of work +needed. The next two sections describe two of them. A third alternative is to +use some external process for maintaining the size data, and use the expansion +of the mailbox_size option as a way of importing it into Exim. + + +26.6 Using tags to record message sizes +--------------------------------------- + +If maildir_tag is set, the string is expanded for each delivery. When the +maildir file is renamed into the new sub-directory, the tag is added to its +name. However, if adding the tag takes the length of the name to the point +where the test stat() call fails with ENAMETOOLONG, the tag is dropped and the +maildir file is created with no tag. + +Tags can be used to encode the size of files in their names; see +quota_size_regex above for an example. The expansion of maildir_tag happens +after the message has been written. The value of the $message_size variable is +set to the number of bytes actually written. If the expansion is forced to +fail, the tag is ignored, but a non-forced failure causes delivery to be +deferred. The expanded tag may contain any printing characters except "/". +Non-printing characters in the string are ignored; if the resulting string is +empty, it is ignored. If it starts with an alphanumeric character, a leading +colon is inserted; this default has not proven to be the path that popular +maildir implementations have chosen (but changing it in Exim would break +backwards compatibility). + +For one common implementation, you might set: + +maildir_tag = ,S=${message_size} + +but you should check the documentation of the other software to be sure. + +It is advisable to also set quota_size_regex when setting maildir_tag as this +allows Exim to extract the size from your tag, instead of having to stat() each +message file. + + +26.7 Using a maildirsize file +----------------------------- + +If maildir_use_size_file is true, Exim implements the maildir++ rules for +storing quota and message size information in a file called maildirsize within +the toplevel maildir directory. If this file does not exist, Exim creates it, +setting the quota from the quota option of the transport. If the maildir +directory itself does not exist, it is created before any attempt to write a +maildirsize file. + +The maildirsize file is used to hold information about the sizes of messages in +the maildir, thus speeding up quota calculations. The quota value in the file +is just a cache; if the quota is changed in the transport, the new value +overrides the cached value when the next message is delivered. The cache is +maintained for the benefit of other programs that access the maildir and need +to know the quota. + +If the quota option in the transport is unset or zero, the maildirsize file is +maintained (with a zero quota setting), but no quota is imposed. + +A regular expression is available for controlling which directories in the +maildir participate in quota calculations when a maildirsizefile is in use. See +the description of the maildir_quota_directory_regex option above for details. + + +26.8 Mailstore delivery +----------------------- + +If the mailstore_format option is true, each message is written as two files in +the given directory. A unique base name is constructed from the message id and +the current delivery process, and the files that are written use this base name +plus the suffixes .env and .msg. The .env file contains the message's envelope, +and the .msg file contains the message itself. The base name is placed in the +variable $mailstore_basename. + +During delivery, the envelope is first written to a file with the suffix .tmp. +The .msg file is then written, and when it is complete, the .tmp file is +renamed as the .env file. Programs that access messages in mailstore format +should wait for the presence of both a .msg and a .env file before accessing +either of them. An alternative approach is to wait for the absence of a .tmp +file. + +The envelope file starts with any text defined by the mailstore_prefix option, +expanded and terminated by a newline if there isn't one. Then follows the +sender address on one line, then all the recipient addresses, one per line. +There can be more than one recipient only if the batch_max option is set +greater than one. Finally, mailstore_suffix is expanded and the result appended +to the file, followed by a newline if it does not end with one. + +If expansion of mailstore_prefix or mailstore_suffix ends with a forced +failure, it is ignored. Other expansion errors are treated as serious +configuration errors, and delivery is deferred. The variable +$mailstore_basename is available for use during these expansions. + + +26.9 Non-special new file delivery +---------------------------------- + +If neither maildir_format nor mailstore_format is set, a single new file is +created directly in the named directory. For example, when delivering messages +into files in batched SMTP format for later delivery to some host (see section +48.10), a setting such as + +directory = /var/bsmtp/$host + +might be used. A message is written to a file with a temporary name, which is +then renamed when the delivery is complete. The final name is obtained by +expanding the contents of the directory_file option. + + + +=============================================================================== +27. THE AUTOREPLY TRANSPORT + +The autoreply transport is not a true transport in that it does not cause the +message to be transmitted. Instead, it generates a new mail message as an +automatic reply to the incoming message. References: and Auto-Submitted: header +lines are included. These are constructed according to the rules in RFCs 2822 +and 3834, respectively. + +If the router that passes the message to this transport does not have the +unseen option set, the original message (for the current recipient) is not +delivered anywhere. However, when the unseen option is set on the router that +passes the message to this transport, routing of the address continues, so +another router can set up a normal message delivery. + +The autoreply transport is usually run as the result of mail filtering, a +"vacation" message being the standard example. However, it can also be run +directly from a router like any other transport. To reduce the possibility of +message cascades, messages created by the autoreply transport always have empty +envelope sender addresses, like bounce messages. + +The parameters of the message to be sent can be specified in the configuration +by options described below. However, these are used only when the address +passed to the transport does not contain its own reply information. When the +transport is run as a consequence of a mail or vacation command in a filter +file, the parameters of the message are supplied by the filter, and passed with +the address. The transport's options that define the message are then ignored +(so they are not usually set in this case). The message is specified entirely +by the filter or by the transport; it is never built from a mixture of options. +However, the file_optional, mode, and return_message options apply in all +cases. + +Autoreply is implemented as a local transport. When used as a result of a +command in a user's filter file, autoreply normally runs under the uid and gid +of the user, and with appropriate current and home directories (see chapter 23 +). + +There is a subtle difference between routing a message to a pipe transport that +generates some text to be returned to the sender, and routing it to an +autoreply transport. This difference is noticeable only if more than one +address from the same message is so handled. In the case of a pipe, the +separate outputs from the different addresses are gathered up and returned to +the sender in a single message, whereas if autoreply is used, a separate +message is generated for each address that is passed to it. + +Non-printing characters are not permitted in the header lines generated for the +message that autoreply creates, with the exception of newlines that are +immediately followed by white space. If any non-printing characters are found, +the transport defers. Whether characters with the top bit set count as printing +characters or not is controlled by the print_topbitchars global option. + +If any of the generic options for manipulating headers (for example, +headers_add) are set on an autoreply transport, they apply to the copy of the +original message that is included in the generated message when return_message +is set. They do not apply to the generated message itself. + +If the autoreply transport receives return code 2 from Exim when it submits the +message, indicating that there were no recipients, it does not treat this as an +error. This means that autoreplies sent to $sender_address when this is empty +(because the incoming message is a bounce message) do not cause problems. They +are just discarded. + + +27.1 Private options for autoreply +---------------------------------- + ++-----------------------------------------------+ +|bcc|Use: autoreply|Type: string*|Default: unset| ++-----------------------------------------------+ + +This specifies the addresses that are to receive "blind carbon copies" of the +message when the message is specified by the transport. + ++----------------------------------------------+ +|cc|Use: autoreply|Type: string*|Default: unset| ++----------------------------------------------+ + +This specifies recipients of the message and the contents of the Cc: header +when the message is specified by the transport. + ++------------------------------------------------+ +|file|Use: autoreply|Type: string*|Default: unset| ++------------------------------------------------+ + +The contents of the file are sent as the body of the message when the message +is specified by the transport. If both file and text are set, the text string +comes first. + ++-------------------------------------------------------+ +|file_expand|Use: autoreply|Type: boolean|Default: false| ++-------------------------------------------------------+ + +If this is set, the contents of the file named by the file option are subjected +to string expansion as they are added to the message. + ++---------------------------------------------------------+ +|file_optional|Use: autoreply|Type: boolean|Default: false| ++---------------------------------------------------------+ + +If this option is true, no error is generated if the file named by the file +option or passed with the address does not exist or cannot be read. + ++------------------------------------------------+ +|from|Use: autoreply|Type: string*|Default: unset| ++------------------------------------------------+ + +This specifies the contents of the From: header when the message is specified +by the transport. + ++---------------------------------------------------+ +|headers|Use: autoreply|Type: string*|Default: unset| ++---------------------------------------------------+ + +This specifies additional RFC 2822 headers that are to be added to the message +when the message is specified by the transport. Several can be given by using " +\n" to separate them. There is no check on the format. + ++-----------------------------------------------+ +|log|Use: autoreply|Type: string*|Default: unset| ++-----------------------------------------------+ + +This option names a file in which a record of every message sent is logged when +the message is specified by the transport. + ++-----------------------------------------------------+ +|mode|Use: autoreply|Type: octal integer|Default: 0600| ++-----------------------------------------------------+ + +If either the log file or the "once" file has to be created, this mode is used. + ++------------------------------------------------------------+ +|never_mail|Use: autoreply|Type: address list*|Default: unset| ++------------------------------------------------------------+ + +If any run of the transport creates a message with a recipient that matches any +item in the list, that recipient is quietly discarded. If all recipients are +discarded, no message is created. This applies both when the recipients are +generated by a filter and when they are specified in the transport. + ++------------------------------------------------+ +|once|Use: autoreply|Type: string*|Default: unset| ++------------------------------------------------+ + +This option names a file or DBM database in which a record of each To: +recipient is kept when the message is specified by the transport. Note: This +does not apply to Cc: or Bcc: recipients. + +If once is unset, or is set to an empty string, the message is always sent. By +default, if once is set to a non-empty filename, the message is not sent if a +potential recipient is already listed in the database. However, if the +once_repeat option specifies a time greater than zero, the message is sent if +that much time has elapsed since a message was last sent to this recipient. A +setting of zero time for once_repeat (the default) prevents a message from +being sent a second time - in this case, zero means infinity. + +If once_file_size is zero, a DBM database is used to remember recipients, and +it is allowed to grow as large as necessary. If once_file_size is set greater +than zero, it changes the way Exim implements the once option. Instead of using +a DBM file to record every recipient it sends to, it uses a regular file, whose +size will never get larger than the given value. + +In the file, Exim keeps a linear list of recipient addresses and the times at +which they were sent messages. If the file is full when a new address needs to +be added, the oldest address is dropped. If once_repeat is not set, this means +that a given recipient may receive multiple messages, but at unpredictable +intervals that depend on the rate of turnover of addresses in the file. If +once_repeat is set, it specifies a maximum time between repeats. + ++------------------------------------------------------+ +|once_file_size|Use: autoreply|Type: integer|Default: 0| ++------------------------------------------------------+ + +See once above. + ++--------------------------------------------------+ +|once_repeat|Use: autoreply|Type: time*|Default: 0s| ++--------------------------------------------------+ + +See once above. After expansion, the value of this option must be a valid time +value. + ++----------------------------------------------------+ +|reply_to|Use: autoreply|Type: string*|Default: unset| ++----------------------------------------------------+ + +This specifies the contents of the Reply-To: header when the message is +specified by the transport. + ++----------------------------------------------------------+ +|return_message|Use: autoreply|Type: boolean|Default: false| ++----------------------------------------------------------+ + +If this is set, a copy of the original message is returned with the new +message, subject to the maximum size set in the return_size_limit global +configuration option. + ++---------------------------------------------------+ +|subject|Use: autoreply|Type: string*|Default: unset| ++---------------------------------------------------+ + +This specifies the contents of the Subject: header when the message is +specified by the transport. It is tempting to quote the original subject in +automatic responses. For example: + +subject = Re: $h_subject: + +There is a danger in doing this, however. It may allow a third party to +subscribe your users to an opt-in mailing list, provided that the list accepts +bounce messages as subscription confirmations. Well-managed lists require a +non-bounce message to confirm a subscription, so the danger is relatively +small. + ++------------------------------------------------+ +|text|Use: autoreply|Type: string*|Default: unset| ++------------------------------------------------+ + +This specifies a single string to be used as the body of the message when the +message is specified by the transport. If both text and file are set, the text +comes first. + ++----------------------------------------------+ +|to|Use: autoreply|Type: string*|Default: unset| ++----------------------------------------------+ + +This specifies recipients of the message and the contents of the To: header +when the message is specified by the transport. + + + +=============================================================================== +28. THE LMTP TRANSPORT + +The lmtp transport runs the LMTP protocol (RFC 2033) over a pipe to a specified +command or by interacting with a Unix domain socket. This transport is +something of a cross between the pipe and smtp transports. Exim also has +support for using LMTP over TCP/IP; this is implemented as an option for the +smtp transport. Because LMTP is expected to be of minority interest, the +default build-time configure in src/EDITME has it commented out. You need to +ensure that + +TRANSPORT_LMTP=yes + +is present in your Local/Makefile in order to have the lmtp transport included +in the Exim binary. The private options of the lmtp transport are as follows: + ++-----------------------------------------------+ +|batch_id|Use: lmtp|Type: string*|Default: unset| ++-----------------------------------------------+ + +See the description of local delivery batching in chapter 25. + ++--------------------------------------------+ +|batch_max|Use: lmtp|Type: integer|Default: 1| ++--------------------------------------------+ + +This limits the number of addresses that can be handled in a single delivery. +Most LMTP servers can handle several addresses at once, so it is normally a +good idea to increase this value. See the description of local delivery +batching in chapter 25. + ++----------------------------------------------+ +|command|Use: lmtp|Type: string*|Default: unset| ++----------------------------------------------+ + +This option must be set if socket is not set. The string is a command which is +run in a separate process. It is split up into a command name and list of +arguments, each of which is separately expanded (so expansion cannot change the +number of arguments). The command is run directly, not via a shell. The message +is passed to the new process using the standard input and output to operate the +LMTP protocol. + ++---------------------------------------------------+ +|ignore_quota|Use: lmtp|Type: boolean|Default: false| ++---------------------------------------------------+ + +If this option is set true, the string "IGNOREQUOTA" is added to RCPT commands, +provided that the LMTP server has advertised support for IGNOREQUOTA in its +response to the LHLO command. + ++---------------------------------------------+ +|socket|Use: lmtp|Type: string*|Default: unset| ++---------------------------------------------+ + +This option must be set if command is not set. The result of expansion must be +the name of a Unix domain socket. The transport connects to the socket and +delivers the message to it using the LMTP protocol. + ++----------------------------------------+ +|timeout|Use: lmtp|Type: time|Default: 5m| ++----------------------------------------+ + +The transport is aborted if the created process or Unix domain socket does not +respond to LMTP commands or message input within this timeout. Delivery is +deferred, and will be tried again later. Here is an example of a typical LMTP +transport: + +lmtp: + driver = lmtp + command = /some/local/lmtp/delivery/program + batch_max = 20 + user = exim + +This delivers up to 20 addresses at a time, in a mixture of domains if +necessary, running as the user exim. + + + +=============================================================================== +29. THE PIPE TRANSPORT + +The pipe transport is used to deliver messages via a pipe to a command running +in another process. One example is the use of pipe as a pseudo-remote transport +for passing messages to some other delivery mechanism (such as UUCP). Another +is the use by individual users to automatically process their incoming +messages. The pipe transport can be used in one of the following ways: + + * A router routes one address to a transport in the normal way, and the + transport is configured as a pipe transport. In this case, $local_part + contains the local part of the address (as usual), and the command that is + run is specified by the command option on the transport. + + * If the batch_max option is set greater than 1 (the default is 1), the + transport can handle more than one address in a single run. In this case, + when more than one address is routed to the transport, $local_part is not + set (because it is not unique). However, the pseudo-variable + $pipe_addresses (described in section 29.3 below) contains all the + addresses that are routed to the transport. + + * A router redirects an address directly to a pipe command (for example, from + an alias or forward file). In this case, $address_pipe contains the text of + the pipe command, and the command option on the transport is ignored unless + force_command is set. If only one address is being transported (batch_max + is not greater than one, or only one address was redirected to this pipe + command), $local_part contains the local part that was redirected. + +The pipe transport is a non-interactive delivery method. Exim can also deliver +messages over pipes using the LMTP interactive protocol. This is implemented by +the lmtp transport. + +In the case when pipe is run as a consequence of an entry in a local user's +.forward file, the command runs under the uid and gid of that user. In other +cases, the uid and gid have to be specified explicitly, either on the transport +or on the router that handles the address. Current and "home" directories are +also controllable. See chapter 23 for details of the local delivery environment +and chapter 25 for a discussion of local delivery batching. + + +29.1 Concurrent delivery +------------------------ + +If two messages arrive at almost the same time, and both are routed to a pipe +delivery, the two pipe transports may be run concurrently. You must ensure that +any pipe commands you set up are robust against this happening. If the commands +write to a file, the exim_lock utility might be of use. Alternatively the +max_parallel option could be used with a value of "1" to enforce serialization. + + +29.2 Returned status and data +----------------------------- + +If the command exits with a non-zero return code, the delivery is deemed to +have failed, unless either the ignore_status option is set (in which case the +return code is treated as zero), or the return code is one of those listed in +the temp_errors option, which are interpreted as meaning "try again later". In +this case, delivery is deferred. Details of a permanent failure are logged, but +are not included in the bounce message, which merely contains "local delivery +failed". + +If the command exits on a signal and the freeze_signal option is set then the +message will be frozen in the queue. If that option is not set, a bounce will +be sent as normal. + +If the return code is greater than 128 and the command being run is a shell +script, it normally means that the script was terminated by a signal whose +value is the return code minus 128. The freeze_signal option does not apply in +this case. + +If Exim is unable to run the command (that is, if execve() fails), the return +code is set to 127. This is the value that a shell returns if it is asked to +run a non-existent command. The wording for the log line suggests that a +non-existent command may be the problem. + +The return_output option can affect the result of a pipe delivery. If it is set +and the command produces any output on its standard output or standard error +streams, the command is considered to have failed, even if it gave a zero +return code or if ignore_status is set. The output from the command is included +as part of the bounce message. The return_fail_output option is similar, except +that output is returned only when the command exits with a failure return code, +that is, a value other than zero or a code that matches temp_errors. + + +29.3 How the command is run +--------------------------- + +The command line is (by default) broken down into a command name and arguments +by the pipe transport itself. The allow_commands and restrict_to_path options +can be used to restrict the commands that may be run. + +Unquoted arguments are delimited by white space. If an argument appears in +double quotes, backslash is interpreted as an escape character in the usual +way. If an argument appears in single quotes, no escaping is done. + +String expansion is applied to the command line except when it comes from a +traditional .forward file (commands from a filter file are expanded). The +expansion is applied to each argument in turn rather than to the whole line. +For this reason, any string expansion item that contains white space must be +quoted so as to be contained within a single argument. A setting such as + +command = /some/path ${if eq{$local_part}{postmaster}{xx}{yy}} + +will not work, because the expansion item gets split between several arguments. +You have to write + +command = /some/path "${if eq{$local_part}{postmaster}{xx}{yy}}" + +to ensure that it is all in one argument. The expansion is done in this way, +argument by argument, so that the number of arguments cannot be changed as a +result of expansion, and quotes or backslashes in inserted variables do not +interact with external quoting. However, this leads to problems if you want to +generate multiple arguments (or the command name plus arguments) from a single +expansion. In this situation, the simplest solution is to use a shell. For +example: + +command = /bin/sh -c ${lookup{$local_part}lsearch{/some/file}} + +Special handling takes place when an argument consists of precisely the text +"$pipe_addresses" (no quotes). This is not a general expansion variable; the +only place this string is recognized is when it appears as an argument for a +pipe or transport filter command. It causes each address that is being handled +to be inserted in the argument list at that point as a separate argument. This +avoids any problems with spaces or shell metacharacters, and is of use when a +pipe transport is handling groups of addresses in a batch. + +If force_command is enabled on the transport, Special handling takes place for +an argument that consists of precisely the text "$address_pipe". It is handled +similarly to $pipe_addresses above. It is expanded and each argument is +inserted in the argument list at that point as a separate argument. The +"$address_pipe" item does not need to be the only item in the argument; in +fact, if it were then force_command should behave as a no-op. Rather, it should +be used to adjust the command run while preserving the argument vector +separation. + +After splitting up into arguments and expansion, the resulting command is run +in a subprocess directly from the transport, not under a shell. The message +that is being delivered is supplied on the standard input, and the standard +output and standard error are both connected to a single pipe that is read by +Exim. The max_output option controls how much output the command may produce, +and the return_output and return_fail_output options control what is done with +it. + +Not running the command under a shell (by default) lessens the security risks +in cases when a command from a user's filter file is built out of data that was +taken from an incoming message. If a shell is required, it can of course be +explicitly specified as the command to be run. However, there are circumstances +where existing commands (for example, in .forward files) expect to be run under +a shell and cannot easily be modified. To allow for these cases, there is an +option called use_shell, which changes the way the pipe transport works. +Instead of breaking up the command line as just described, it expands it as a +single string and passes the result to /bin/sh. The restrict_to_path option and +the $pipe_addresses facility cannot be used with use_shell, and the whole +mechanism is inherently less secure. + + +29.4 Environment variables +-------------------------- + +The environment variables listed below are set up when the command is invoked. +This list is a compromise for maximum compatibility with other MTAs. Note that +the environment option can be used to add additional variables to this +environment. The environment for the pipe transport is not subject to the +add_environment and keep_environment main config options. + +DOMAIN the domain of the address +HOME the home directory, if set +HOST the host name when called from a router (see below) +LOCAL_PART see below +LOCAL_PART_PREFIX see below +LOCAL_PART_SUFFIX see below +LOGNAME see below +MESSAGE_ID Exim's local ID for the message +PATH as specified by the path option below +QUALIFY_DOMAIN the sender qualification domain +RECIPIENT the complete recipient address +SENDER the sender of the message (empty if a bounce) +SHELL /bin/sh +TZ the value of the timezone option, if set +USER see below + +When a pipe transport is called directly from (for example) an accept router, +LOCAL_PART is set to the local part of the address. When it is called as a +result of a forward or alias expansion, LOCAL_PART is set to the local part of +the address that was expanded. In both cases, any affixes are removed from the +local part, and made available in LOCAL_PART_PREFIX and LOCAL_PART_SUFFIX, +respectively. LOGNAME and USER are set to the same value as LOCAL_PART for +compatibility with other MTAs. + +HOST is set only when a pipe transport is called from a router that associates +hosts with an address, typically when using pipe as a pseudo-remote transport. +HOST is set to the first host name specified by the router. + +If the transport's generic home_directory option is set, its value is used for +the HOME environment variable. Otherwise, a home directory may be set by the +router's transport_home_directory option, which defaults to the user's home +directory if check_local_user is set. + + +29.5 Private options for pipe +----------------------------- + ++----------------------------------------------------------+ +|allow_commands|Use: pipe|Type: string list*|Default: unset| ++----------------------------------------------------------+ + +The string is expanded, and is then interpreted as a colon-separated list of +permitted commands. If restrict_to_path is not set, the only commands permitted +are those in the allow_commands list. They need not be absolute paths; the path +option is still used for relative paths. If restrict_to_path is set with +allow_commands, the command must either be in the allow_commands list, or a +name without any slashes that is found on the path. In other words, if neither +allow_commands nor restrict_to_path is set, there is no restriction on the +command, but otherwise only commands that are permitted by one or the other are +allowed. For example, if + +allow_commands = /usr/bin/vacation + +and restrict_to_path is not set, the only permitted command is /usr/bin/ +vacation. The allow_commands option may not be set if use_shell is set. + ++-----------------------------------------------+ +|batch_id|Use: pipe|Type: string*|Default: unset| ++-----------------------------------------------+ + +See the description of local delivery batching in chapter 25. + ++--------------------------------------------+ +|batch_max|Use: pipe|Type: integer|Default: 1| ++--------------------------------------------+ + +This limits the number of addresses that can be handled in a single delivery. +See the description of local delivery batching in chapter 25. + ++--------------------------------------------------+ +|check_string|Use: pipe|Type: string|Default: unset| ++--------------------------------------------------+ + +As pipe writes the message, the start of each line is tested for matching +check_string, and if it does, the initial matching characters are replaced by +the contents of escape_string, provided both are set. The value of check_string +is a literal string, not a regular expression, and the case of any letters it +contains is significant. When use_bsmtp is set, the contents of check_string +and escape_string are forced to values that implement the SMTP escaping +protocol. Any settings made in the configuration file are ignored. + ++----------------------------------------------+ +|command|Use: pipe|Type: string*|Default: unset| ++----------------------------------------------+ + +This option need not be set when pipe is being used to deliver to pipes +obtained directly from address redirections. In other cases, the option must be +set, to provide a command to be run. It need not yield an absolute path (see +the path option below). The command is split up into separate arguments by +Exim, and each argument is separately expanded, as described in section 29.3 +above. + ++--------------------------------------------------+ +|environment|Use: pipe|Type: string*|Default: unset| ++--------------------------------------------------+ + +This option is used to add additional variables to the environment in which the +command runs (see section 29.4 for the default list). Its value is a string +which is expanded, and then interpreted as a colon-separated list of +environment settings of the form <name>=<value>. + ++---------------------------------------------------+ +|escape_string|Use: pipe|Type: string|Default: unset| ++---------------------------------------------------+ + +See check_string above. + ++-------------------------------------------------------+ +|freeze_exec_fail|Use: pipe|Type: boolean|Default: false| ++-------------------------------------------------------+ + +Failure to exec the command in a pipe transport is by default treated like any +other failure while running the command. However, if freeze_exec_fail is set, +failure to exec is treated specially, and causes the message to be frozen, +whatever the setting of ignore_status. + ++----------------------------------------------------+ +|freeze_signal|Use: pipe|Type: boolean|Default: false| ++----------------------------------------------------+ + +Normally if the process run by a command in a pipe transport exits on a signal, +a bounce message is sent. If freeze_signal is set, the message will be frozen +in Exim's queue instead. + ++----------------------------------------------------+ +|force_command|Use: pipe|Type: boolean|Default: false| ++----------------------------------------------------+ + +Normally when a router redirects an address directly to a pipe command the +command option on the transport is ignored. If force_command is set, the +command option will used. This is especially useful for forcing a wrapper or +additional argument to be added to the command. For example: + +command = /usr/bin/remote_exec myhost -- $address_pipe +force_command + +Note that $address_pipe is handled specially in command when force_command is +set, expanding out to the original argument vector as separate items, similarly +to a Unix shell ""$@"" construct. + ++----------------------------------------------------+ +|ignore_status|Use: pipe|Type: boolean|Default: false| ++----------------------------------------------------+ + +If this option is true, the status returned by the subprocess that is set up to +run the command is ignored, and Exim behaves as if zero had been returned. +Otherwise, a non-zero status or termination by signal causes an error return +from the transport unless the status value is one of those listed in +temp_errors; these cause the delivery to be deferred and tried again later. + +Note: This option does not apply to timeouts, which do not return a status. See +the timeout_defer option for how timeouts are handled. + ++-------------------------------------------------------+ +|log_defer_output|Use: pipe|Type: boolean|Default: false| ++-------------------------------------------------------+ + +If this option is set, and the status returned by the command is one of the +codes listed in temp_errors (that is, delivery was deferred), and any output +was produced on stdout or stderr, the first line of it is written to the main +log. + ++------------------------------------------------------+ +|log_fail_output|Use: pipe|Type: boolean|Default: false| ++------------------------------------------------------+ + +If this option is set, and the command returns any output on stdout or stderr, +and also ends with a return code that is neither zero nor one of the return +codes listed in temp_errors (that is, the delivery failed), the first line of +output is written to the main log. This option and log_output are mutually +exclusive. Only one of them may be set. + ++-------------------------------------------------+ +|log_output|Use: pipe|Type: boolean|Default: false| ++-------------------------------------------------+ + +If this option is set and the command returns any output on stdout or stderr, +the first line of output is written to the main log, whatever the return code. +This option and log_fail_output are mutually exclusive. Only one of them may be +set. + ++-----------------------------------------------+ +|max_output|Use: pipe|Type: integer|Default: 20K| ++-----------------------------------------------+ + +This specifies the maximum amount of output that the command may produce on its +standard output and standard error file combined. If the limit is exceeded, the +process running the command is killed. This is intended as a safety measure to +catch runaway processes. The limit is applied independently of the settings of +the options that control what is done with such output (for example, +return_output). Because of buffering effects, the amount of output may exceed +the limit by a small amount before Exim notices. + ++---------------------------------------------------------+ +|message_prefix|Use: pipe|Type: string*|Default: see below| ++---------------------------------------------------------+ + +The string specified here is expanded and output at the start of every message. +The default is unset if use_bsmtp is set. Otherwise it is + +message_prefix = \ + From ${if def:return_path{$return_path}{MAILER-DAEMON}}\ + ${tod_bsdinbox}\n + +This is required by the commonly used /usr/bin/vacation program. However, it +must not be present if delivery is to the Cyrus IMAP server, or to the tmail +local delivery agent. The prefix can be suppressed by setting + +message_prefix = + +Note: If you set use_crlf true, you must change any occurrences of "\n" to "\r\ +n" in message_prefix. + ++---------------------------------------------------------+ +|message_suffix|Use: pipe|Type: string*|Default: see below| ++---------------------------------------------------------+ + +The string specified here is expanded and output at the end of every message. +The default is unset if use_bsmtp is set. Otherwise it is a single newline. The +suffix can be suppressed by setting + +message_suffix = + +Note: If you set use_crlf true, you must change any occurrences of "\n" to "\r\ +n" in message_suffix. + ++---------------------------------------------------+ +|path|Use: pipe|Type: string*|Default: /bin:/usr/bin| ++---------------------------------------------------+ + +This option is expanded and specifies the string that is set up in the PATH +environment variable of the subprocess. If the command option does not yield an +absolute path name, the command is sought in the PATH directories, in the usual +way. Warning: This does not apply to a command specified as a transport filter. + ++------------------------------------------------------+ +|permit_coredump|Use: pipe|Type: boolean|Default: false| ++------------------------------------------------------+ + +Normally Exim inhibits core-dumps during delivery. If you have a need to get a +core-dump of a pipe command, enable this command. This enables core-dumps +during delivery and affects both the Exim binary and the pipe command run. It +is recommended that this option remain off unless and until you have a need for +it and that this only be enabled when needed, as the risk of excessive resource +consumption can be quite high. Note also that Exim is typically installed as a +setuid binary and most operating systems will inhibit coredumps of these by +default, so further OS-specific action may be required. + ++------------------------------------------------------+ +|pipe_as_creator|Use: pipe|Type: boolean|Default: false| ++------------------------------------------------------+ + +If the generic user option is not set and this option is true, the delivery +process is run under the uid that was in force when Exim was originally called +to accept the message. If the group id is not otherwise set (via the generic +group option), the gid that was in force when Exim was originally called to +accept the message is used. + ++-------------------------------------------------------+ +|restrict_to_path|Use: pipe|Type: boolean|Default: false| ++-------------------------------------------------------+ + +When this option is set, any command name not listed in allow_commands must +contain no slashes. The command is searched for only in the directories listed +in the path option. This option is intended for use in the case when a pipe +command has been generated from a user's .forward file. This is usually handled +by a pipe transport called address_pipe. + ++---------------------------------------------------------+ +|return_fail_output|Use: pipe|Type: boolean|Default: false| ++---------------------------------------------------------+ + +If this option is true, and the command produced any output and ended with a +return code other than zero or one of the codes listed in temp_errors (that is, +the delivery failed), the output is returned in the bounce message. However, if +the message has a null sender (that is, it is itself a bounce message), output +from the command is discarded. This option and return_output are mutually +exclusive. Only one of them may be set. + ++----------------------------------------------------+ +|return_output|Use: pipe|Type: boolean|Default: false| ++----------------------------------------------------+ + +If this option is true, and the command produced any output, the delivery is +deemed to have failed whatever the return code from the command, and the output +is returned in the bounce message. Otherwise, the output is just discarded. +However, if the message has a null sender (that is, it is a bounce message), +output from the command is always discarded, whatever the setting of this +option. This option and return_fail_output are mutually exclusive. Only one of +them may be set. + ++----------------------------------------------------------+ +|temp_errors|Use: pipe|Type: string list|Default: see below| ++----------------------------------------------------------+ + +This option contains either a colon-separated list of numbers, or a single +asterisk. If ignore_status is false and return_output is not set, and the +command exits with a non-zero return code, the failure is treated as temporary +and the delivery is deferred if the return code matches one of the numbers, or +if the setting is a single asterisk. Otherwise, non-zero return codes are +treated as permanent errors. The default setting contains the codes defined by +EX_TEMPFAIL and EX_CANTCREAT in sysexits.h. If Exim is compiled on a system +that does not define these macros, it assumes values of 75 and 73, +respectively. + ++----------------------------------------+ +|timeout|Use: pipe|Type: time|Default: 1h| ++----------------------------------------+ + +If the command fails to complete within this time, it is killed. This normally +causes the delivery to fail (but see timeout_defer). A zero time interval +specifies no timeout. In order to ensure that any subprocesses created by the +command are also killed, Exim makes the initial process a process group leader, +and kills the whole process group on a timeout. However, this can be defeated +if one of the processes starts a new process group. + ++----------------------------------------------------+ +|timeout_defer|Use: pipe|Type: boolean|Default: false| ++----------------------------------------------------+ + +A timeout in a pipe transport, either in the command that the transport runs, +or in a transport filter that is associated with it, is by default treated as a +hard error, and the delivery fails. However, if timeout_defer is set true, both +kinds of timeout become temporary errors, causing the delivery to be deferred. + ++------------------------------------------------+ +|umask|Use: pipe|Type: octal integer|Default: 022| ++------------------------------------------------+ + +This specifies the umask setting for the subprocess that runs the command. + ++------------------------------------------------+ +|use_bsmtp|Use: pipe|Type: boolean|Default: false| ++------------------------------------------------+ + +If this option is set true, the pipe transport writes messages in "batch SMTP" +format, with the envelope sender and recipient(s) included as SMTP commands. If +you want to include a leading HELO command with such messages, you can do so by +setting the message_prefix option. See section 48.10 for details of batch SMTP. + ++---------------------------------------------------------+ +|use_classresources|Use: pipe|Type: boolean|Default: false| ++---------------------------------------------------------+ + +This option is available only when Exim is running on FreeBSD, NetBSD, or BSD/ +OS. If it is set true, the setclassresources() function is used to set resource +limits when a pipe transport is run to perform a delivery. The limits for the +uid under which the pipe is to run are obtained from the login class database. + ++-----------------------------------------------+ +|use_crlf|Use: pipe|Type: boolean|Default: false| ++-----------------------------------------------+ + +This option causes lines to be terminated with the two-character CRLF sequence +(carriage return, linefeed) instead of just a linefeed character. In the case +of batched SMTP, the byte sequence written to the pipe is then an exact image +of what would be sent down a real SMTP connection. + +The contents of the message_prefix and message_suffix options are written +verbatim, so must contain their own carriage return characters if these are +needed. When use_bsmtp is not set, the default values for both message_prefix +and message_suffix end with a single linefeed, so their values must be changed +to end with "\r\n" if use_crlf is set. + ++------------------------------------------------+ +|use_shell|Use: pipe|Type: boolean|Default: false| ++------------------------------------------------+ + +If this option is set, it causes the command to be passed to /bin/sh instead of +being run directly from the transport, as described in section 29.3. This is +less secure, but is needed in some situations where the command is expected to +be run under a shell and cannot easily be modified. The allow_commands and +restrict_to_path options, and the "$pipe_addresses" facility are incompatible +with use_shell. The command is expanded as a single string, and handed to /bin/ +sh as data for its -c option. + + +29.6 Using an external local delivery agent +------------------------------------------- + +The pipe transport can be used to pass all messages that require local delivery +to a separate local delivery agent such as procmail. When doing this, care must +be taken to ensure that the pipe is run under an appropriate uid and gid. In +some configurations one wants this to be a uid that is trusted by the delivery +agent to supply the correct sender of the message. It may be necessary to +recompile or reconfigure the delivery agent so that it trusts an appropriate +user. The following is an example transport and router configuration for +procmail: + +# transport +procmail_pipe: + driver = pipe + command = /usr/local/bin/procmail -d $local_part + return_path_add + delivery_date_add + envelope_to_add + check_string = "From " + escape_string = ">From " + umask = 077 + user = $local_part + group = mail + +# router +procmail: + driver = accept + check_local_user + transport = procmail_pipe + +In this example, the pipe is run as the local user, but with the group set to +mail. An alternative is to run the pipe as a specific user such as mail or exim +, but in this case you must arrange for procmail to trust that user to supply a +correct sender address. If you do not specify either a group or a user option, +the pipe command is run as the local user. The home directory is the user's +home directory by default. + +Note: The command that the pipe transport runs does not begin with + +IFS=" " + +as shown in some procmail documentation, because Exim does not by default use a +shell to run pipe commands. + +The next example shows a transport and a router for a system where local +deliveries are handled by the Cyrus IMAP server. + +# transport +local_delivery_cyrus: + driver = pipe + command = /usr/cyrus/bin/deliver \ + -m ${substr_1:$local_part_suffix} -- $local_part + user = cyrus + group = mail + return_output + log_output + message_prefix = + message_suffix = + +# router +local_user_cyrus: + driver = accept + check_local_user + local_part_suffix = .* + transport = local_delivery_cyrus + +Note the unsetting of message_prefix and message_suffix, and the use of +return_output to cause any text written by Cyrus to be returned to the sender. + + + +=============================================================================== +30. THE SMTP TRANSPORT + +The smtp transport delivers messages over TCP/IP connections using the SMTP or +LMTP protocol. The list of hosts to try can either be taken from the address +that is being processed (having been set up by the router), or specified +explicitly for the transport. Timeout and retry processing (see chapter 32) is +applied to each IP address independently. + + +30.1 Multiple messages on a single connection +--------------------------------------------- + +The sending of multiple messages over a single TCP/IP connection can arise in +two ways: + + * If a message contains more than max_rcpt (see below) addresses that are + routed to the same host, more than one copy of the message has to be sent + to that host. In this situation, multiple copies may be sent in a single + run of the smtp transport over a single TCP/IP connection. (What Exim + actually does when it has too many addresses to send in one message also + depends on the value of the global remote_max_parallel option. Details are + given in section 48.1.) + + * When a message has been successfully delivered over a TCP/IP connection, + Exim looks in its hints database to see if there are any other messages + awaiting a connection to the same host. If there are, a new delivery + process is started for one of them, and the current TCP/IP connection is + passed on to it. The new process may in turn send multiple copies and + possibly create yet another process. + +For each copy sent over the same TCP/IP connection, a sequence counter is +incremented, and if it ever gets to the value of connection_max_messages, no +further messages are sent over that connection. + + +30.2 Use of the $host and $host_address variables +------------------------------------------------- + +At the start of a run of the smtp transport, the values of $host and +$host_address are the name and IP address of the first host on the host list +passed by the router. However, when the transport is about to connect to a +specific host, and while it is connected to that host, $host and $host_address +are set to the values for that host. These are the values that are in force +when the helo_data, hosts_try_auth, interface, serialize_hosts, and the various +TLS options are expanded. + + +30.3 Use of $tls_cipher and $tls_peerdn +--------------------------------------- + +At the start of a run of the smtp transport, the values of $tls_bits, +$tls_cipher, $tls_peerdn and $tls_sni are the values that were set when the +message was received. These are the values that are used for options that are +expanded before any SMTP connections are made. Just before each connection is +made, these four variables are emptied. If TLS is subsequently started, they +are set to the appropriate values for the outgoing connection, and these are +the values that are in force when any authenticators are run and when the +authenticated_sender option is expanded. + +These variables are deprecated in favour of $tls_in_cipher et. al. and will be +removed in a future release. + + +30.4 Private options for smtp +----------------------------- + +The private options of the smtp transport are as follows: + ++------------------------------------------------------------------+ +|address_retry_include_sender|Use: smtp|Type: boolean|Default: true| ++------------------------------------------------------------------+ + +When an address is delayed because of a 4xx response to a RCPT command, it is +the combination of sender and recipient that is delayed in subsequent queue +runs until the retry time is reached. You can delay the recipient without +reference to the sender (which is what earlier versions of Exim did), by +setting address_retry_include_sender false. However, this can lead to problems +with servers that regularly issue 4xx responses to RCPT commands. + ++------------------------------------------------------+ +|allow_localhost|Use: smtp|Type: boolean|Default: false| ++------------------------------------------------------+ + +When a host specified in hosts or fallback_hosts (see below) turns out to be +the local host, or is listed in hosts_treat_as_local, delivery is deferred by +default. However, if allow_localhost is set, Exim goes on to do the delivery +anyway. This should be used only in special cases when the configuration +ensures that no looping will result (for example, a differently configured Exim +is listening on the port to which the message is sent). + ++-----------------------------------------------------------+ +|authenticated_sender|Use: smtp|Type: string*|Default: unset| ++-----------------------------------------------------------+ + +When Exim has authenticated as a client, or if authenticated_sender_force is +true, this option sets a value for the AUTH= item on outgoing MAIL commands, +overriding any existing authenticated sender value. If the string expansion is +forced to fail, the option is ignored. Other expansion failures cause delivery +to be deferred. If the result of expansion is an empty string, that is also +ignored. + +The expansion happens after the outgoing connection has been made and TLS +started, if required. This means that the $host, $host_address, $tls_out_cipher +, and $tls_out_peerdn variables are set according to the particular connection. + +If the SMTP session is not authenticated, the expansion of authenticated_sender +still happens (and can cause the delivery to be deferred if it fails), but no +AUTH= item is added to MAIL commands unless authenticated_sender_force is true. + +This option allows you to use the smtp transport in LMTP mode to deliver mail +to Cyrus IMAP and provide the proper local part as the "authenticated sender", +via a setting such as: + +authenticated_sender = $local_part + +This removes the need for IMAP subfolders to be assigned special ACLs to allow +direct delivery to those subfolders. + +Because of expected uses such as that just described for Cyrus (when no domain +is involved), there is no checking on the syntax of the provided value. + ++-----------------------------------------------------------------+ +|authenticated_sender_force|Use: smtp|Type: boolean|Default: false| ++-----------------------------------------------------------------+ + +If this option is set true, the authenticated_sender option's value is used for +the AUTH= item on outgoing MAIL commands, even if Exim has not authenticated as +a client. + ++------------------------------------------------+ +|command_timeout|Use: smtp|Type: time|Default: 5m| ++------------------------------------------------+ + +This sets a timeout for receiving a response to an SMTP command that has been +sent out. It is also used when waiting for the initial banner line from the +remote host. Its value must not be zero. + ++------------------------------------------------+ +|connect_timeout|Use: smtp|Type: time|Default: 5m| ++------------------------------------------------+ + +This sets a timeout for the connect() function, which sets up a TCP/IP call to +a remote host. A setting of zero allows the system timeout (typically several +minutes) to act. To have any effect, the value of this option must be less than +the system timeout. However, it has been observed that on some systems there is +no system timeout, which is why the default value for this option is 5 minutes, +a value recommended by RFC 1123. + ++------------------------------------------------------------+ +|connection_max_messages|Use: smtp|Type: integer|Default: 500| ++------------------------------------------------------------+ + +This controls the maximum number of separate message deliveries that are sent +over a single TCP/IP connection. If the value is zero, there is no limit. For +testing purposes, this value can be overridden by the -oB command line option. + ++---------------------------------------------------------------+ +|dane_require_tls_ciphers|Use: smtp|Type: string*|Default: unset| ++---------------------------------------------------------------+ + +This option may be used to override tls_require_ciphers for connections where +DANE has been determined to be in effect. If not set, then tls_require_ciphers +will be used. Normal SMTP delivery is not able to make strong demands of TLS +cipher configuration, because delivery will fall back to plaintext. Once DANE +has been determined to be in effect, there is no plaintext fallback and making +the TLS cipherlist configuration stronger will increase security, rather than +counter-intuitively decreasing it. If the option expands to be empty or is +forced to fail, then it will be treated as unset and tls_require_ciphers will +be used instead. + ++---------------------------------------------+ +|data_timeout|Use: smtp|Type: time|Default: 5m| ++---------------------------------------------+ + +This sets a timeout for the transmission of each block in the data portion of +the message. As a result, the overall timeout for a message depends on the size +of the message. Its value must not be zero. See also final_timeout. + ++-------------------------------------------------+ +|dkim_canon|Use: smtp|Type: string*|Default: unset| ++-------------------------------------------------+ + ++-------------------------------------------------+ +|dkim_domain|Use: smtp|Type: string|Default: list*| ++-------------------------------------------------+ + ++-------------------------------------------------+ +|dkim_hash|Use: smtp|Type: string*|Default: sha256| ++-------------------------------------------------+ + ++----------------------------------------------------+ +|dkim_identity|Use: smtp|Type: string*|Default: unset| ++----------------------------------------------------+ + ++-------------------------------------------------------+ +|dkim_private_key|Use: smtp|Type: string*|Default: unset| ++-------------------------------------------------------+ + ++----------------------------------------------------+ +|dkim_selector|Use: smtp|Type: string*|Default: unset| ++----------------------------------------------------+ + ++--------------------------------------------------+ +|dkim_strict|Use: smtp|Type: string*|Default: unset| ++--------------------------------------------------+ + ++----------------------------------------------------------+ +|dkim_sign_headers|Use: smtp|Type: string*|Default: per RFC| ++----------------------------------------------------------+ + ++------------------------------------------------------+ +|dkim_timestamps|Use: smtp|Type: string*|Default: unset| ++------------------------------------------------------+ + +DKIM signing options. For details see section 57.2. + ++--------------------------------------------------------+ +|delay_after_cutoff|Use: smtp|Type: boolean|Default: true| ++--------------------------------------------------------+ + +This option controls what happens when all remote IP addresses for a given +domain have been inaccessible for so long that they have passed their retry +cutoff times. + +In the default state, if the next retry time has not been reached for any of +them, the address is bounced without trying any deliveries. In other words, +Exim delays retrying an IP address after the final cutoff time until a new +retry time is reached, and can therefore bounce an address without ever trying +a delivery, when machines have been down for a long time. Some people are +unhappy at this prospect, so... + +If delay_after_cutoff is set false, Exim behaves differently. If all IP +addresses are past their final cutoff time, Exim tries to deliver to those IP +addresses that have not been tried since the message arrived. If there are +none, of if they all fail, the address is bounced. In other words, it does not +delay when a new message arrives, but immediately tries those expired IP +addresses that haven't been tried since the message arrived. If there is a +continuous stream of messages for the dead hosts, unsetting delay_after_cutoff +means that there will be many more attempts to deliver to them. + ++--------------------------------------------------------+ +|dns_qualify_single|Use: smtp|Type: boolean|Default: true| ++--------------------------------------------------------+ + +If the hosts or fallback_hosts option is being used, and the gethostbyname +option is false, the RES_DEFNAMES resolver option is set. See the +qualify_single option in chapter 17 for more details. + ++---------------------------------------------------------+ +|dns_search_parents|Use: smtp|Type: boolean|Default: false| ++---------------------------------------------------------+ + +If the hosts or fallback_hosts option is being used, and the gethostbyname +option is false, the RES_DNSRCH resolver option is set. See the search_parents +option in chapter 17 for more details. + ++------------------------------------------------------------------+ +|dnssec_request_domains|Use: smtp|Type: domain list*|Default: unset| ++------------------------------------------------------------------+ + +DNS lookups for domains matching dnssec_request_domains will be done with the +dnssec request bit set. This applies to all of the SRV, MX, AAAA, A lookup +sequence. + ++------------------------------------------------------------------+ +|dnssec_require_domains|Use: smtp|Type: domain list*|Default: unset| ++------------------------------------------------------------------+ + +DNS lookups for domains matching dnssec_require_domains will be done with the +dnssec request bit set. Any returns not having the Authenticated Data bit (AD +bit) set will be ignored and logged as a host-lookup failure. This applies to +all of the SRV, MX, AAAA, A lookup sequence. + ++-------------------------------------------+ +|dscp|Use: smtp|Type: string*|Default: unset| ++-------------------------------------------+ + +This option causes the DSCP value associated with a socket to be set to one of +a number of fixed strings or to numeric value. The -bI:dscp option may be used +to ask Exim which names it knows of. Common values include "throughput", +"mincost", and on newer systems "ef", "af41", etc. Numeric values may be in the +range 0 to 0x3F. + +The outbound packets from Exim will be marked with this value in the header +(for IPv4, the TOS field; for IPv6, the TCLASS field); there is no guarantee +that these values will have any effect, not be stripped by networking +equipment, or do much of anything without cooperation with your Network +Engineer and those of all network operators between the source and destination. + ++---------------------------------------------------------+ +|fallback_hosts|Use: smtp|Type: string list|Default: unset| ++---------------------------------------------------------+ + +String expansion is not applied to this option. The argument must be a +colon-separated list of host names or IP addresses, optionally also including +port numbers, though the separator can be changed, as described in section 6.20 +. Each individual item in the list is the same as an item in a route_list +setting for the manualroute router, as described in section 20.5. + +Fallback hosts can also be specified on routers, which associate them with the +addresses they process. As for the hosts option without hosts_override, +fallback_hosts specified on the transport is used only if the address does not +have its own associated fallback host list. Unlike hosts, a setting of +fallback_hosts on an address is not overridden by hosts_override. However, +hosts_randomize does apply to fallback host lists. + +If Exim is unable to deliver to any of the hosts for a particular address, and +the errors are not permanent rejections, the address is put on a separate +transport queue with its host list replaced by the fallback hosts, unless the +address was routed via MX records and the current host was in the original MX +list. In that situation, the fallback host list is not used. + +Once normal deliveries are complete, the fallback queue is delivered by +re-running the same transports with the new host lists. If several failing +addresses have the same fallback hosts (and max_rcpt permits it), a single copy +of the message is sent. + +The resolution of the host names on the fallback list is controlled by the +gethostbyname option, as for the hosts option. Fallback hosts apply both to +cases when the host list comes with the address and when it is taken from hosts +. This option provides a "use a smart host only if delivery fails" facility. + ++-----------------------------------------------+ +|final_timeout|Use: smtp|Type: time|Default: 10m| ++-----------------------------------------------+ + +This is the timeout that applies while waiting for the response to the final +line containing just "." that terminates a message. Its value must not be zero. + ++----------------------------------------------------+ +|gethostbyname|Use: smtp|Type: boolean|Default: false| ++----------------------------------------------------+ + +If this option is true when the hosts and/or fallback_hosts options are being +used, names are looked up using gethostbyname() (or getipnodebyname() when +available) instead of using the DNS. Of course, that function may in fact use +the DNS, but it may also consult other sources of information such as /etc/ +hosts. + ++---------------------------------------------------------+ +|gnutls_compat_mode|Use: smtp|Type: boolean|Default: unset| ++---------------------------------------------------------+ + +This option controls whether GnuTLS is used in compatibility mode in an Exim +server. This reduces security slightly, but improves interworking with older +implementations of TLS. + ++----------------------------------------------------+ +|helo_data|Use: smtp|Type: string*|Default: see below| ++----------------------------------------------------+ + +The value of this option is expanded after a connection to a another host has +been set up. The result is used as the argument for the EHLO, HELO, or LHLO +command that starts the outgoing SMTP or LMTP session. The default value of the +option is: + +$primary_hostname + +During the expansion, the variables $host and $host_address are set to the +identity of the remote host, and the variables $sending_ip_address and +$sending_port are set to the local IP address and port number that are being +used. These variables can be used to generate different values for different +servers or different local IP addresses. For example, if you want the string +that is used for helo_data to be obtained by a DNS lookup of the outgoing +interface address, you could use this: + +helo_data = ${lookup dnsdb{ptr=$sending_ip_address}{$value}\ + {$primary_hostname}} + +The use of helo_data applies both to sending messages and when doing callouts. + ++-------------------------------------------------+ +|hosts|Use: smtp|Type: string list*|Default: unset| ++-------------------------------------------------+ + +Hosts are associated with an address by a router such as dnslookup, which finds +the hosts by looking up the address domain in the DNS, or by manualroute, which +has lists of hosts in its configuration. However, email addresses can be passed +to the smtp transport by any router, and not all of them can provide an +associated list of hosts. + +The hosts option specifies a list of hosts to be used if the address being +processed does not have any hosts associated with it. The hosts specified by +hosts are also used, whether or not the address has its own hosts, if +hosts_override is set. + +The string is first expanded, before being interpreted as a colon-separated +list of host names or IP addresses, possibly including port numbers. The +separator may be changed to something other than colon, as described in section +6.20. Each individual item in the list is the same as an item in a route_list +setting for the manualroute router, as described in section 20.5. However, note +that the "/MX" facility of the manualroute router is not available here. + +If the expansion fails, delivery is deferred. Unless the failure was caused by +the inability to complete a lookup, the error is logged to the panic log as +well as the main log. Host names are looked up either by searching directly for +address records in the DNS or by calling gethostbyname() (or getipnodebyname() +when available), depending on the setting of the gethostbyname option. When +Exim is compiled with IPv6 support, if a host that is looked up in the DNS has +both IPv4 and IPv6 addresses, both types of address are used. + +During delivery, the hosts are tried in order, subject to their retry status, +unless hosts_randomize is set. + ++-----------------------------------------------------------+ +|hosts_avoid_esmtp|Use: smtp|Type: host list*|Default: unset| ++-----------------------------------------------------------+ + +This option is for use with broken hosts that announce ESMTP facilities (for +example, PIPELINING) and then fail to implement them properly. When a host +matches hosts_avoid_esmtp, Exim sends HELO rather than EHLO at the start of the +SMTP session. This means that it cannot use any of the ESMTP facilities such as +AUTH, PIPELINING, SIZE, and STARTTLS. + ++----------------------------------------------------------------+ +|hosts_avoid_pipelining|Use: smtp|Type: host list*|Default: unset| ++----------------------------------------------------------------+ + +Exim will not use the SMTP PIPELINING extension when delivering to any host +that matches this list, even if the server host advertises PIPELINING support. + ++---------------------------------------------------------+ +|hosts_avoid_tls|Use: smtp|Type: host list*|Default: unset| ++---------------------------------------------------------+ + +Exim will not try to start a TLS session when delivering to any host that +matches this list. See chapter 42 for details of TLS. + ++----------------------------------------------------------------+ +|hosts_verify_avoid_tls|Use: smtp|Type: host list*|Default: unset| ++----------------------------------------------------------------+ + +Exim will not try to start a TLS session for a verify callout, or when +delivering in cutthrough mode, to any host that matches this list. + ++------------------------------------------------+ +|hosts_max_try|Use: smtp|Type: integer|Default: 5| ++------------------------------------------------+ + +This option limits the number of IP addresses that are tried for any one +delivery in cases where there are temporary delivery errors. Section 30.5 +describes in detail how the value of this option is used. + ++-----------------------------------------------------------+ +|hosts_max_try_hardlimit|Use: smtp|Type: integer|Default: 50| ++-----------------------------------------------------------+ + +This is an additional check on the maximum number of IP addresses that Exim +tries for any one delivery. Section 30.5 describes its use and why it exists. + ++----------------------------------------------------------+ +|hosts_nopass_tls|Use: smtp|Type: host list*|Default: unset| ++----------------------------------------------------------+ + +For any host that matches this list, a connection on which a TLS session has +been started will not be passed to a new delivery process for sending another +message on the same connection. See section 42.11 for an explanation of when +this might be needed. + ++-------------------------------------------------------+ +|hosts_noproxy_tls|Use: smtp|Type: host list*|Default: *| ++-------------------------------------------------------+ + +For any host that matches this list, a TLS session which has been started will +not be passed to a new delivery process for sending another message on the same +session. + +The traditional implementation closes down TLS and re-starts it in the new +process, on the same open TCP connection, for each successive message sent. If +permitted by this option a pipe to to the new process is set up instead, and +the original process maintains the TLS connection and proxies the SMTP +connection from and to the new process and any subsequents. The new process has +no access to TLS information, so cannot include it in logging. + ++-----------------------------------------------------+ +|hosts_override|Use: smtp|Type: boolean|Default: false| ++-----------------------------------------------------+ + +If this option is set and the hosts option is also set, any hosts that are +attached to the address are ignored, and instead the hosts specified by the +hosts option are always used. This option does not apply to fallback_hosts. + ++------------------------------------------------------+ +|hosts_randomize|Use: smtp|Type: boolean|Default: false| ++------------------------------------------------------+ + +If this option is set, and either the list of hosts is taken from the hosts or +the fallback_hosts option, or the hosts supplied by the router were not +obtained from MX records (this includes fallback hosts from the router), and +were not randomized by the router, the order of trying the hosts is randomized +each time the transport runs. Randomizing the order of a host list can be used +to do crude load sharing. + +When hosts_randomize is true, a host list may be split into groups whose order +is separately randomized. This makes it possible to set up MX-like behaviour. +The boundaries between groups are indicated by an item that is just "+" in the +host list. For example: + +hosts = host1:host2:host3:+:host4:host5 + +The order of the first three hosts and the order of the last two hosts is +randomized for each use, but the first three always end up before the last two. +If hosts_randomize is not set, a "+" item in the list is ignored. + ++------------------------------------------------------------+ +|hosts_require_auth|Use: smtp|Type: host list*|Default: unset| ++------------------------------------------------------------+ + +This option provides a list of servers for which authentication must succeed +before Exim will try to transfer a message. If authentication fails for servers +which are not in this list, Exim tries to send unauthenticated. If +authentication fails for one of these servers, delivery is deferred. This +temporary error is detectable in the retry rules, so it can be turned into a +hard failure if required. See also hosts_try_auth, and chapter 33 for details +of authentication. + ++--------------------------------------------------------+ +|hosts_request_ocsp|Use: smtp|Type: host list*|Default: *| ++--------------------------------------------------------+ + +Exim will request a Certificate Status on a TLS session for any host that +matches this list. tls_verify_certificates should also be set for the +transport. + ++------------------------------------------------------------+ +|hosts_require_dane|Use: smtp|Type: host list*|Default: unset| ++------------------------------------------------------------+ + +If built with DANE support, Exim will require that a DNSSEC-validated TLSA +record is present for any host matching the list, and that a DANE-verified TLS +connection is made. There will be no fallback to in-clear communication. See +section 42.15. + ++------------------------------------------------------------+ +|hosts_require_ocsp|Use: smtp|Type: host list*|Default: unset| ++------------------------------------------------------------+ + +Exim will request, and check for a valid Certificate Status being given, on a +TLS session for any host that matches this list. tls_verify_certificates should +also be set for the transport. + ++-----------------------------------------------------------+ +|hosts_require_tls|Use: smtp|Type: host list*|Default: unset| ++-----------------------------------------------------------+ + +Exim will insist on using a TLS session when delivering to any host that +matches this list. See chapter 42 for details of TLS. Note: This option affects +outgoing mail only. To insist on TLS for incoming messages, use an appropriate +ACL. + ++--------------------------------------------------------+ +|hosts_try_auth|Use: smtp|Type: host list*|Default: unset| ++--------------------------------------------------------+ + +This option provides a list of servers to which, provided they announce +authentication support, Exim will attempt to authenticate as a client when it +connects. If authentication fails, Exim will try to transfer the message +unauthenticated. See also hosts_require_auth, and chapter 33 for details of +authentication. + ++--------------------------------------------------------+ +|hosts_try_chunking|Use: smtp|Type: host list*|Default: *| ++--------------------------------------------------------+ + +This option provides a list of servers to which, provided they announce +CHUNKING support, Exim will attempt to use BDAT commands rather than DATA. BDAT +will not be used in conjunction with a transport filter. + ++--------------------------------------------------------+ +|hosts_try_dane|Use: smtp|Type: host list*|Default: unset| ++--------------------------------------------------------+ + +If built with DANE support, Exim will lookup a TLSA record for any host +matching the list. If found and verified by DNSSEC, a DANE-verified TLS +connection is made to that host; there will be no fallback to in-clear +communication. See section 42.15. + ++------------------------------------------------------------+ +|hosts_try_fastopen|Use: smtp|Type: host list*|Default: unset| ++------------------------------------------------------------+ + +This option provides a list of servers to which, provided the facility is +supported by this system, Exim will attempt to perform a TCP Fast Open. No data +is sent on the SYN segment but, if the remote server also supports the +facility, it can send its SMTP banner immediately after the SYN,ACK segment. +This can save up to one round-trip time. + +The facility is only active for previously-contacted servers, as the initiator +must present a cookie in the SYN segment. + +On (at least some) current Linux distributions the facility must be enabled in +the kernel by the sysadmin before the support is usable. There is no option for +control of the server side; if the system supports it it is always enabled. +Note that lengthy operations in the connect ACL, such as DNSBL lookups, will +still delay the emission of the SMTP banner. + ++----------------------------------------------------+ +|hosts_try_prdr|Use: smtp|Type: host list*|Default: *| ++----------------------------------------------------+ + +This option provides a list of servers to which, provided they announce PRDR +support, Exim will attempt to negotiate PRDR for multi-recipient messages. The +option can usually be left as default. + ++-----------------------------------------------------+ +|interface|Use: smtp|Type: string list*|Default: unset| ++-----------------------------------------------------+ + +This option specifies which interface to bind to when making an outgoing SMTP +call. The value is an IP address, not an interface name such as "eth0". Do not +confuse this with the interface address that was used when a message was +received, which is in $received_ip_address, formerly known as +$interface_address. The name was changed to minimize confusion with the +outgoing interface address. There is no variable that contains an outgoing +interface address because, unless it is set by this option, its value is +unknown. + +During the expansion of the interface option the variables $host and +$host_address refer to the host to which a connection is about to be made +during the expansion of the string. Forced expansion failure, or an empty +string result causes the option to be ignored. Otherwise, after expansion, the +string must be a list of IP addresses, colon-separated by default, but the +separator can be changed in the usual way (6.21). For example: + +interface = <; 192.168.123.123 ; 3ffe:ffff:836f::fe86:a061 + +The first interface of the correct type (IPv4 or IPv6) is used for the outgoing +connection. If none of them are the correct type, the option is ignored. If +interface is not set, or is ignored, the system's IP functions choose which +interface to use if the host has more than one. + ++-----------------------------------------------+ +|keepalive|Use: smtp|Type: boolean|Default: true| ++-----------------------------------------------+ + +This option controls the setting of SO_KEEPALIVE on outgoing TCP/IP socket +connections. When set, it causes the kernel to probe idle connections +periodically, by sending packets with "old" sequence numbers. The other end of +the connection should send a acknowledgment if the connection is still okay or +a reset if the connection has been aborted. The reason for doing this is that +it has the beneficial effect of freeing up certain types of connection that can +get stuck when the remote host is disconnected without tidying up the TCP/IP +call properly. The keepalive mechanism takes several hours to detect +unreachable hosts. + ++--------------------------------------------------------+ +|lmtp_ignore_quota|Use: smtp|Type: boolean|Default: false| ++--------------------------------------------------------+ + +If this option is set true when the protocol option is set to "lmtp", the +string "IGNOREQUOTA" is added to RCPT commands, provided that the LMTP server +has advertised support for IGNOREQUOTA in its response to the LHLO command. + ++---------------------------------------------+ +|max_rcpt|Use: smtp|Type: integer|Default: 100| ++---------------------------------------------+ + +This option limits the number of RCPT commands that are sent in a single SMTP +message transaction. Each set of addresses is treated independently, and so can +cause parallel connections to the same host if remote_max_parallel permits +this. + ++---------------------------------------------------+ +|multi_domain|Use: smtp|Type: boolean*|Default: true| ++---------------------------------------------------+ + +When this option is set, the smtp transport can handle a number of addresses +containing a mixture of different domains provided they all resolve to the same +list of hosts. Turning the option off restricts the transport to handling only +one domain at a time. This is useful if you want to use $domain in an expansion +for the transport, because it is set only when there is a single domain +involved in a remote delivery. + +It is expanded per-address and can depend on any of $address_data, $domain_data +, $local_part_data, $host, $host_address and $host_port. + ++-----------------------------------------------+ +|port|Use: smtp|Type: string*|Default: see below| ++-----------------------------------------------+ + +This option specifies the TCP/IP port on the server to which Exim connects. +Note: Do not confuse this with the port that was used when a message was +received, which is in $received_port, formerly known as $interface_port. The +name was changed to minimize confusion with the outgoing port. There is no +variable that contains an outgoing port. + +If the value of this option begins with a digit it is taken as a port number; +otherwise it is looked up using getservbyname(). The default value is normally +"smtp", but if protocol is set to "lmtp" the default is "lmtp" and if protocol +is set to "smtps" the default is "smtps". If the expansion fails, or if a port +number cannot be found, delivery is deferred. + +Note that at least one Linux distribution has been seen failing to put "smtps" +in its "/etc/services" file, resulting is such deferrals. + ++---------------------------------------------+ +|protocol|Use: smtp|Type: string|Default: smtp| ++---------------------------------------------+ + +If this option is set to "lmtp" instead of "smtp", the default value for the +port option changes to "lmtp", and the transport operates the LMTP protocol +(RFC 2033) instead of SMTP. This protocol is sometimes used for local +deliveries into closed message stores. Exim also has support for running LMTP +over a pipe to a local process - see chapter 28. + +If this option is set to "smtps", the default value for the port option changes +to "smtps", and the transport initiates TLS immediately after connecting, as an +outbound SSL-on-connect, instead of using STARTTLS to upgrade. + +The Internet standards bodies used to strongly discourage use of this mode, but +as of RFC 8314 it is perferred over STARTTLS for message submission (as +distinct from MTA-MTA communication). + ++---------------------------------------------------------------+ +|retry_include_ip_address|Use: smtp|Type: boolean*|Default: true| ++---------------------------------------------------------------+ + +Exim normally includes both the host name and the IP address in the key it +constructs for indexing retry data after a temporary delivery failure. This +means that when one of several IP addresses for a host is failing, it gets +tried periodically (controlled by the retry rules), but use of the other IP +addresses is not affected. + +However, in some dialup environments hosts are assigned a different IP address +each time they connect. In this situation the use of the IP address as part of +the retry key leads to undesirable behaviour. Setting this option false causes +Exim to use only the host name. Since it is expanded it can be made to depend +on the host or domain. + ++---------------------------------------------------------+ +|serialize_hosts|Use: smtp|Type: host list*|Default: unset| ++---------------------------------------------------------+ + +Because Exim operates in a distributed manner, if several messages for the same +host arrive at around the same time, more than one simultaneous connection to +the remote host can occur. This is not usually a problem except when there is a +slow link between the hosts. In that situation it may be helpful to restrict +Exim to one connection at a time. This can be done by setting serialize_hosts +to match the relevant hosts. + +Exim implements serialization by means of a hints database in which a record is +written whenever a process connects to one of the restricted hosts. The record +is deleted when the connection is completed. Obviously there is scope for +records to get left lying around if there is a system or program crash. To +guard against this, Exim ignores any records that are more than six hours old. + +If you set up this kind of serialization, you should also arrange to delete the +relevant hints database whenever your system reboots. The names of the files +start with misc and they are kept in the spool/db directory. There may be one +or two files, depending on the type of DBM in use. The same files are used for +ETRN serialization. + +See also the max_parallel generic transport option. + ++---------------------------------------------------+ +|size_addition|Use: smtp|Type: integer|Default: 1024| ++---------------------------------------------------+ + +If a remote SMTP server indicates that it supports the SIZE option of the MAIL +command, Exim uses this to pass over the message size at the start of an SMTP +transaction. It adds the value of size_addition to the value it sends, to allow +for headers and other text that may be added during delivery by configuration +options or in a transport filter. It may be necessary to increase this if a lot +of text is added to messages. + +Alternatively, if the value of size_addition is set negative, it disables the +use of the SIZE option altogether. + ++--------------------------------------------------+ +|socks_proxy|Use: smtp|Type: string*|Default: unset| ++--------------------------------------------------+ + +This option enables use of SOCKS proxies for connections made by the transport. +For details see section 58.2. + ++------------------------------------------------------+ +|tls_certificate|Use: smtp|Type: string*|Default: unset| ++------------------------------------------------------+ + +The value of this option must be the absolute path to a file which contains the +client's certificate, for possible use when sending a message over an encrypted +connection. The values of $host and $host_address are set to the name and +address of the server during the expansion. See chapter 42 for details of TLS. + +Note: This option must be set if you want Exim to be able to use a TLS +certificate when sending messages as a client. The global option of the same +name specifies the certificate for Exim as a server; it is not automatically +assumed that the same certificate should be used when Exim is operating as a +client. + ++----------------------------------------------+ +|tls_crl|Use: smtp|Type: string*|Default: unset| ++----------------------------------------------+ + +This option specifies a certificate revocation list. The expanded value must be +the name of a file that contains a CRL in PEM format. + ++-----------------------------------------------------+ +|tls_dh_min_bits|Use: smtp|Type: integer|Default: 1024| ++-----------------------------------------------------+ + +When establishing a TLS session, if a ciphersuite which uses Diffie-Hellman key +agreement is negotiated, the server will provide a large prime number for use. +This option establishes the minimum acceptable size of that number. If the +parameter offered by the server is too small, then the TLS handshake will fail. + +Only supported when using GnuTLS. + ++-----------------------------------------------------+ +|tls_privatekey|Use: smtp|Type: string*|Default: unset| ++-----------------------------------------------------+ + +The value of this option must be the absolute path to a file which contains the +client's private key. This is used when sending a message over an encrypted +connection using a client certificate. The values of $host and $host_address +are set to the name and address of the server during the expansion. If this +option is unset, or the expansion is forced to fail, or the result is an empty +string, the private key is assumed to be in the same file as the certificate. +See chapter 42 for details of TLS. + ++----------------------------------------------------------+ +|tls_require_ciphers|Use: smtp|Type: string*|Default: unset| ++----------------------------------------------------------+ + +The value of this option must be a list of permitted cipher suites, for use +when setting up an outgoing encrypted connection. (There is a global option of +the same name for controlling incoming connections.) The values of $host and +$host_address are set to the name and address of the server during the +expansion. See chapter 42 for details of TLS; note that this option is used in +different ways by OpenSSL and GnuTLS (see sections 42.4 and 42.5). For GnuTLS, +the order of the ciphers is a preference order. + ++----------------------------------------------+ +|tls_sni|Use: smtp|Type: string*|Default: unset| ++----------------------------------------------+ + +If this option is set then it sets the $tls_out_sni variable and causes any TLS +session to pass this value as the Server Name Indication extension to the +remote side, which can be used by the remote side to select an appropriate +certificate and private key for the session. + +See 42.10 for more information. + +Note that for OpenSSL, this feature requires a build of OpenSSL that supports +TLS extensions. + ++-----------------------------------------------------------+ +|tls_tempfail_tryclear|Use: smtp|Type: boolean|Default: true| ++-----------------------------------------------------------+ + +When the server host is not in hosts_require_tls, and there is a problem in +setting up a TLS session, this option determines whether or not Exim should try +to deliver the message unencrypted. If it is set false, delivery to the current +host is deferred; if there are other hosts, they are tried. If this option is +set true, Exim attempts to deliver unencrypted after a 4xx response to +STARTTLS. Also, if STARTTLS is accepted, but the subsequent TLS negotiation +fails, Exim closes the current connection (because it is in an unknown state), +opens a new one to the same host, and then tries the delivery in clear. + ++----------------------------------------------------------+ +|tls_try_verify_hosts|Use: smtp|Type: host list*|Default: *| ++----------------------------------------------------------+ + +This option gives a list of hosts for which, on encrypted connections, +certificate verification will be tried but need not succeed. The +tls_verify_certificates option must also be set. Note that unless the host is +in this list TLS connections will be denied to hosts using self-signed +certificates when tls_verify_certificates is matched. The +$tls_out_certificate_verified variable is set when certificate verification +succeeds. + ++---------------------------------------------------------------+ +|tls_verify_cert_hostnames|Use: smtp|Type: host list*|Default: *| ++---------------------------------------------------------------+ + +This option give a list of hosts for which, while verifying the server +certificate, checks will be included on the host name (note that this will +generally be the result of a DNS MX lookup) versus Subject and +Subject-Alternate-Name fields. Wildcard names are permitted limited to being +the initial component of a 3-or-more component FQDN. + +There is no equivalent checking on client certificates. + ++---------------------------------------------------------------+ +|tls_verify_certificates|Use: smtp|Type: string*|Default: system| ++---------------------------------------------------------------+ + +The value of this option must be either the word "system" or the absolute path +to a file or directory containing permitted certificates for servers, for use +when setting up an encrypted connection. + +The "system" value for the option will use a location compiled into the SSL +library. This is not available for GnuTLS versions preceding 3.0.20; a value of +"system" is taken as empty and an explicit location must be specified. + +The use of a directory for the option value is not available for GnuTLS +versions preceding 3.3.6 and a single file must be used. + +With OpenSSL the certificates specified explicitly either by file or directory +are added to those given by the system default location. + +The values of $host and $host_address are set to the name and address of the +server during the expansion of this option. See chapter 42 for details of TLS. + +For back-compatibility, if neither tls_verify_hosts nor tls_try_verify_hosts +are set (a single-colon empty list counts as being set) and certificate +verification fails the TLS connection is closed. + ++----------------------------------------------------------+ +|tls_verify_hosts|Use: smtp|Type: host list*|Default: unset| ++----------------------------------------------------------+ + +This option gives a list of hosts for which, on encrypted connections, +certificate verification must succeed. The tls_verify_certificates option must +also be set. If both this option and tls_try_verify_hosts are unset operation +is as if this option selected all hosts. + ++---------------------------------------------------------+ +|utf8_downconvert|Use: smtp|Type: integer!!|Default: unset| ++---------------------------------------------------------+ + +If built with internationalization support, this option controls conversion of +UTF-8 in message addresses to a-label form. For details see section 59.1. + + +30.5 How the limits for the number of hosts to try are used +----------------------------------------------------------- + +There are two options that are concerned with the number of hosts that are +tried when an SMTP delivery takes place. They are hosts_max_try and +hosts_max_try_hardlimit. + +The hosts_max_try option limits the number of hosts that are tried for a single +delivery. However, despite the term "host" in its name, the option actually +applies to each IP address independently. In other words, a multihomed host is +treated as several independent hosts, just as it is for retrying. + +Many of the larger ISPs have multiple MX records which often point to +multihomed hosts. As a result, a list of a dozen or more IP addresses may be +created as a result of routing one of these domains. + +Trying every single IP address on such a long list does not seem sensible; if +several at the top of the list fail, it is reasonable to assume there is some +problem that is likely to affect all of them. Roughly speaking, the value of +hosts_max_try is the maximum number that are tried before deferring the +delivery. However, the logic cannot be quite that simple. + +Firstly, IP addresses that are skipped because their retry times have not +arrived do not count, and in addition, addresses that are past their retry +limits are also not counted, even when they are tried. This means that when +some IP addresses are past their retry limits, more than the value of +hosts_max_retry may be tried. The reason for this behaviour is to ensure that +all IP addresses are considered before timing out an email address (but see +below for an exception). + +Secondly, when the hosts_max_try limit is reached, Exim looks down the host +list to see if there is a subsequent host with a different (higher valued) MX. +If there is, that host is considered next, and the current IP address is used +but not counted. This behaviour helps in the case of a domain with a retry rule +that hardly ever delays any hosts, as is now explained: + +Consider the case of a long list of hosts with one MX value, and a few with a +higher MX value. If hosts_max_try is small (the default is 5) only a few hosts +at the top of the list are tried at first. With the default retry rule, which +specifies increasing retry times, the higher MX hosts are eventually tried when +those at the top of the list are skipped because they have not reached their +retry times. + +However, it is common practice to put a fixed short retry time on domains for +large ISPs, on the grounds that their servers are rarely down for very long. +Unfortunately, these are exactly the domains that tend to resolve to long lists +of hosts. The short retry time means that the lowest MX hosts are tried every +time. The attempts may be in a different order because of random sorting, but +without the special MX check, the higher MX hosts would never be tried until +all the lower MX hosts had timed out (which might be several days), because +there are always some lower MX hosts that have reached their retry times. With +the special check, Exim considers at least one IP address from each MX value at +every delivery attempt, even if the hosts_max_try limit has already been +reached. + +The above logic means that hosts_max_try is not a hard limit, and in +particular, Exim normally eventually tries all the IP addresses before timing +out an email address. When hosts_max_try was implemented, this seemed a +reasonable thing to do. Recently, however, some lunatic DNS configurations have +been set up with hundreds of IP addresses for some domains. It can take a very +long time indeed for an address to time out in these cases. + +The hosts_max_try_hardlimit option was added to help with this problem. Exim +never tries more than this number of IP addresses; if it hits this limit and +they are all timed out, the email address is bounced, even though not all +possible IP addresses have been tried. + + + +=============================================================================== +31. ADDRESS REWRITING + +There are some circumstances in which Exim automatically rewrites domains in +addresses. The two most common are when an address is given without a domain +(referred to as an "unqualified address") or when an address contains an +abbreviated domain that is expanded by DNS lookup. + +Unqualified envelope addresses are accepted only for locally submitted +messages, or for messages that are received from hosts matching +sender_unqualified_hosts or recipient_unqualified_hosts, as appropriate. +Unqualified addresses in header lines are qualified if they are in locally +submitted messages, or messages from hosts that are permitted to send +unqualified envelope addresses. Otherwise, unqualified addresses in header +lines are neither qualified nor rewritten. + +One situation in which Exim does not automatically rewrite a domain is when it +is the name of a CNAME record in the DNS. The older RFCs suggest that such a +domain should be rewritten using the "canonical" name, and some MTAs do this. +The new RFCs do not contain this suggestion. + + +31.1 Explicitly configured address rewriting +-------------------------------------------- + +This chapter describes the rewriting rules that can be used in the main rewrite +section of the configuration file, and also in the generic headers_rewrite +option that can be set on any transport. + +Some people believe that configured address rewriting is a Mortal Sin. Others +believe that life is not possible without it. Exim provides the facility; you +do not have to use it. + +The main rewriting rules that appear in the "rewrite" section of the +configuration file are applied to addresses in incoming messages, both envelope +addresses and addresses in header lines. Each rule specifies the types of +address to which it applies. + +Whether or not addresses in header lines are rewritten depends on the origin of +the headers and the type of rewriting. Global rewriting, that is, rewriting +rules from the rewrite section of the configuration file, is applied only to +those headers that were received with the message. Header lines that are added +by ACLs or by a system filter or by individual routers or transports (which are +specific to individual recipient addresses) are not rewritten by the global +rules. + +Rewriting at transport time, by means of the headers_rewrite option, applies +all headers except those added by routers and transports. That is, as well as +the headers that were received with the message, it also applies to headers +that were added by an ACL or a system filter. + +In general, rewriting addresses from your own system or domain has some +legitimacy. Rewriting other addresses should be done only with great care and +in special circumstances. The author of Exim believes that rewriting should be +used sparingly, and mainly for "regularizing" addresses in your own domains. +Although it can sometimes be used as a routing tool, this is very strongly +discouraged. + +There are two commonly encountered circumstances where rewriting is used, as +illustrated by these examples: + + * The company whose domain is hitch.fict.example has a number of hosts that + exchange mail with each other behind a firewall, but there is only a single + gateway to the outer world. The gateway rewrites *.hitch.fict.example as + hitch.fict.example when sending mail off-site. + + * A host rewrites the local parts of its own users so that, for example, + fp42@hitch.fict.example becomes Ford.Prefect@hitch.fict.example. + + +31.2 When does rewriting happen? +-------------------------------- + +Configured address rewriting can take place at several different stages of a +message's processing. + +At the start of an ACL for MAIL, the sender address may have been rewritten by +a special SMTP-time rewrite rule (see section 31.9), but no ordinary rewrite +rules have yet been applied. If, however, the sender address is verified in the +ACL, it is rewritten before verification, and remains rewritten thereafter. The +subsequent value of $sender_address is the rewritten address. This also applies +if sender verification happens in a RCPT ACL. Otherwise, when the sender +address is not verified, it is rewritten as soon as a message's header lines +have been received. + +Similarly, at the start of an ACL for RCPT, the current recipient's address may +have been rewritten by a special SMTP-time rewrite rule, but no ordinary +rewrite rules have yet been applied to it. However, the behaviour is different +from the sender address when a recipient is verified. The address is rewritten +for the verification, but the rewriting is not remembered at this stage. The +value of $local_part and $domain after verification are always the same as they +were before (that is, they contain the unrewritten - except for SMTP-time +rewriting - address). + +As soon as a message's header lines have been received, all the envelope +recipient addresses are permanently rewritten, and rewriting is also applied to +the addresses in the header lines (if configured). This happens before adding +any header lines that were specified in MAIL or RCPT ACLs, and before the DATA +ACL and local_scan() functions are run. + +When an address is being routed, either for delivery or for verification, +rewriting is applied immediately to child addresses that are generated by +redirection, unless no_rewrite is set on the router. + +At transport time, additional rewriting of addresses in header lines can be +specified by setting the generic headers_rewrite option on a transport. This +option contains rules that are identical in form to those in the rewrite +section of the configuration file. They are applied to the original message +header lines and any that were added by ACLs or a system filter. They are not +applied to header lines that are added by routers or the transport. + +The outgoing envelope sender can be rewritten by means of the return_path +transport option. However, it is not possible to rewrite envelope recipients at +transport time. + + +31.3 Testing the rewriting rules that apply on input +---------------------------------------------------- + +Exim's input rewriting configuration appears in a part of the runtime +configuration file headed by "begin rewrite". It can be tested by the -brw +command line option. This takes an address (which can be a full RFC 2822 +address) as its argument. The output is a list of how the address would be +transformed by the rewriting rules for each of the different places it might +appear in an incoming message, that is, for each different header and for the +envelope sender and recipient fields. For example, + +exim -brw ph10@exim.workshop.example + +might produce the output + +sender: Philip.Hazel@exim.workshop.example +from: Philip.Hazel@exim.workshop.example +to: ph10@exim.workshop.example +cc: ph10@exim.workshop.example +bcc: ph10@exim.workshop.example +reply-to: Philip.Hazel@exim.workshop.example +env-from: Philip.Hazel@exim.workshop.example +env-to: ph10@exim.workshop.example + +which shows that rewriting has been set up for that address when used in any of +the source fields, but not when it appears as a recipient address. At the +present time, there is no equivalent way of testing rewriting rules that are +set for a particular transport. + + +31.4 Rewriting rules +-------------------- + +The rewrite section of the configuration file consists of lines of rewriting +rules in the form + +<source pattern> <replacement> <flags> + +Rewriting rules that are specified for the headers_rewrite generic transport +option are given as a colon-separated list. Each item in the list takes the +same form as a line in the main rewriting configuration (except that any colons +must be doubled, of course). + +The formats of source patterns and replacement strings are described below. +Each is terminated by white space, unless enclosed in double quotes, in which +case normal quoting conventions apply inside the quotes. The flags are single +characters which may appear in any order. Spaces and tabs between them are +ignored. + +For each address that could potentially be rewritten, the rules are scanned in +order, and replacements for the address from earlier rules can themselves be +replaced by later rules (but see the "q" and "R" flags). + +The order in which addresses are rewritten is undefined, may change between +releases, and must not be relied on, with one exception: when a message is +received, the envelope sender is always rewritten first, before any header +lines are rewritten. For example, the replacement string for a rewrite of an +address in To: must not assume that the message's address in From: has (or has +not) already been rewritten. However, a rewrite of From: may assume that the +envelope sender has already been rewritten. + +The variables $local_part and $domain can be used in the replacement string to +refer to the address that is being rewritten. Note that lookup-driven rewriting +can be done by a rule of the form + +*@* ${lookup ... + +where the lookup key uses $1 and $2 or $local_part and $domain to refer to the +address that is being rewritten. + + +31.5 Rewriting patterns +----------------------- + +The source pattern in a rewriting rule is any item which may appear in an +address list (see section 10.19). It is in fact processed as a single-item +address list, which means that it is expanded before being tested against the +address. As always, if you use a regular expression as a pattern, you must take +care to escape dollar and backslash characters, or use the "\N" facility to +suppress string expansion within the regular expression. + +Domains in patterns should be given in lower case. Local parts in patterns are +case-sensitive. If you want to do case-insensitive matching of local parts, you +can use a regular expression that starts with "^(?i)". + +After matching, the numerical variables $1, $2, etc. may be set, depending on +the type of match which occurred. These can be used in the replacement string +to insert portions of the incoming address. $0 always refers to the complete +incoming address. When a regular expression is used, the numerical variables +are set from its capturing subexpressions. For other types of pattern they are +set as follows: + + * If a local part or domain starts with an asterisk, the numerical variables + refer to the character strings matched by asterisks, with $1 associated + with the first asterisk, and $2 with the second, if present. For example, + if the pattern + + *queen@*.fict.example + + is matched against the address hearts-queen@wonderland.fict.example then + + $0 = hearts-queen@wonderland.fict.example + $1 = hearts- + $2 = wonderland + + Note that if the local part does not start with an asterisk, but the domain + does, it is $1 that contains the wild part of the domain. + + * If the domain part of the pattern is a partial lookup, the wild and fixed + parts of the domain are placed in the next available numerical variables. + Suppose, for example, that the address foo@bar.baz.example is processed by + a rewriting rule of the form + + *@partial-dbm;/some/dbm/file <replacement string> + + and the key in the file that matches the domain is "*.baz.example". Then + + $1 = foo + $2 = bar + $3 = baz.example + + If the address foo@baz.example is looked up, this matches the same wildcard + file entry, and in this case $2 is set to the empty string, but $3 is still + set to baz.example. If a non-wild key is matched in a partial lookup, $2 is + again set to the empty string and $3 is set to the whole domain. For + non-partial domain lookups, no numerical variables are set. + + +31.6 Rewriting replacements +--------------------------- + +If the replacement string for a rule is a single asterisk, addresses that match +the pattern and the flags are not rewritten, and no subsequent rewriting rules +are scanned. For example, + +hatta@lookingglass.fict.example * f + +specifies that hatta@lookingglass.fict.example is never to be rewritten in +From: headers. + +If the replacement string is not a single asterisk, it is expanded, and must +yield a fully qualified address. Within the expansion, the variables +$local_part and $domain refer to the address that is being rewritten. Any +letters they contain retain their original case - they are not lower cased. The +numerical variables are set up according to the type of pattern that matched +the address, as described above. If the expansion is forced to fail by the +presence of "fail" in a conditional or lookup item, rewriting by the current +rule is abandoned, but subsequent rules may take effect. Any other expansion +failure causes the entire rewriting operation to be abandoned, and an entry +written to the panic log. + + +31.7 Rewriting flags +-------------------- + +There are three different kinds of flag that may appear on rewriting rules: + + * Flags that specify which headers and envelope addresses to rewrite: E, F, + T, b, c, f, h, r, s, t. + + * A flag that specifies rewriting at SMTP time: S. + + * Flags that control the rewriting process: Q, q, R, w. + +For rules that are part of the headers_rewrite generic transport option, E, F, +T, and S are not permitted. + + +31.8 Flags specifying which headers and envelope addresses to rewrite +--------------------------------------------------------------------- + +If none of the following flag letters, nor the "S" flag (see section 31.9) are +present, a main rewriting rule applies to all headers and to both the sender +and recipient fields of the envelope, whereas a transport-time rewriting rule +just applies to all headers. Otherwise, the rewriting rule is skipped unless +the relevant addresses are being processed. + +E rewrite all envelope fields +F rewrite the envelope From field +T rewrite the envelope To field +b rewrite the Bcc: header +c rewrite the Cc: header +f rewrite the From: header +h rewrite all headers +r rewrite the Reply-To: header +s rewrite the Sender: header +t rewrite the To: header + +"All headers" means all of the headers listed above that can be selected +individually, plus their Resent- versions. It does not include other headers +such as Subject: etc. + +You should be particularly careful about rewriting Sender: headers, and +restrict this to special known cases in your own domains. + + +31.9 The SMTP-time rewriting flag +--------------------------------- + +The rewrite flag "S" specifies a rewrite of incoming envelope addresses at SMTP +time, as soon as an address is received in a MAIL or RCPT command, and before +any other processing; even before syntax checking. The pattern is required to +be a regular expression, and it is matched against the whole of the data for +the command, including any surrounding angle brackets. + +This form of rewrite rule allows for the handling of addresses that are not +compliant with RFCs 2821 and 2822 (for example, "bang paths" in batched SMTP +input). Because the input is not required to be a syntactically valid address, +the variables $local_part and $domain are not available during the expansion of +the replacement string. The result of rewriting replaces the original address +in the MAIL or RCPT command. + + +31.10 Flags controlling the rewriting process +--------------------------------------------- + +There are four flags which control the way the rewriting process works. These +take effect only when a rule is invoked, that is, when the address is of the +correct type (matches the flags) and matches the pattern: + + * If the "Q" flag is set on a rule, the rewritten address is permitted to be + an unqualified local part. It is qualified with qualify_recipient. In the + absence of "Q" the rewritten address must always include a domain. + + * If the "q" flag is set on a rule, no further rewriting rules are + considered, even if no rewriting actually takes place because of a "fail" + in the expansion. The "q" flag is not effective if the address is of the + wrong type (does not match the flags) or does not match the pattern. + + * The "R" flag causes a successful rewriting rule to be re-applied to the new + address, up to ten times. It can be combined with the "q" flag, to stop + rewriting once it fails to match (after at least one successful rewrite). + + * When an address in a header is rewritten, the rewriting normally applies + only to the working part of the address, with any comments and RFC 2822 + "phrase" left unchanged. For example, rewriting might change + + From: Ford Prefect <fp42@restaurant.hitch.fict.example> + + into + + From: Ford Prefect <prefectf@hitch.fict.example> + + Sometimes there is a need to replace the whole address item, and this can + be done by adding the flag letter "w" to a rule. If this is set on a rule + that causes an address in a header line to be rewritten, the entire address + is replaced, not just the working part. The replacement must be a complete + RFC 2822 address, including the angle brackets if necessary. If text + outside angle brackets contains a character whose value is greater than 126 + or less than 32 (except for tab), the text is encoded according to RFC + 2047. The character set is taken from headers_charset, which gets its + default at build time. + + When the "w" flag is set on a rule that causes an envelope address to be + rewritten, all but the working part of the replacement address is + discarded. + + +31.11 Rewriting examples +------------------------ + +Here is an example of the two common rewriting paradigms: + +*@*.hitch.fict.example $1@hitch.fict.example +*@hitch.fict.example ${lookup{$1}dbm{/etc/realnames}\ + {$value}fail}@hitch.fict.example bctfrF + +Note the use of "fail" in the lookup expansion in the second rule, forcing the +string expansion to fail if the lookup does not succeed. In this context it has +the effect of leaving the original address unchanged, but Exim goes on to +consider subsequent rewriting rules, if any, because the "q" flag is not +present in that rule. An alternative to "fail" would be to supply $1 +explicitly, which would cause the rewritten address to be the same as before, +at the cost of a small bit of processing. Not supplying either of these is an +error, since the rewritten address would then contain no local part. + +The first example above replaces the domain with a superior, more general +domain. This may not be desirable for certain local parts. If the rule + +root@*.hitch.fict.example * + +were inserted before the first rule, rewriting would be suppressed for the +local part root at any domain ending in hitch.fict.example. + +Rewriting can be made conditional on a number of tests, by making use of ${if +in the expansion item. For example, to apply a rewriting rule only to messages +that originate outside the local host: + +*@*.hitch.fict.example "${if !eq {$sender_host_address}{}\ + {$1@hitch.fict.example}fail}" + +The replacement string is quoted in this example because it contains white +space. + +Exim does not handle addresses in the form of "bang paths". If it sees such an +address it treats it as an unqualified local part which it qualifies with the +local qualification domain (if the source of the message is local or if the +remote host is permitted to send unqualified addresses). Rewriting can +sometimes be used to handle simple bang paths with a fixed number of +components. For example, the rule + +\N^([^!]+)!(.*)@your.domain.example$\N $2@$1 + +rewrites a two-component bang path host.name!user as the domain address +user@host.name. However, there is a security implication in using this as a +global rewriting rule for envelope addresses. It can provide a backdoor method +for using your system as a relay, because the incoming addresses appear to be +local. If the bang path addresses are received via SMTP, it is safer to use the +"S" flag to rewrite them as they are received, so that relay checking can be +done on the rewritten addresses. + + + +=============================================================================== +32. RETRY CONFIGURATION + +The "retry" section of the runtime configuration file contains a list of retry +rules that control how often Exim tries to deliver messages that cannot be +delivered at the first attempt. If there are no retry rules (the section is +empty or not present), there are no retries. In this situation, temporary +errors are treated as permanent. The default configuration contains a single, +general-purpose retry rule (see section 7.6). The -brt command line option can +be used to test which retry rule will be used for a given address, domain and +error. + +The most common cause of retries is temporary failure to deliver to a remote +host because the host is down, or inaccessible because of a network problem. +Exim's retry processing in this case is applied on a per-host (strictly, per IP +address) basis, not on a per-message basis. Thus, if one message has recently +been delayed, delivery of a new message to the same host is not immediately +tried, but waits for the host's retry time to arrive. If the retry_defer log +selector is set, the message "retry time not reached" is written to the main +log whenever a delivery is skipped for this reason. Section 48.2 contains more +details of the handling of errors during remote deliveries. + +Retry processing applies to routing as well as to delivering, except as covered +in the next paragraph. The retry rules do not distinguish between these +actions. It is not possible, for example, to specify different behaviour for +failures to route the domain snark.fict.example and failures to deliver to the +host snark.fict.example. I didn't think anyone would ever need this added +complication, so did not implement it. However, although they share the same +retry rule, the actual retry times for routing and transporting a given domain +are maintained independently. + +When a delivery is not part of a queue run (typically an immediate delivery on +receipt of a message), the routers are always run, and local deliveries are +always attempted, even if retry times are set for them. This makes for better +behaviour if one particular message is causing problems (for example, causing +quota overflow, or provoking an error in a filter file). If such a delivery +suffers a temporary failure, the retry data is updated as normal, and +subsequent delivery attempts from queue runs occur only when the retry time for +the local address is reached. + + +32.1 Changing retry rules +------------------------- + +If you change the retry rules in your configuration, you should consider +whether or not to delete the retry data that is stored in Exim's spool area in +files with names like db/retry. Deleting any of Exim's hints files is always +safe; that is why they are called "hints". + +The hints retry data contains suggested retry times based on the previous +rules. In the case of a long-running problem with a remote host, it might +record the fact that the host has timed out. If your new rules increase the +timeout time for such a host, you should definitely remove the old retry data +and let Exim recreate it, based on the new rules. Otherwise Exim might bounce +messages that it should now be retaining. + + +32.2 Format of retry rules +-------------------------- + +Each retry rule occupies one line and consists of three or four parts, +separated by white space: a pattern, an error name, an optional list of sender +addresses, and a list of retry parameters. The pattern and sender lists must be +enclosed in double quotes if they contain white space. The rules are searched +in order until one is found where the pattern, error name, and sender list (if +present) match the failing host or address, the error that occurred, and the +message's sender, respectively. + +The pattern is any single item that may appear in an address list (see section +10.19). It is in fact processed as a one-item address list, which means that it +is expanded before being tested against the address that has been delayed. A +negated address list item is permitted. Address list processing treats a plain +domain name as if it were preceded by "*@", which makes it possible for many +retry rules to start with just a domain. For example, + +lookingglass.fict.example * F,24h,30m; + +provides a rule for any address in the lookingglass.fict.example domain, +whereas + +alice@lookingglass.fict.example * F,24h,30m; + +applies only to temporary failures involving the local part alice. In practice, +almost all rules start with a domain name pattern without a local part. + +Warning: If you use a regular expression in a retry rule pattern, it must match +a complete address, not just a domain, because that is how regular expressions +work in address lists. + +^\Nxyz\d+\.abc\.example$\N * G,1h,10m,2 Wrong +^\N[^@]+@xyz\d+\.abc\.example$\N * G,1h,10m,2 Right + + +32.3 Choosing which retry rule to use for address errors +-------------------------------------------------------- + +When Exim is looking for a retry rule after a routing attempt has failed (for +example, after a DNS timeout), each line in the retry configuration is tested +against the complete address only if retry_use_local_part is set for the +router. Otherwise, only the domain is used, except when matching against a +regular expression, when the local part of the address is replaced with "*". A +domain on its own can match a domain pattern, or a pattern that starts with +"*@". By default, retry_use_local_part is true for routers where +check_local_user is true, and false for other routers. + +Similarly, when Exim is looking for a retry rule after a local delivery has +failed (for example, after a mailbox full error), each line in the retry +configuration is tested against the complete address only if +retry_use_local_part is set for the transport (it defaults true for all local +transports). + +However, when Exim is looking for a retry rule after a remote delivery attempt +suffers an address error (a 4xx SMTP response for a recipient address), the +whole address is always used as the key when searching the retry rules. The +rule that is found is used to create a retry time for the combination of the +failing address and the message's sender. It is the combination of sender and +recipient that is delayed in subsequent queue runs until its retry time is +reached. You can delay the recipient without regard to the sender by setting +address_retry_include_sender false in the smtp transport but this can lead to +problems with servers that regularly issue 4xx responses to RCPT commands. + + +32.4 Choosing which retry rule to use for host and message errors +----------------------------------------------------------------- + +For a temporary error that is not related to an individual address (for +example, a connection timeout), each line in the retry configuration is checked +twice. First, the name of the remote host is used as a domain name (preceded by +"*@" when matching a regular expression). If this does not match the line, the +domain from the email address is tried in a similar fashion. For example, +suppose the MX records for a.b.c.example are + +a.b.c.example MX 5 x.y.z.example + MX 6 p.q.r.example + MX 7 m.n.o.example + +and the retry rules are + +p.q.r.example * F,24h,30m; +a.b.c.example * F,4d,45m; + +and a delivery to the host x.y.z.example suffers a connection failure. The +first rule matches neither the host nor the domain, so Exim looks at the second +rule. This does not match the host, but it does match the domain, so it is used +to calculate the retry time for the host x.y.z.example. Meanwhile, Exim tries +to deliver to p.q.r.example. If this also suffers a host error, the first retry +rule is used, because it matches the host. + +In other words, temporary failures to deliver to host p.q.r.example use the +first rule to determine retry times, but for all the other hosts for the domain +a.b.c.example, the second rule is used. The second rule is also used if routing +to a.b.c.example suffers a temporary failure. + +Note: The host name is used when matching the patterns, not its IP address. +However, if a message is routed directly to an IP address without the use of a +host name, for example, if a manualroute router contains a setting such as: + +route_list = *.a.example 192.168.34.23 + +then the "host name" that is used when searching for a retry rule is the +textual form of the IP address. + + +32.5 Retry rules for specific errors +------------------------------------ + +The second field in a retry rule is the name of a particular error, or an +asterisk, which matches any error. The errors that can be tested for are: + +auth_failed + + Authentication failed when trying to send to a host in the + hosts_require_auth list in an smtp transport. + +data_4xx + + A 4xx error was received for an outgoing DATA command, either immediately + after the command, or after sending the message's data. + +mail_4xx + + A 4xx error was received for an outgoing MAIL command. + +rcpt_4xx + + A 4xx error was received for an outgoing RCPT command. + +For the three 4xx errors, either the first or both of the x's can be given as +specific digits, for example: "mail_45x" or "rcpt_436". For example, to +recognize 452 errors given to RCPT commands for addresses in a certain domain, +and have retries every ten minutes with a one-hour timeout, you could set up a +retry rule of this form: + +the.domain.name rcpt_452 F,1h,10m + +These errors apply to both outgoing SMTP (the smtp transport) and outgoing LMTP +(either the lmtp transport, or the smtp transport in LMTP mode). + +lost_connection + + A server unexpectedly closed the SMTP connection. There may, of course, + legitimate reasons for this (host died, network died), but if it repeats a + lot for the same host, it indicates something odd. + +lookup + + A DNS lookup for a host failed. Note that a dnslookup router will need to + have matched its fail_defer_domains option for this retry type to be + usable. Also note that a manualroute router will probably need its + host_find_failed option set to defer. + +refused_MX + + A connection to a host obtained from an MX record was refused. + +refused_A + + A connection to a host not obtained from an MX record was refused. + +refused + + A connection was refused. + +timeout_connect_MX + + A connection attempt to a host obtained from an MX record timed out. + +timeout_connect_A + + A connection attempt to a host not obtained from an MX record timed out. + +timeout_connect + + A connection attempt timed out. + +timeout_MX + + There was a timeout while connecting or during an SMTP session with a host + obtained from an MX record. + +timeout_A + + There was a timeout while connecting or during an SMTP session with a host + not obtained from an MX record. + +timeout + + There was a timeout while connecting or during an SMTP session. + +tls_required + + The server was required to use TLS (it matched hosts_require_tls in the + smtp transport), but either did not offer TLS, or it responded with 4xx to + STARTTLS, or there was a problem setting up the TLS connection. + +quota + + A mailbox quota was exceeded in a local delivery by the appendfile + transport. + +quota_<time> + + A mailbox quota was exceeded in a local delivery by the appendfile + transport, and the mailbox has not been accessed for <time>. For example, + quota_4d applies to a quota error when the mailbox has not been accessed + for four days. + +The idea of quota_<time> is to make it possible to have shorter timeouts when +the mailbox is full and is not being read by its owner. Ideally, it should be +based on the last time that the user accessed the mailbox. However, it is not +always possible to determine this. Exim uses the following heuristic rules: + + * If the mailbox is a single file, the time of last access (the "atime") is + used. As no new messages are being delivered (because the mailbox is over + quota), Exim does not access the file, so this is the time of last user + access. + + * For a maildir delivery, the time of last modification of the new + subdirectory is used. As the mailbox is over quota, no new files are + created in the new subdirectory, because no new messages are being + delivered. Any change to the new subdirectory is therefore assumed to be + the result of an MUA moving a new message to the cur directory when it is + first read. The time that is used is therefore the last time that the user + read a new message. + + * For other kinds of multi-file mailbox, the time of last access cannot be + obtained, so a retry rule that uses this type of error field is never + matched. + +The quota errors apply both to system-enforced quotas and to Exim's own quota +mechanism in the appendfile transport. The quota error also applies when a +local delivery is deferred because a partition is full (the ENOSPC error). + + +32.6 Retry rules for specified senders +-------------------------------------- + +You can specify retry rules that apply only when the failing message has a +specific sender. In particular, this can be used to define retry rules that +apply only to bounce messages. The third item in a retry rule can be of this +form: + +senders=<address list> + +The retry timings themselves are then the fourth item. For example: + +* rcpt_4xx senders=: F,1h,30m + +matches recipient 4xx errors for bounce messages sent to any address at any +host. If the address list contains white space, it must be enclosed in quotes. +For example: + +a.domain rcpt_452 senders="xb.dom : yc.dom" G,8h,10m,1.5 + +Warning: This facility can be unhelpful if it is used for host errors (which do +not depend on the recipient). The reason is that the sender is used only to +match the retry rule. Once the rule has been found for a host error, its +contents are used to set a retry time for the host, and this will apply to all +messages, not just those with specific senders. + +When testing retry rules using -brt, you can supply a sender using the -f +command line option, like this: + +exim -f "" -brt user@dom.ain + +If you do not set -f with -brt, a retry rule that contains a senders list is +never matched. + + +32.7 Retry parameters +--------------------- + +The third (or fourth, if a senders list is present) field in a retry rule is a +sequence of retry parameter sets, separated by semicolons. Each set consists of + +<letter>,<cutoff time>,<arguments> + +The letter identifies the algorithm for computing a new retry time; the cutoff +time is the time beyond which this algorithm no longer applies, and the +arguments vary the algorithm's action. The cutoff time is measured from the +time that the first failure for the domain (combined with the local part if +relevant) was detected, not from the time the message was received. + +The available algorithms are: + + * F: retry at fixed intervals. There is a single time parameter specifying + the interval. + + * G: retry at geometrically increasing intervals. The first argument + specifies a starting value for the interval, and the second a multiplier, + which is used to increase the size of the interval at each retry. + + * H: retry at randomized intervals. The arguments are as for G. For each + retry, the previous interval is multiplied by the factor in order to get a + maximum for the next interval. The minimum interval is the first argument + of the parameter, and an actual interval is chosen randomly between them. + Such a rule has been found to be helpful in cluster configurations when all + the members of the cluster restart at once, and may therefore synchronize + their queue processing times. + +When computing the next retry time, the algorithm definitions are scanned in +order until one whose cutoff time has not yet passed is reached. This is then +used to compute a new retry time that is later than the current time. In the +case of fixed interval retries, this simply means adding the interval to the +current time. For geometrically increasing intervals, retry intervals are +computed from the rule's parameters until one that is greater than the previous +interval is found. The main configuration variable retry_interval_max limits +the maximum interval between retries. It cannot be set greater than "24h", +which is its default value. + +A single remote domain may have a number of hosts associated with it, and each +host may have more than one IP address. Retry algorithms are selected on the +basis of the domain name, but are applied to each IP address independently. If, +for example, a host has two IP addresses and one is unusable, Exim will +generate retry times for it and will not try to use it until its next retry +time comes. Thus the good IP address is likely to be tried first most of the +time. + +Retry times are hints rather than promises. Exim does not make any attempt to +run deliveries exactly at the computed times. Instead, a queue runner process +starts delivery processes for delayed messages periodically, and these attempt +new deliveries only for those addresses that have passed their next retry time. +If a new message arrives for a deferred address, an immediate delivery attempt +occurs only if the address has passed its retry time. In the absence of new +messages, the minimum time between retries is the interval between queue runner +processes. There is not much point in setting retry times of five minutes if +your queue runners happen only once an hour, unless there are a significant +number of incoming messages (which might be the case on a system that is +sending everything to a smart host, for example). + +The data in the retry hints database can be inspected by using the exim_dumpdb +or exim_fixdb utility programs (see chapter 53). The latter utility can also be +used to change the data. The exinext utility script can be used to find out +what the next retry times are for the hosts associated with a particular mail +domain, and also for local deliveries that have been deferred. + + +32.8 Retry rule examples +------------------------ + +Here are some example retry rules: + +alice@wonderland.fict.example quota_5d F,7d,3h +wonderland.fict.example quota_5d +wonderland.fict.example * F,1h,15m; G,2d,1h,2; +lookingglass.fict.example * F,24h,30m; +* refused_A F,2h,20m; +* * F,2h,15m; G,16h,1h,1.5; F,5d,8h + +The first rule sets up special handling for mail to +alice@wonderland.fict.example when there is an over-quota error and the mailbox +has not been read for at least 5 days. Retries continue every three hours for 7 +days. The second rule handles over-quota errors for all other local parts at +wonderland.fict.example; the absence of a local part has the same effect as +supplying "*@". As no retry algorithms are supplied, messages that fail are +bounced immediately if the mailbox has not been read for at least 5 days. + +The third rule handles all other errors at wonderland.fict.example; retries +happen every 15 minutes for an hour, then with geometrically increasing +intervals until two days have passed since a delivery first failed. After the +first hour there is a delay of one hour, then two hours, then four hours, and +so on (this is a rather extreme example). + +The fourth rule controls retries for the domain lookingglass.fict.example. They +happen every 30 minutes for 24 hours only. The remaining two rules handle all +other domains, with special action for connection refusal from hosts that were +not obtained from an MX record. + +The final rule in a retry configuration should always have asterisks in the +first two fields so as to provide a general catch-all for any addresses that do +not have their own special handling. This example tries every 15 minutes for 2 +hours, then with intervals starting at one hour and increasing by a factor of +1.5 up to 16 hours, then every 8 hours up to 5 days. + + +32.9 Timeout of retry data +-------------------------- + +Exim timestamps the data that it writes to its retry hints database. When it +consults the data during a delivery it ignores any that is older than the value +set in retry_data_expire (default 7 days). If, for example, a host hasn't been +tried for 7 days, Exim will try to deliver to it immediately a message arrives, +and if that fails, it will calculate a retry time as if it were failing for the +first time. + +This improves the behaviour for messages routed to rarely-used hosts such as MX +backups. If such a host was down at one time, and happens to be down again when +Exim tries a month later, using the old retry data would imply that it had been +down all the time, which is not a justified assumption. + +If a host really is permanently dead, this behaviour causes a burst of retries +every now and again, but only if messages routed to it are rare. If there is a +message at least once every 7 days the retry data never expires. + + +32.10 Long-term failures +------------------------ + +Special processing happens when an email address has been failing for so long +that the cutoff time for the last algorithm is reached. For example, using the +default retry rule: + +* * F,2h,15m; G,16h,1h,1.5; F,4d,6h + +the cutoff time is four days. Reaching the retry cutoff is independent of how +long any specific message has been failing; it is the length of continuous +failure for the recipient address that counts. + +When the cutoff time is reached for a local delivery, or for all the IP +addresses associated with a remote delivery, a subsequent delivery failure +causes Exim to give up on the address, and a bounce message is generated. In +order to cater for new messages that use the failing address, a next retry time +is still computed from the final algorithm, and is used as follows: + +For local deliveries, one delivery attempt is always made for any subsequent +messages. If this delivery fails, the address fails immediately. The +post-cutoff retry time is not used. + +If the delivery is remote, there are two possibilities, controlled by the +delay_after_cutoff option of the smtp transport. The option is true by default. +Until the post-cutoff retry time for one of the IP addresses, as set by the +retry_data_expire option, is reached, the failing email address is bounced +immediately, without a delivery attempt taking place. After that time, one new +delivery attempt is made to those IP addresses that are past their retry times, +and if that still fails, the address is bounced and new retry times are +computed. + +In other words, when all the hosts for a given email address have been failing +for a long time, Exim bounces rather then defers until one of the hosts' retry +times is reached. Then it tries once, and bounces if that attempt fails. This +behaviour ensures that few resources are wasted in repeatedly trying to deliver +to a broken destination, but if the host does recover, Exim will eventually +notice. + +If delay_after_cutoff is set false, Exim behaves differently. If all IP +addresses are past their final cutoff time, Exim tries to deliver to those IP +addresses that have not been tried since the message arrived. If there are no +suitable IP addresses, or if they all fail, the address is bounced. In other +words, it does not delay when a new message arrives, but tries the expired +addresses immediately, unless they have been tried since the message arrived. +If there is a continuous stream of messages for the failing domains, setting +delay_after_cutoff false means that there will be many more attempts to deliver +to permanently failing IP addresses than when delay_after_cutoff is true. + + +32.11 Deliveries that work intermittently +----------------------------------------- + +Some additional logic is needed to cope with cases where a host is +intermittently available, or when a message has some attribute that prevents +its delivery when others to the same address get through. In this situation, +because some messages are successfully delivered, the "retry clock" for the +host or address keeps getting reset by the successful deliveries, and so +failing messages remain in the queue for ever because the cutoff time is never +reached. + +Two exceptional actions are applied to prevent this happening. The first +applies to errors that are related to a message rather than a remote host. +Section 48.2 has a discussion of the different kinds of error; examples of +message-related errors are 4xx responses to MAIL or DATA commands, and quota +failures. For this type of error, if a message's arrival time is earlier than +the "first failed" time for the error, the earlier time is used when scanning +the retry rules to decide when to try next and when to time out the address. + +The exceptional second action applies in all cases. If a message has been on +the queue for longer than the cutoff time of any applicable retry rule for a +given address, a delivery is attempted for that address, even if it is not yet +time, and if this delivery fails, the address is timed out. A new retry time is +not computed in this case, so that other messages for the same address are +considered immediately. + + + +=============================================================================== +33. SMTP AUTHENTICATION + +The "authenticators" section of Exim's runtime configuration is concerned with +SMTP authentication. This facility is an extension to the SMTP protocol, +described in RFC 2554, which allows a client SMTP host to authenticate itself +to a server. This is a common way for a server to recognize clients that are +permitted to use it as a relay. SMTP authentication is not of relevance to the +transfer of mail between servers that have no managerial connection with each +other. + +Very briefly, the way SMTP authentication works is as follows: + + * The server advertises a number of authentication mechanisms in response to + the client's EHLO command. + + * The client issues an AUTH command, naming a specific mechanism. The command + may, optionally, contain some authentication data. + + * The server may issue one or more challenges, to which the client must send + appropriate responses. In simple authentication mechanisms, the challenges + are just prompts for user names and passwords. The server does not have to + issue any challenges - in some mechanisms the relevant data may all be + transmitted with the AUTH command. + + * The server either accepts or denies authentication. + + * If authentication succeeds, the client may optionally make use of the AUTH + option on the MAIL command to pass an authenticated sender in subsequent + mail transactions. Authentication lasts for the remainder of the SMTP + connection. + + * If authentication fails, the client may give up, or it may try a different + authentication mechanism, or it may try transferring mail over the + unauthenticated connection. + +If you are setting up a client, and want to know which authentication +mechanisms the server supports, you can use Telnet to connect to port 25 (the +SMTP port) on the server, and issue an EHLO command. The response to this +includes the list of supported mechanisms. For example: + +$ telnet server.example 25 +Trying 192.168.34.25... +Connected to server.example. +Escape character is '^]'. +220 server.example ESMTP Exim 4.20 ... +ehlo client.example +250-server.example Hello client.example [10.8.4.5] +250-SIZE 52428800 +250-PIPELINING +250-AUTH PLAIN +250 HELP + +The second-last line of this example output shows that the server supports +authentication using the PLAIN mechanism. In Exim, the different authentication +mechanisms are configured by specifying authenticator drivers. Like the routers +and transports, which authenticators are included in the binary is controlled +by build-time definitions. The following are currently available, included by +setting + +AUTH_CRAM_MD5=yes +AUTH_CYRUS_SASL=yes +AUTH_DOVECOT=yes +AUTH_GSASL=yes +AUTH_HEIMDAL_GSSAPI=yes +AUTH_PLAINTEXT=yes +AUTH_SPA=yes +AUTH_TLS=yes + +in Local/Makefile, respectively. The first of these supports the CRAM-MD5 +authentication mechanism (RFC 2195), and the second provides an interface to +the Cyrus SASL authentication library. The third is an interface to Dovecot's +authentication system, delegating the work via a socket interface. The fourth +provides an interface to the GNU SASL authentication library, which provides +mechanisms but typically not data sources. The fifth provides direct access to +Heimdal GSSAPI, geared for Kerberos, but supporting setting a server keytab. +The sixth can be configured to support the PLAIN authentication mechanism (RFC +2595) or the LOGIN mechanism, which is not formally documented, but used by +several MUAs. The seventh authenticator supports Microsoft's Secure Password +Authentication mechanism. The eighth is an Exim authenticator but not an SMTP +one; instead it can use information from a TLS negotiation. + +The authenticators are configured using the same syntax as other drivers (see +section 6.23). If no authenticators are required, no authentication section +need be present in the configuration file. Each authenticator can in principle +have both server and client functions. When Exim is receiving SMTP mail, it is +acting as a server; when it is sending out messages over SMTP, it is acting as +a client. Authenticator configuration options are provided for use in both +these circumstances. + +To make it clear which options apply to which situation, the prefixes server_ +and client_ are used on option names that are specific to either the server or +the client function, respectively. Server and client functions are disabled if +none of their options are set. If an authenticator is to be used for both +server and client functions, a single definition, using both sets of options, +is required. For example: + +cram: + driver = cram_md5 + public_name = CRAM-MD5 + server_secret = ${if eq{$auth1}{ph10}{secret1}fail} + client_name = ph10 + client_secret = secret2 + +The server_ option is used when Exim is acting as a server, and the client_ +options when it is acting as a client. + +Descriptions of the individual authenticators are given in subsequent chapters. +The remainder of this chapter covers the generic options for the +authenticators, followed by general discussion of the way authentication works +in Exim. + +Beware: the meaning of $auth1, $auth2, ... varies on a per-driver and +per-mechanism basis. Please read carefully to determine which variables hold +account labels such as usercodes and which hold passwords or other +authenticating data. + +Note that some mechanisms support two different identifiers for accounts: the +authentication id and the authorization id. The contractions authn and authz +are commonly encountered. The American spelling is standard here. Conceptually, +authentication data such as passwords are tied to the identifier used to +authenticate; servers may have rules to permit one user to act as a second +user, so that after login the session is treated as though that second user had +logged in. That second user is the authorization id. A robust configuration +might confirm that the authz field is empty or matches the authn field. Often +this is just ignored. The authn can be considered as verified data, the authz +as an unverified request which the server might choose to honour. + +A realm is a text string, typically a domain name, presented by a server to a +client to help it select an account and credentials to use. In some mechanisms, +the client and server provably agree on the realm, but clients typically can +not treat the realm as secure data to be blindly trusted. + + +33.1 Generic options for authenticators +--------------------------------------- + ++-----------------------------------------------------------------+ +|client_condition|Use: authenticators|Type: string*|Default: unset| ++-----------------------------------------------------------------+ + +When Exim is authenticating as a client, it skips any authenticator whose +client_condition expansion yields "0", "no", or "false". This can be used, for +example, to skip plain text authenticators when the connection is not encrypted +by a setting such as: + +client_condition = ${if !eq{$tls_out_cipher}{}} + ++--------------------------------------------------------------+ +|client_set_id|Use: authenticators|Type: string*|Default: unset| ++--------------------------------------------------------------+ + +When client authentication succeeds, this condition is expanded; the result is +used in the log lines for outbound messages. Typically it will be the user name +used for authentication. + ++------------------------------------------------------+ +|driver|Use: authenticators|Type: string|Default: unset| ++------------------------------------------------------+ + +This option must always be set. It specifies which of the available +authenticators is to be used. + ++-----------------------------------------------------------+ +|public_name|Use: authenticators|Type: string|Default: unset| ++-----------------------------------------------------------+ + +This option specifies the name of the authentication mechanism that the driver +implements, and by which it is known to the outside world. These names should +contain only upper case letters, digits, underscores, and hyphens (RFC 2222), +but Exim in fact matches them caselessly. If public_name is not set, it +defaults to the driver's instance name. + ++---------------------------------------------------------------------------+ +|server_advertise_condition|Use: authenticators|Type: string*|Default: unset| ++---------------------------------------------------------------------------+ + +When a server is about to advertise an authentication mechanism, the condition +is expanded. If it yields the empty string, "0", "no", or "false", the +mechanism is not advertised. If the expansion fails, the mechanism is not +advertised. If the failure was not forced, and was not caused by a lookup +defer, the incident is logged. See section 33.3 below for further discussion. + ++-----------------------------------------------------------------+ +|server_condition|Use: authenticators|Type: string*|Default: unset| ++-----------------------------------------------------------------+ + +This option must be set for a plaintext server authenticator, where it is used +directly to control authentication. See section 34.2 for details. + +For the gsasl authenticator, this option is required for various mechanisms; +see chapter 38 for details. + +For the other authenticators, server_condition can be used as an additional +authentication or authorization mechanism that is applied after the other +authenticator conditions succeed. If it is set, it is expanded when the +authenticator would otherwise return a success code. If the expansion is forced +to fail, authentication fails. Any other expansion failure causes a temporary +error code to be returned. If the result of a successful expansion is an empty +string, "0", "no", or "false", authentication fails. If the result of the +expansion is "1", "yes", or "true", authentication succeeds. For any other +result, a temporary error code is returned, with the expanded string as the +error text. + ++-------------------------------------------------------------------+ +|server_debug_print|Use: authenticators|Type: string*|Default: unset| ++-------------------------------------------------------------------+ + +If this option is set and authentication debugging is enabled (see the -d +command line option), the string is expanded and included in the debugging +output when the authenticator is run as a server. This can help with checking +out the values of variables. If expansion of the string fails, the error +message is written to the debugging output, and Exim carries on processing. + ++--------------------------------------------------------------+ +|server_set_id|Use: authenticators|Type: string*|Default: unset| ++--------------------------------------------------------------+ + +When an Exim server successfully authenticates a client, this string is +expanded using data from the authentication, and preserved for any incoming +messages in the variable $authenticated_id. It is also included in the log +lines for incoming messages. For example, a user/password authenticator +configuration might preserve the user name that was used to authenticate, and +refer to it subsequently during delivery of the message. On a failing +authentication the expansion result is instead saved in the +$authenticated_fail_id variable. If expansion fails, the option is ignored. + ++---------------------------------------------------------------------------+ +|server_mail_auth_condition|Use: authenticators|Type: string*|Default: unset| ++---------------------------------------------------------------------------+ + +This option allows a server to discard authenticated sender addresses supplied +as part of MAIL commands in SMTP connections that are authenticated by the +driver on which server_mail_auth_condition is set. The option is not used as +part of the authentication process; instead its (unexpanded) value is +remembered for later use. How it is used is described in the following section. + + +33.2 The AUTH parameter on MAIL commands +---------------------------------------- + +When a client supplied an AUTH= item on a MAIL command, Exim applies the +following checks before accepting it as the authenticated sender of the +message: + + * If the connection is not using extended SMTP (that is, HELO was used rather + than EHLO), the use of AUTH= is a syntax error. + + * If the value of the AUTH= parameter is "<>", it is ignored. + + * If acl_smtp_mailauth is defined, the ACL it specifies is run. While it is + running, the value of $authenticated_sender is set to the value obtained + from the AUTH= parameter. If the ACL does not yield "accept", the value of + $authenticated_sender is deleted. The acl_smtp_mailauth ACL may not return + "drop" or "discard". If it defers, a temporary error code (451) is given + for the MAIL command. + + * If acl_smtp_mailauth is not defined, the value of the AUTH= parameter is + accepted and placed in $authenticated_sender only if the client has + authenticated. + + * If the AUTH= value was accepted by either of the two previous rules, and + the client has authenticated, and the authenticator has a setting for the + server_mail_auth_condition, the condition is checked at this point. The + valued that was saved from the authenticator is expanded. If the expansion + fails, or yields an empty string, "0", "no", or "false", the value of + $authenticated_sender is deleted. If the expansion yields any other value, + the value of $authenticated_sender is retained and passed on with the + message. + +When $authenticated_sender is set for a message, it is passed on to other hosts +to which Exim authenticates as a client. Do not confuse this value with +$authenticated_id, which is a string obtained from the authentication process, +and which is not usually a complete email address. + +Whenever an AUTH= value is ignored, the incident is logged. The ACL for MAIL, +if defined, is run after AUTH= is accepted or ignored. It can therefore make +use of $authenticated_sender. The converse is not true: the value of +$sender_address is not yet set up when the acl_smtp_mailauth ACL is run. + + +33.3 Authentication on an Exim server +------------------------------------- + +When Exim receives an EHLO command, it advertises the public names of those +authenticators that are configured as servers, subject to the following +conditions: + + * The client host must match auth_advertise_hosts (default *). + + * It the server_advertise_condition option is set, its expansion must not + yield the empty string, "0", "no", or "false". + +The order in which the authenticators are defined controls the order in which +the mechanisms are advertised. + +Some mail clients (for example, some versions of Netscape) require the user to +provide a name and password for authentication whenever AUTH is advertised, +even though authentication may not in fact be needed (for example, Exim may be +set up to allow unconditional relaying from the client by an IP address check). +You can make such clients more friendly by not advertising AUTH to them. For +example, if clients on the 10.9.8.0/24 network are permitted (by the ACL that +runs for RCPT) to relay without authentication, you should set + +auth_advertise_hosts = ! 10.9.8.0/24 + +so that no authentication mechanisms are advertised to them. + +The server_advertise_condition controls the advertisement of individual +authentication mechanisms. For example, it can be used to restrict the +advertisement of a particular mechanism to encrypted connections, by a setting +such as: + +server_advertise_condition = ${if eq{$tls_in_cipher}{}{no}{yes}} + +If the session is encrypted, $tls_in_cipher is not empty, and so the expansion +yields "yes", which allows the advertisement to happen. + +When an Exim server receives an AUTH command from a client, it rejects it +immediately if AUTH was not advertised in response to an earlier EHLO command. +This is the case if + + * The client host does not match auth_advertise_hosts; or + + * No authenticators are configured with server options; or + + * Expansion of server_advertise_condition blocked the advertising of all the + server authenticators. + +Otherwise, Exim runs the ACL specified by acl_smtp_auth in order to decide +whether to accept the command. If acl_smtp_auth is not set, AUTH is accepted +from any client host. + +If AUTH is not rejected by the ACL, Exim searches its configuration for a +server authentication mechanism that was advertised in response to EHLO and +that matches the one named in the AUTH command. If it finds one, it runs the +appropriate authentication protocol, and authentication either succeeds or +fails. If there is no matching advertised mechanism, the AUTH command is +rejected with a 504 error. + +When a message is received from an authenticated host, the value of +$received_protocol is set to "esmtpa" or "esmtpsa" instead of "esmtp" or +"esmtps", and $sender_host_authenticated contains the name (not the public +name) of the authenticator driver that successfully authenticated the client +from which the message was received. This variable is empty if there was no +successful authentication. + +Successful authentication sets up information used by the $authresults +expansion item. + + +33.4 Testing server authentication +---------------------------------- + +Exim's -bh option can be useful for testing server authentication +configurations. The data for the AUTH command has to be sent using base64 +encoding. A quick way to produce such data for testing is the following Perl +script: + +use MIME::Base64; +printf ("%s", encode_base64(eval "\"$ARGV[0]\"")); + +This interprets its argument as a Perl string, and then encodes it. The +interpretation as a Perl string allows binary zeros, which are required for +some kinds of authentication, to be included in the data. For example, a +command line to run this script on such data might be + +encode '\0user\0password' + +Note the use of single quotes to prevent the shell interpreting the +backslashes, so that they can be interpreted by Perl to specify characters +whose code value is zero. + +Warning 1: If either of the user or password strings starts with an octal +digit, you must use three zeros instead of one after the leading backslash. If +you do not, the octal digit that starts your string will be incorrectly +interpreted as part of the code for the first character. + +Warning 2: If there are characters in the strings that Perl interprets +specially, you must use a Perl escape to prevent them being misinterpreted. For +example, a command such as + +encode '\0user@domain.com\0pas$$word' + +gives an incorrect answer because of the unescaped "@" and "$" characters. + +If you have the mimencode command installed, another way to do produce +base64-encoded strings is to run the command + +echo -e -n `\0user\0password' | mimencode + +The -e option of echo enables the interpretation of backslash escapes in the +argument, and the -n option specifies no newline at the end of its output. +However, not all versions of echo recognize these options, so you should check +your version before relying on this suggestion. + + +33.5 Authentication by an Exim client +------------------------------------- + +The smtp transport has two options called hosts_require_auth and hosts_try_auth +. When the smtp transport connects to a server that announces support for +authentication, and the host matches an entry in either of these options, Exim +(as a client) tries to authenticate as follows: + + * For each authenticator that is configured as a client, in the order in + which they are defined in the configuration, it searches the authentication + mechanisms announced by the server for one whose name matches the public + name of the authenticator. + + * When it finds one that matches, it runs the authenticator's client code. + The variables $host and $host_address are available for any string + expansions that the client might do. They are set to the server's name and + IP address. If any expansion is forced to fail, the authentication attempt + is abandoned, and Exim moves on to the next authenticator. Otherwise an + expansion failure causes delivery to be deferred. + + * If the result of the authentication attempt is a temporary error or a + timeout, Exim abandons trying to send the message to the host for the + moment. It will try again later. If there are any backup hosts available, + they are tried in the usual way. + + * If the response to authentication is a permanent error (5xx code), Exim + carries on searching the list of authenticators and tries another one if + possible. If all authentication attempts give permanent errors, or if there + are no attempts because no mechanisms match (or option expansions force + failure), what happens depends on whether the host matches + hosts_require_auth or hosts_try_auth. In the first case, a temporary error + is generated, and delivery is deferred. The error can be detected in the + retry rules, and thereby turned into a permanent error if you wish. In the + second case, Exim tries to deliver the message unauthenticated. + +Note that the hostlist test for whether to do authentication can be confused if +name-IP lookups change between the time the peer is decided upon and the time +that the transport runs. For example, with a manualroute router given a host +name, and with DNS "round-robin" used by that name: if the local resolver cache +times out between the router and the transport running, the transport may get +an IP for the name for its authentication check which does not match the +connection peer IP. No authentication will then be done, despite the names +being identical. + +For such cases use a separate transport which always authenticates. + +When Exim has authenticated itself to a remote server, it adds the AUTH +parameter to the MAIL commands it sends, if it has an authenticated sender for +the message. If the message came from a remote host, the authenticated sender +is the one that was receiving on an incoming MAIL command, provided that the +incoming connection was authenticated and the server_mail_auth condition +allowed the authenticated sender to be retained. If a local process calls Exim +to send a message, the sender address that is built from the login name and +qualify_domain is treated as authenticated. However, if the +authenticated_sender option is set on the smtp transport, it overrides the +authenticated sender that was received with the message. + + + +=============================================================================== +34. THE PLAINTEXT AUTHENTICATOR + +The plaintext authenticator can be configured to support the PLAIN and LOGIN +authentication mechanisms, both of which transfer authentication data as plain +(unencrypted) text (though base64 encoded). The use of plain text is a security +risk; you are strongly advised to insist on the use of SMTP encryption (see +chapter 42) if you use the PLAIN or LOGIN mechanisms. If you do use unencrypted +plain text, you should not use the same passwords for SMTP connections as you +do for login accounts. + + +34.1 Plaintext options +---------------------- + +When configured as a server, plaintext uses the following options: + ++-----------------------------------------------------------------+ +|server_condition|Use: authenticators|Type: string*|Default: unset| ++-----------------------------------------------------------------+ + +This is actually a global authentication option, but it must be set in order to +configure the plaintext driver as a server. Its use is described below. + ++----------------------------------------------------------+ +|server_prompts|Use: plaintext|Type: string*|Default: unset| ++----------------------------------------------------------+ + +The contents of this option, after expansion, must be a colon-separated list of +prompt strings. If expansion fails, a temporary authentication rejection is +given. + + +34.2 Using plaintext in a server +-------------------------------- + +When running as a server, plaintext performs the authentication test by +expanding a string. The data sent by the client with the AUTH command, or in +response to subsequent prompts, is base64 encoded, and so may contain any byte +values when decoded. If any data is supplied with the command, it is treated as +a list of strings, separated by NULs (binary zeros), the first three of which +are placed in the expansion variables $auth1, $auth2, and $auth3 (neither LOGIN +nor PLAIN uses more than three strings). + +For compatibility with previous releases of Exim, the values are also placed in +the expansion variables $1, $2, and $3. However, the use of these variables for +this purpose is now deprecated, as it can lead to confusion in string +expansions that also use them for other things. + +If there are more strings in server_prompts than the number of strings supplied +with the AUTH command, the remaining prompts are used to obtain more data. Each +response from the client may be a list of NUL-separated strings. + +Once a sufficient number of data strings have been received, server_condition +is expanded. If the expansion is forced to fail, authentication fails. Any +other expansion failure causes a temporary error code to be returned. If the +result of a successful expansion is an empty string, "0", "no", or "false", +authentication fails. If the result of the expansion is "1", "yes", or "true", +authentication succeeds and the generic server_set_id option is expanded and +saved in $authenticated_id. For any other result, a temporary error code is +returned, with the expanded string as the error text. + +Warning: If you use a lookup in the expansion to find the user's password, be +sure to make the authentication fail if the user is unknown. There are good and +bad examples at the end of the next section. + + +34.3 The PLAIN authentication mechanism +--------------------------------------- + +The PLAIN authentication mechanism (RFC 2595) specifies that three strings be +sent as one item of data (that is, one combined string containing two NUL +separators). The data is sent either as part of the AUTH command, or +subsequently in response to an empty prompt from the server. + +The second and third strings are a user name and a corresponding password. +Using a single fixed user name and password as an example, this could be +configured as follows: + +fixed_plain: + driver = plaintext + public_name = PLAIN + server_prompts = : + server_condition = \ + ${if and {{eq{$auth2}{username}}{eq{$auth3}{mysecret}}}} + server_set_id = $auth2 + +Note that the default result strings from if ("true" or an empty string) are +exactly what we want here, so they need not be specified. Obviously, if the +password contains expansion-significant characters such as dollar, backslash, +or closing brace, they have to be escaped. + +The server_prompts setting specifies a single, empty prompt (empty items at the +end of a string list are ignored). If all the data comes as part of the AUTH +command, as is commonly the case, the prompt is not used. This authenticator is +advertised in the response to EHLO as + +250-AUTH PLAIN + +and a client host can authenticate itself by sending the command + +AUTH PLAIN AHVzZXJuYW1lAG15c2VjcmV0 + +As this contains three strings (more than the number of prompts), no further +data is required from the client. Alternatively, the client may just send + +AUTH PLAIN + +to initiate authentication, in which case the server replies with an empty +prompt. The client must respond with the combined data string. + +The data string is base64 encoded, as required by the RFC. This example, when +decoded, is <NUL>"username"<NUL>"mysecret", where <NUL> represents a zero byte. +This is split up into three strings, the first of which is empty. The +server_condition option in the authenticator checks that the second two are +"username" and "mysecret" respectively. + +Having just one fixed user name and password, as in this example, is not very +realistic, though for a small organization with only a handful of +authenticating clients it could make sense. + +A more sophisticated instance of this authenticator could use the user name in +$auth2 to look up a password in a file or database, and maybe do an encrypted +comparison (see crypteq in chapter 11). Here is a example of this approach, +where the passwords are looked up in a DBM file. Warning: This is an incorrect +example: + +server_condition = \ + ${if eq{$auth3}{${lookup{$auth2}dbm{/etc/authpwd}}}} + +The expansion uses the user name ($auth2) as the key to look up a password, +which it then compares to the supplied password ($auth3). Why is this example +incorrect? It works fine for existing users, but consider what happens if a +non-existent user name is given. The lookup fails, but as no success/failure +strings are given for the lookup, it yields an empty string. Thus, to defeat +the authentication, all a client has to do is to supply a non-existent user +name and an empty password. The correct way of writing this test is: + +server_condition = ${lookup{$auth2}dbm{/etc/authpwd}\ + {${if eq{$value}{$auth3}}} {false}} + +In this case, if the lookup succeeds, the result is checked; if the lookup +fails, "false" is returned and authentication fails. If crypteq is being used +instead of eq, the first example is in fact safe, because crypteq always fails +if its second argument is empty. However, the second way of writing the test +makes the logic clearer. + + +34.4 The LOGIN authentication mechanism +--------------------------------------- + +The LOGIN authentication mechanism is not documented in any RFC, but is in use +in a number of programs. No data is sent with the AUTH command. Instead, a user +name and password are supplied separately, in response to prompts. The +plaintext authenticator can be configured to support this as in this example: + +fixed_login: + driver = plaintext + public_name = LOGIN + server_prompts = User Name : Password + server_condition = \ + ${if and {{eq{$auth1}{username}}{eq{$auth2}{mysecret}}}} + server_set_id = $auth1 + +Because of the way plaintext operates, this authenticator accepts data supplied +with the AUTH command (in contravention of the specification of LOGIN), but if +the client does not supply it (as is the case for LOGIN clients), the prompt +strings are used to obtain two data items. + +Some clients are very particular about the precise text of the prompts. For +example, Outlook Express is reported to recognize only "Username:" and +"Password:". Here is an example of a LOGIN authenticator that uses those +strings. It uses the ldapauth expansion condition to check the user name and +password by binding to an LDAP server: + +login: + driver = plaintext + public_name = LOGIN + server_prompts = Username:: : Password:: + server_condition = ${if and{{ \ + !eq{}{$auth1} }{ \ + ldapauth{\ + user="uid=${quote_ldap_dn:$auth1},ou=people,o=example.org" \ + pass=${quote:$auth2} \ + ldap://ldap.example.org/} }} } + server_set_id = uid=$auth1,ou=people,o=example.org + +We have to check that the username is not empty before using it, because LDAP +does not permit empty DN components. We must also use the quote_ldap_dn +operator to correctly quote the DN for authentication. However, the basic quote +operator, rather than any of the LDAP quoting operators, is the correct one to +use for the password, because quoting is needed only to make the password +conform to the Exim syntax. At the LDAP level, the password is an uninterpreted +string. + + +34.5 Support for different kinds of authentication +-------------------------------------------------- + +A number of string expansion features are provided for the purpose of +interfacing to different ways of user authentication. These include checking +traditionally encrypted passwords from /etc/passwd (or equivalent), PAM, +Radius, ldapauth, pwcheck, and saslauthd. For details see section 11.7. + + +34.6 Using plaintext in a client +-------------------------------- + +The plaintext authenticator has two client options: + ++------------------------------------------------------------------------+ +|client_ignore_invalid_base64|Use: plaintext|Type: boolean|Default: false| ++------------------------------------------------------------------------+ + +If the client receives a server prompt that is not a valid base64 string, +authentication is abandoned by default. However, if this option is set true, +the error in the challenge is ignored and the client sends the response as +usual. + ++-------------------------------------------------------+ +|client_send|Use: plaintext|Type: string*|Default: unset| ++-------------------------------------------------------+ + +The string is a colon-separated list of authentication data strings. Each +string is independently expanded before being sent to the server. The first +string is sent with the AUTH command; any more strings are sent in response to +prompts from the server. Before each string is expanded, the value of the most +recent prompt is placed in the next $auth<n> variable, starting with $auth1 for +the first prompt. Up to three prompts are stored in this way. Thus, the prompt +that is received in response to sending the first string (with the AUTH +command) can be used in the expansion of the second string, and so on. If an +invalid base64 string is received when client_ignore_invalid_base64 is set, an +empty string is put in the $auth<n> variable. + +Note: You cannot use expansion to create multiple strings, because splitting +takes priority and happens first. + +Because the PLAIN authentication mechanism requires NUL (binary zero) bytes in +the data, further processing is applied to each string before it is sent. If +there are any single circumflex characters in the string, they are converted to +NULs. Should an actual circumflex be required as data, it must be doubled in +the string. + +This is an example of a client configuration that implements the PLAIN +authentication mechanism with a fixed user name and password: + +fixed_plain: + driver = plaintext + public_name = PLAIN + client_send = ^username^mysecret + +The lack of colons means that the entire text is sent with the AUTH command, +with the circumflex characters converted to NULs. A similar example that uses +the LOGIN mechanism is: + +fixed_login: + driver = plaintext + public_name = LOGIN + client_send = : username : mysecret + +The initial colon means that the first string is empty, so no data is sent with +the AUTH command itself. The remaining strings are sent in response to prompts. + + + +=============================================================================== +35. THE CRAM_MD5 AUTHENTICATOR + +The CRAM-MD5 authentication mechanism is described in RFC 2195. The server +sends a challenge string to the client, and the response consists of a user +name and the CRAM-MD5 digest of the challenge string combined with a secret +string (password) which is known to both server and client. Thus, the secret is +not sent over the network as plain text, which makes this authenticator more +secure than plaintext. However, the downside is that the secret has to be +available in plain text at either end. + + +35.1 Using cram_md5 as a server +------------------------------- + +This authenticator has one server option, which must be set to configure the +authenticator as a server: + ++--------------------------------------------------------+ +|server_secret|Use: cram_md5|Type: string*|Default: unset| ++--------------------------------------------------------+ + +When the server receives the client's response, the user name is placed in the +expansion variable $auth1, and server_secret is expanded to obtain the password +for that user. The server then computes the CRAM-MD5 digest that the client +should have sent, and checks that it received the correct string. If the +expansion of server_secret is forced to fail, authentication fails. If the +expansion fails for some other reason, a temporary error code is returned to +the client. + +For compatibility with previous releases of Exim, the user name is also placed +in $1. However, the use of this variables for this purpose is now deprecated, +as it can lead to confusion in string expansions that also use numeric +variables for other things. + +For example, the following authenticator checks that the user name given by the +client is "ph10", and if so, uses "secret" as the password. For any other user +name, authentication fails. + +fixed_cram: + driver = cram_md5 + public_name = CRAM-MD5 + server_secret = ${if eq{$auth1}{ph10}{secret}fail} + server_set_id = $auth1 + +If authentication succeeds, the setting of server_set_id preserves the user +name in $authenticated_id. A more typical configuration might look up the +secret string in a file, using the user name as the key. For example: + +lookup_cram: + driver = cram_md5 + public_name = CRAM-MD5 + server_secret = ${lookup{$auth1}lsearch{/etc/authpwd}\ + {$value}fail} + server_set_id = $auth1 + +Note that this expansion explicitly forces failure if the lookup fails because +$auth1 contains an unknown user name. + +As another example, if you wish to re-use a Cyrus SASL sasldb2 file without +using the relevant libraries, you need to know the realm to specify in the +lookup and then ask for the "userPassword" attribute for that user in that +realm, with: + +cyrusless_crammd5: + driver = cram_md5 + public_name = CRAM-MD5 + server_secret = ${lookup{$auth1:mail.example.org:userPassword}\ + dbmjz{/etc/sasldb2}{$value}fail} + server_set_id = $auth1 + + +35.2 Using cram_md5 as a client +------------------------------- + +When used as a client, the cram_md5 authenticator has two options: + ++----------------------------------------------------------------------+ +|client_name|Use: cram_md5|Type: string*|Default: the primary host name| ++----------------------------------------------------------------------+ + +This string is expanded, and the result used as the user name data when +computing the response to the server's challenge. + ++--------------------------------------------------------+ +|client_secret|Use: cram_md5|Type: string*|Default: unset| ++--------------------------------------------------------+ + +This option must be set for the authenticator to work as a client. Its value is +expanded and the result used as the secret string when computing the response. + +Different user names and secrets can be used for different servers by referring +to $host or $host_address in the options. Forced failure of either expansion +string is treated as an indication that this authenticator is not prepared to +handle this case. Exim moves on to the next configured client authenticator. +Any other expansion failure causes Exim to give up trying to send the message +to the current server. + +A simple example configuration of a cram_md5 authenticator, using fixed +strings, is: + +fixed_cram: + driver = cram_md5 + public_name = CRAM-MD5 + client_name = ph10 + client_secret = secret + + + +=============================================================================== +36. THE CYRUS_SASL AUTHENTICATOR + +The code for this authenticator was provided by Matthew Byng-Maddick while at A +L Digital Ltd. + +The cyrus_sasl authenticator provides server support for the Cyrus SASL library +implementation of the RFC 2222 ("Simple Authentication and Security Layer"). +This library supports a number of authentication mechanisms, including PLAIN +and LOGIN, but also several others that Exim does not support directly. In +particular, there is support for Kerberos authentication. + +The cyrus_sasl authenticator provides a gatewaying mechanism directly to the +Cyrus interface, so if your Cyrus library can do, for example, CRAM-MD5, then +so can the cyrus_sasl authenticator. By default it uses the public name of the +driver to determine which mechanism to support. + +Where access to some kind of secret file is required, for example, in GSSAPI or +CRAM-MD5, it is worth noting that the authenticator runs as the Exim user, and +that the Cyrus SASL library has no way of escalating privileges by default. You +may also find you need to set environment variables, depending on the driver +you are using. + +The application name provided by Exim is "exim", so various SASL options may be +set in exim.conf in your SASL directory. If you are using GSSAPI for Kerberos, +note that because of limitations in the GSSAPI interface, changing the server +keytab might need to be communicated down to the Kerberos layer independently. +The mechanism for doing so is dependent upon the Kerberos implementation. + +For example, for older releases of Heimdal, the environment variable +KRB5_KTNAME may be set to point to an alternative keytab file. Exim will pass +this variable through from its own inherited environment when started as root +or the Exim user. The keytab file needs to be readable by the Exim user. With +newer releases of Heimdal, a setuid Exim may cause Heimdal to discard the +environment variable. In practice, for those releases, the Cyrus authenticator +is not a suitable interface for GSSAPI (Kerberos) support. Instead, consider +the heimdal_gssapi authenticator, described in chapter 39 + + +36.1 Using cyrus_sasl as a server +--------------------------------- + +The cyrus_sasl authenticator has four private options. It puts the username (on +a successful authentication) into $auth1. For compatibility with previous +releases of Exim, the username is also placed in $1. However, the use of this +variable for this purpose is now deprecated, as it can lead to confusion in +string expansions that also use numeric variables for other things. + ++----------------------------------------------------------------+ +|server_hostname|Use: cyrus_sasl|Type: string*|Default: see below| ++----------------------------------------------------------------+ + +This option selects the hostname that is used when communicating with the +library. The default value is "$primary_hostname". It is up to the underlying +SASL plug-in what it does with this data. + ++-----------------------------------------------------------+ +|server_mech|Use: cyrus_sasl|Type: string|Default: see below| ++-----------------------------------------------------------+ + +This option selects the authentication mechanism this driver should use. The +default is the value of the generic public_name option. This option allows you +to use a different underlying mechanism from the advertised name. For example: + +sasl: + driver = cyrus_sasl + public_name = X-ANYTHING + server_mech = CRAM-MD5 + server_set_id = $auth1 + ++---------------------------------------------------------+ +|server_realm|Use: cyrus_sasl|Type: string*|Default: unset| ++---------------------------------------------------------+ + +This specifies the SASL realm that the server claims to be in. + ++-----------------------------------------------------------+ +|server_service|Use: cyrus_sasl|Type: string|Default: "smtp"| ++-----------------------------------------------------------+ + +This is the SASL service that the server claims to implement. + +For straightforward cases, you do not need to set any of the authenticator's +private options. All you need to do is to specify an appropriate mechanism as +the public name. Thus, if you have a SASL library that supports CRAM-MD5 and +PLAIN, you could have two authenticators as follows: + +sasl_cram_md5: + driver = cyrus_sasl + public_name = CRAM-MD5 + server_set_id = $auth1 + +sasl_plain: + driver = cyrus_sasl + public_name = PLAIN + server_set_id = $auth2 + +Cyrus SASL does implement the LOGIN authentication method, even though it is +not a standard method. It is disabled by default in the source distribution, +but it is present in many binary distributions. + + + +=============================================================================== +37. THE DOVECOT AUTHENTICATOR + +This authenticator is an interface to the authentication facility of the +Dovecot POP/IMAP server, which can support a number of authentication methods. +Note that Dovecot must be configured to use auth-client not auth-userdb. If you +are using Dovecot to authenticate POP/IMAP clients, it might be helpful to use +the same mechanisms for SMTP authentication. This is a server authenticator +only. There is only one option: + ++------------------------------------------------------+ +|server_socket|Use: dovecot|Type: string|Default: unset| ++------------------------------------------------------+ + +This option must specify the UNIX socket that is the interface to Dovecot +authentication. The public_name option must specify an authentication mechanism +that Dovecot is configured to support. You can have several authenticators for +different mechanisms. For example: + +dovecot_plain: + driver = dovecot + public_name = PLAIN + server_socket = /var/run/dovecot/auth-client + server_set_id = $auth1 + +dovecot_ntlm: + driver = dovecot + public_name = NTLM + server_socket = /var/run/dovecot/auth-client + server_set_id = $auth1 + +If the SMTP connection is encrypted, or if $sender_host_address is equal to +$received_ip_address (that is, the connection is local), the "secured" option +is passed in the Dovecot authentication command. If, for a TLS connection, a +client certificate has been verified, the "valid-client-cert" option is passed. +When authentication succeeds, the identity of the user who authenticated is +placed in $auth1. + + + +=============================================================================== +38. THE GSASL AUTHENTICATOR + +The gsasl authenticator provides server integration for the GNU SASL library +and the mechanisms it provides. This is new as of the 4.80 release and there +are a few areas where the library does not let Exim smoothly scale to handle +future authentication mechanisms, so no guarantee can be made that any +particular new authentication mechanism will be supported without code changes +in Exim. + +Exim's gsasl authenticator does not have client-side support at this time; only +the server-side support is implemented. Patches welcome. + ++-------------------------------------------------------------+ +|server_channelbinding|Use: gsasl|Type: boolean|Default: false| ++-------------------------------------------------------------+ + +Do not set this true without consulting a cryptographic engineer. + +Some authentication mechanisms are able to use external context at both ends of +the session to bind the authentication to that context, and fail the +authentication process if that context differs. Specifically, some TLS +ciphersuites can provide identifying information about the cryptographic +context. + +This should have meant that certificate identity and verification becomes a +non-issue, as a man-in-the-middle attack will cause the correct client and +server to see different identifiers and authentication will fail. + +This is currently only supported when using the GnuTLS library. This is only +usable by mechanisms which support "channel binding"; at time of writing, +that's the SCRAM family. + +This defaults off to ensure smooth upgrade across Exim releases, in case this +option causes some clients to start failing. Some future release of Exim might +have switched the default to be true. + +However, Channel Binding in TLS has proven to be broken in current versions. Do +not plan to rely upon this feature for security, ever, without consulting with +a subject matter expert (a cryptographic engineer). + ++-----------------------------------------------------------+ +|server_hostname|Use: gsasl|Type: string*|Default: see below| ++-----------------------------------------------------------+ + +This option selects the hostname that is used when communicating with the +library. The default value is "$primary_hostname". Some mechanisms will use +this data. + ++------------------------------------------------------+ +|server_mech|Use: gsasl|Type: string|Default: see below| ++------------------------------------------------------+ + +This option selects the authentication mechanism this driver should use. The +default is the value of the generic public_name option. This option allows you +to use a different underlying mechanism from the advertised name. For example: + +sasl: + driver = gsasl + public_name = X-ANYTHING + server_mech = CRAM-MD5 + server_set_id = $auth1 + ++-------------------------------------------------------+ +|server_password|Use: gsasl|Type: string*|Default: unset| ++-------------------------------------------------------+ + +Various mechanisms need access to the cleartext password on the server, so that +proof-of-possession can be demonstrated on the wire, without sending the +password itself. + +The data available for lookup varies per mechanism. In all cases, $auth1 is set +to the authentication id. The $auth2 variable will always be the authorization +id (authz) if available, else the empty string. The $auth3 variable will always +be the realm if available, else the empty string. + +A forced failure will cause authentication to defer. + +If using this option, it may make sense to set the server_condition option to +be simply "true". + ++----------------------------------------------------+ +|server_realm|Use: gsasl|Type: string*|Default: unset| ++----------------------------------------------------+ + +This specifies the SASL realm that the server claims to be in. Some mechanisms +will use this data. + ++---------------------------------------------------------+ +|server_scram_iter|Use: gsasl|Type: string*|Default: unset| ++---------------------------------------------------------+ + +This option provides data for the SCRAM family of mechanisms. $auth1 is not +available at evaluation time. (This may change, as we receive feedback on use) + ++---------------------------------------------------------+ +|server_scram_salt|Use: gsasl|Type: string*|Default: unset| ++---------------------------------------------------------+ + +This option provides data for the SCRAM family of mechanisms. $auth1 is not +available at evaluation time. (This may change, as we receive feedback on use) + ++------------------------------------------------------+ +|server_service|Use: gsasl|Type: string|Default: "smtp"| ++------------------------------------------------------+ + +This is the SASL service that the server claims to implement. Some mechanisms +will use this data. + + +38.1 gsasl auth variables +------------------------- + +These may be set when evaluating specific options, as detailed above. They will +also be set when evaluating server_condition. + +Unless otherwise stated below, the gsasl integration will use the following +meanings for these variables: + + * $auth1: the authentication id + + * $auth2: the authorization id + + * $auth3: the realm + +On a per-mechanism basis: + + * EXTERNAL: only $auth1 is set, to the possibly empty authorization id; the + server_condition option must be present. + + * ANONYMOUS: only $auth1 is set, to the possibly empty anonymous token; the + server_condition option must be present. + + * GSSAPI: $auth1 will be set to the GSSAPI Display Name; $auth2 will be set + to the authorization id, the server_condition option must be present. + +An anonymous token is something passed along as an unauthenticated identifier; +this is analogous to FTP anonymous authentication passing an email address, or +software-identifier@, as the "password". + +An example showing the password having the realm specified in the callback and +demonstrating a Cyrus SASL to GSASL migration approach is: + +gsasl_cyrusless_crammd5: + driver = gsasl + public_name = CRAM-MD5 + server_realm = imap.example.org + server_password = ${lookup{$auth1:$auth3:userPassword}\ + dbmjz{/etc/sasldb2}{$value}fail} + server_set_id = ${quote:$auth1} + server_condition = yes + + + +=============================================================================== +39. THE HEIMDAL_GSSAPI AUTHENTICATOR + +The heimdal_gssapi authenticator provides server integration for the Heimdal +GSSAPI/Kerberos library, permitting Exim to set a keytab pathname reliably. + ++--------------------------------------------------------------------+ +|server_hostname|Use: heimdal_gssapi|Type: string*|Default: see below| ++--------------------------------------------------------------------+ + +This option selects the hostname that is used, with server_service, for +constructing the GSS server name, as a GSS_C_NT_HOSTBASED_SERVICE identifier. +The default value is "$primary_hostname". + ++--------------------------------------------------------------+ +|server_keytab|Use: heimdal_gssapi|Type: string*|Default: unset| ++--------------------------------------------------------------+ + +If set, then Heimdal will not use the system default keytab (typically /etc/ +krb5.keytab) but instead the pathname given in this option. The value should be +a pathname, with no "file:" prefix. + ++--------------------------------------------------------------+ +|server_service|Use: heimdal_gssapi|Type: string*|Default: smtp| ++--------------------------------------------------------------+ + +This option specifies the service identifier used, in conjunction with +server_hostname, for building the identifier for finding credentials from the +keytab. + + +39.1 heimdal_gssapi auth variables +---------------------------------- + +Beware that these variables will typically include a realm, thus will appear to +be roughly like an email address already. The authzid in $auth2 is not +verified, so a malicious client can set it to anything. + +The $auth1 field should be safely trustable as a value from the Key +Distribution Center. Note that these are not quite email addresses. Each +identifier is for a role, and so the left-hand-side may include a role suffix. +For instance, "joe/admin@EXAMPLE.ORG". + + * $auth1: the authentication id, set to the GSS Display Name. + + * $auth2: the authorization id, sent within SASL encapsulation after + authentication. If that was empty, this will also be set to the GSS Display + Name. + + + +=============================================================================== +40. THE SPA AUTHENTICATOR + +The spa authenticator provides client support for Microsoft's Secure Password +Authentication mechanism, which is also sometimes known as NTLM (NT LanMan). +The code for client side of this authenticator was contributed by Marc +Prud'hommeaux, and much of it is taken from the Samba project (https:// +www.samba.org/). The code for the server side was subsequently contributed by +Tom Kistner. The mechanism works as follows: + + * After the AUTH command has been accepted, the client sends an SPA + authentication request based on the user name and optional domain. + + * The server sends back a challenge. + + * The client builds a challenge response which makes use of the user's + password and sends it to the server, which then accepts or rejects it. + +Encryption is used to protect the password in transit. + + +40.1 Using spa as a server +-------------------------- + +The spa authenticator has just one server option: + ++-----------------------------------------------------+ +|server_password|Use: spa|Type: string*|Default: unset| ++-----------------------------------------------------+ + +This option is expanded, and the result must be the cleartext password for the +authenticating user, whose name is at this point in $auth1. For compatibility +with previous releases of Exim, the user name is also placed in $1. However, +the use of this variable for this purpose is now deprecated, as it can lead to +confusion in string expansions that also use numeric variables for other +things. For example: + +spa: + driver = spa + public_name = NTLM + server_password = \ + ${lookup{$auth1}lsearch{/etc/exim/spa_clearpass}{$value}fail} + +If the expansion is forced to fail, authentication fails. Any other expansion +failure causes a temporary error code to be returned. + + +40.2 Using spa as a client +-------------------------- + +The spa authenticator has the following client options: + ++---------------------------------------------------+ +|client_domain|Use: spa|Type: string*|Default: unset| ++---------------------------------------------------+ + +This option specifies an optional domain for the authentication. + ++-----------------------------------------------------+ +|client_password|Use: spa|Type: string*|Default: unset| ++-----------------------------------------------------+ + +This option specifies the user's password, and must be set. + ++-----------------------------------------------------+ +|client_username|Use: spa|Type: string*|Default: unset| ++-----------------------------------------------------+ + +This option specifies the user name, and must be set. Here is an example of a +configuration of this authenticator for use with the mail servers at msn.com: + +msn: + driver = spa + public_name = MSN + client_username = msn/msn_username + client_password = msn_plaintext_password + client_domain = DOMAIN_OR_UNSET + + + +=============================================================================== +41. THE TLS AUTHENTICATOR + +The tls authenticator provides server support for authentication based on +client certificates. + +It is not an SMTP authentication mechanism and is not advertised by the server +as part of the SMTP EHLO response. It is an Exim authenticator in the sense +that it affects the protocol element of the log line, can be tested for by the +authenticated ACL condition, and can set the $authenticated_id variable. + +The client must present a verifiable certificate, for which it must have been +requested via the tls_verify_hosts or tls_try_verify_hosts main options (see 42 +). + +If an authenticator of this type is configured it is run before any SMTP-level +communication is done, and can authenticate the connection. If it does, SMTP +authentication is not offered. + +A maximum of one authenticator of this type may be present. + +The tls authenticator has three server options: + ++---------------------------------------------------+ +|server_param1|Use: tls|Type: string*|Default: unset| ++---------------------------------------------------+ + +This option is expanded after the TLS negotiation and the result is placed in +$auth1. If the expansion is forced to fail, authentication fails. Any other +expansion failure causes a temporary error code to be returned. + ++---------------------------------------------------+ +|server_param2|Use: tls|Type: string*|Default: unset| ++---------------------------------------------------+ + ++---------------------------------------------------+ +|server_param3|Use: tls|Type: string*|Default: unset| ++---------------------------------------------------+ + +As above, for $auth2 and $auth3. + +server_param1 may also be spelled server_param. + +Example: + +tls: + driver = tls + server_param1 = ${certextract {subj_altname,mail,>:} \ + {$tls_in_peercert}} + server_condition = ${if and { {eq{$tls_in_certificate_verified}{1}} \ + {forany {$auth1} \ + {!= {0} \ + {${lookup ldap{ldap:///\ + mailname=${quote_ldap_dn:${lc:$item}},\ + ou=users,LDAP_DC?mailid} {$value}{0} \ + } } } }}} + server_set_id = ${if = {1}{${listcount:$auth1}} {$auth1}{}} + +This accepts a client certificate that is verifiable against any of your +configured trust-anchors (which usually means the full set of public CAs) and +which has a SAN with a good account name. + +Note that, up to TLS1.2, the client cert is on the wire in-clear, including the +SAN, The account name is therefore guessable by an opponent. TLS 1.3 protects +both server and client certificates, and is not vulnerable in this way. +Likewise, a traditional plaintext SMTP AUTH done inside TLS is not. + +Note that because authentication is traditionally an SMTP operation, the +authenticated ACL condition cannot be used in a connect- or helo-ACL. + + + +=============================================================================== +42. ENCRYPTED SMTP CONNECTIONS USING TLS/SSL + +Support for TLS (Transport Layer Security), formerly known as SSL (Secure +Sockets Layer), is implemented by making use of the OpenSSL library or the +GnuTLS library (Exim requires GnuTLS release 1.0 or later). There is no +cryptographic code in the Exim distribution itself for implementing TLS. In +order to use this feature you must install OpenSSL or GnuTLS, and then build a +version of Exim that includes TLS support (see section 4.7). You also need to +understand the basic concepts of encryption at a managerial level, and in +particular, the way that public keys, private keys, and certificates are used. + +RFC 3207 defines how SMTP connections can make use of encryption. Once a +connection is established, the client issues a STARTTLS command. If the server +accepts this, the client and the server negotiate an encryption mechanism. If +the negotiation succeeds, the data that subsequently passes between them is +encrypted. + +Exim's ACLs can detect whether the current SMTP session is encrypted or not, +and if so, what cipher suite is in use, whether the client supplied a +certificate, and whether or not that certificate was verified. This makes it +possible for an Exim server to deny or accept certain commands based on the +encryption state. + +Warning: Certain types of firewall and certain anti-virus products can disrupt +TLS connections. You need to turn off SMTP scanning for these products in order +to get TLS to work. + + +42.1 Support for the "submissions" (aka "ssmtp" and "smtps") protocol +--------------------------------------------------------------------- + +The history of port numbers for TLS in SMTP is a little messy and has been +contentious. As of RFC 8314, the common practice of using the historically +allocated port 465 for "email submission but with TLS immediately upon connect +instead of using STARTTLS" is officially blessed by the IETF, and recommended +by them in preference to STARTTLS. + +The name originally assigned to the port was "ssmtp" or "smtps", but as clarity +emerged over the dual roles of SMTP, for MX delivery and Email Submission, +nomenclature has shifted. The modern name is now "submissions". + +This approach was, for a while, officially abandoned when encrypted SMTP was +standardized, but many clients kept using it, even as the TCP port number was +reassigned for other use. Thus you may encounter guidance claiming that you +shouldn't enable use of this port. In practice, a number of mail-clients have +only ever supported submissions, not submission with STARTTLS upgrade. Ideally, +offer both submission (587) and submissions (465) service. + +Exim supports TLS-on-connect by means of the tls_on_connect_ports global +option. Its value must be a list of port numbers; the most common use is +expected to be: + +tls_on_connect_ports = 465 + +The port numbers specified by this option apply to all SMTP connections, both +via the daemon and via inetd. You still need to specify all the ports that the +daemon uses (by setting daemon_smtp_ports or local_interfaces or the -oX +command line option) because tls_on_connect_ports does not add an extra port - +rather, it specifies different behaviour on a port that is defined elsewhere. + +There is also a -tls-on-connect command line option. This overrides +tls_on_connect_ports; it forces the TLS-only behaviour for all ports. + + +42.2 OpenSSL vs GnuTLS +---------------------- + +The first TLS support in Exim was implemented using OpenSSL. Support for GnuTLS +followed later, when the first versions of GnuTLS were released. To build Exim +to use GnuTLS, you need to set + +USE_GNUTLS=yes + +in Local/Makefile, in addition to + +SUPPORT_TLS=yes + +You must also set TLS_LIBS and TLS_INCLUDE appropriately, so that the include +files and libraries for GnuTLS can be found. + +There are some differences in usage when using GnuTLS instead of OpenSSL: + + * The tls_verify_certificates option cannot be the path of a directory for + GnuTLS versions before 3.3.6 (for later versions, or OpenSSL, it can be + either). + + * The default value for tls_dhparam differs for historical reasons. + + * Distinguished Name (DN) strings reported by the OpenSSL library use a slash + for separating fields; GnuTLS uses commas, in accordance with RFC 2253. + This affects the value of the $tls_in_peerdn and $tls_out_peerdn variables. + + * OpenSSL identifies cipher suites using hyphens as separators, for example: + DES-CBC3-SHA. GnuTLS historically used underscores, for example: + RSA_ARCFOUR_SHA. What is more, OpenSSL complains if underscores are present + in a cipher list. To make life simpler, Exim changes underscores to hyphens + for OpenSSL and passes the string unchanged to GnuTLS (expecting the + library to handle its own older variants) when processing lists of cipher + suites in the tls_require_ciphers options (the global option and the smtp + transport option). + + * The tls_require_ciphers options operate differently, as described in the + sections 42.4 and 42.5. + + * The tls_dh_min_bits SMTP transport option is only honoured by GnuTLS. When + using OpenSSL, this option is ignored. (If an API is found to let OpenSSL + be configured in this way, let the Exim Maintainers know and we'll likely + use it). + + * With GnuTLS, if an explicit list is used for the tls_privatekey main option + main option, it must be ordered to match the tls_certificate list. + + * Some other recently added features may only be available in one or the + other. This should be documented with the feature. If the documentation + does not explicitly state that the feature is infeasible in the other TLS + implementation, then patches are welcome. + + +42.3 GnuTLS parameter computation +--------------------------------- + +This section only applies if tls_dhparam is set to "historic" or to an explicit +path; if the latter, then the text about generation still applies, but not the +chosen filename. By default, as of Exim 4.80 a hard-coded D-H prime is used. +See the documentation of tls_dhparam for more information. + +GnuTLS uses D-H parameters that may take a substantial amount of time to +compute. It is unreasonable to re-compute them for every TLS session. +Therefore, Exim keeps this data in a file in its spool directory, called +gnutls-params-NNNN for some value of NNNN, corresponding to the number of bits +requested. The file is owned by the Exim user and is readable only by its +owner. Every Exim process that start up GnuTLS reads the D-H parameters from +this file. If the file does not exist, the first Exim process that needs it +computes the data and writes it to a temporary file which is renamed once it is +complete. It does not matter if several Exim processes do this simultaneously +(apart from wasting a few resources). Once a file is in place, new Exim +processes immediately start using it. + +For maximum security, the parameters that are stored in this file should be +recalculated periodically, the frequency depending on your paranoia level. If +you are avoiding using the fixed D-H primes published in RFCs, then you are +concerned about some advanced attacks and will wish to do this; if you do not +regenerate then you might as well stick to the standard primes. + +Arranging this is easy in principle; just delete the file when you want new +values to be computed. However, there may be a problem. The calculation of new +parameters needs random numbers, and these are obtained from /dev/random. If +the system is not very active, /dev/random may delay returning data until +enough randomness (entropy) is available. This may cause Exim to hang for a +substantial amount of time, causing timeouts on incoming connections. + +The solution is to generate the parameters externally to Exim. They are stored +in gnutls-params-N in PEM format, which means that they can be generated +externally using the certtool command that is part of GnuTLS. + +To replace the parameters with new ones, instead of deleting the file and +letting Exim re-create it, you can generate new parameters using certtool and, +when this has been done, replace Exim's cache file by renaming. The relevant +commands are something like this: + +# ls +[ look for file; assume gnutls-params-2236 is the most recent ] +# rm -f new-params +# touch new-params +# chown exim:exim new-params +# chmod 0600 new-params +# certtool --generate-dh-params --bits 2236 >>new-params +# openssl dhparam -noout -text -in new-params | head +[ check the first line, make sure it's not more than 2236; + if it is, then go back to the start ("rm") and repeat + until the size generated is at most the size requested ] +# chmod 0400 new-params +# mv new-params gnutls-params-2236 + +If Exim never has to generate the parameters itself, the possibility of +stalling is removed. + +The filename changed in Exim 4.80, to gain the -bits suffix. The value which +Exim will choose depends upon the version of GnuTLS in use. For older GnuTLS, +the value remains hard-coded in Exim as 1024. As of GnuTLS 2.12.x, there is a +way for Exim to ask for the "normal" number of bits for D-H public-key usage, +and Exim does so. This attempt to remove Exim from TLS policy decisions failed, +as GnuTLS 2.12 returns a value higher than the current hard-coded limit of the +NSS library. Thus Exim gains the tls_dh_max_bits global option, which applies +to all D-H usage, client or server. If the value returned by GnuTLS is greater +than tls_dh_max_bits then the value will be clamped down to tls_dh_max_bits. +The default value has been set at the current NSS limit, which is still much +higher than Exim historically used. + +The filename and bits used will change as the GnuTLS maintainers change the +value for their parameter "GNUTLS_SEC_PARAM_NORMAL", as clamped by +tls_dh_max_bits. At the time of writing (mid 2012), GnuTLS 2.12 recommends 2432 +bits, while NSS is limited to 2236 bits. + +In fact, the requested value will be *lower* than tls_dh_max_bits, to increase +the chance of the generated prime actually being within acceptable bounds, as +GnuTLS has been observed to overshoot. Note the check step in the procedure +above. There is no sane procedure available to Exim to double-check the size of +the generated prime, so it might still be too large. + + +42.4 Requiring specific ciphers in OpenSSL +------------------------------------------ + +There is a function in the OpenSSL library that can be passed a list of cipher +suites before the cipher negotiation takes place. This specifies which ciphers + +are acceptable for TLS versions prior to 1.3. + +The list is colon separated and may contain names like DES-CBC3-SHA. Exim +passes the expanded value of tls_require_ciphers directly to this function +call. Many systems will install the OpenSSL manual-pages, so you may have +ciphers(1) available to you. The following quotation from the OpenSSL +documentation specifies what forms of item are allowed in the cipher string: + + * It can consist of a single cipher suite such as RC4-SHA. + + * It can represent a list of cipher suites containing a certain algorithm, or + cipher suites of a certain type. For example SHA1 represents all ciphers + suites using the digest algorithm SHA1 and SSLv3 represents all SSL v3 + algorithms. + + * Lists of cipher suites can be combined in a single cipher string using the + + character. This is used as a logical and operation. For example SHA1+DES + represents all cipher suites containing the SHA1 and the DES algorithms. + +Each cipher string can be optionally preceded by one of the characters "!", "-" +or "+". + + * If "!" is used, the ciphers are permanently deleted from the list. The + ciphers deleted can never reappear in the list even if they are explicitly + stated. + + * If "-" is used, the ciphers are deleted from the list, but some or all of + the ciphers can be added again by later options. + + * If "+" is used, the ciphers are moved to the end of the list. This option + does not add any new ciphers; it just moves matching existing ones. + +If none of these characters is present, the string is interpreted as a list of +ciphers to be appended to the current preference list. If the list includes any +ciphers already present they will be ignored: that is, they will not be moved +to the end of the list. + +The OpenSSL ciphers(1) command may be used to test the results of a given +string: + +# note single-quotes to get ! past any shell history expansion +$ openssl ciphers 'HIGH:!MD5:!SHA1' + +This example will let the library defaults be permitted on the MX port, where +there's probably no identity verification anyway, but ups the ante on the +submission ports where the administrator might have some influence on the +choice of clients used: + +# OpenSSL variant; see man ciphers(1) +tls_require_ciphers = ${if =={$received_port}{25}\ + {DEFAULT}\ + {HIGH:!MD5:!SHA1}} + +This example will prefer ECDSA-authenticated ciphers over RSA ones: + +tls_require_ciphers = ECDSA:RSA:!COMPLEMENTOFDEFAULT + +For TLS version 1.3 the control available is less fine-grained and Exim does +not provide access to it at present. The value of the tls_require_ciphers +option is ignored when TLS version 1.3 is negotiated. + +As of writing the library default cipher suite list for TLSv1.3 is + +TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 + + +42.5 Requiring specific ciphers or other parameters in GnuTLS +------------------------------------------------------------- + +The GnuTLS library allows the caller to provide a "priority string", documented +as part of the gnutls_priority_init function. This is very similar to the +ciphersuite specification in OpenSSL. + +The tls_require_ciphers option is treated as the GnuTLS priority string and +controls both protocols and ciphers. + +The tls_require_ciphers option is available both as an global option, +controlling how Exim behaves as a server, and also as an option of the smtp +transport, controlling how Exim behaves as a client. In both cases the value is +string expanded. The resulting string is not an Exim list and the string is +given to the GnuTLS library, so that Exim does not need to be aware of future +feature enhancements of GnuTLS. + +Documentation of the strings accepted may be found in the GnuTLS manual, under +"Priority strings". This is online as https://www.gnutls.org/manual/html_node/ +Priority-Strings.html, but beware that this relates to GnuTLS 3, which may be +newer than the version installed on your system. If you are using GnuTLS 3, +then the example code https://www.gnutls.org/manual/gnutls.html# +Listing-the-ciphersuites-in-a-priority-string on that site can be used to test +a given string. + +For example: + +# Disable older versions of protocols +tls_require_ciphers = NORMAL:%LATEST_RECORD_VERSION:-VERS-SSL3.0 + +Prior to Exim 4.80, an older API of GnuTLS was used, and Exim supported three +additional options, "gnutls_require_kx", "gnutls_require_mac" and " +gnutls_require_protocols". tls_require_ciphers was an Exim list. + +This example will let the library defaults be permitted on the MX port, where +there's probably no identity verification anyway, and lowers security further +by increasing compatibility; but this ups the ante on the submission ports +where the administrator might have some influence on the choice of clients +used: + +# GnuTLS variant +tls_require_ciphers = ${if =={$received_port}{25}\ + {NORMAL:%COMPAT}\ + {SECURE128}} + + +42.6 Configuring an Exim server to use TLS +------------------------------------------ + +When Exim has been built with TLS support, it advertises the availability of +the STARTTLS command to client hosts that match tls_advertise_hosts, but not to +any others. The default value of this option is *, which means that STARTTLS is +always advertised. Set it to blank to never advertise; this is reasonable for +systems that want to use TLS only as a client. + +If STARTTLS is to be used you need to set some other options in order to make +TLS available. + +If a client issues a STARTTLS command and there is some configuration problem +in the server, the command is rejected with a 454 error. If the client persists +in trying to issue SMTP commands, all except QUIT are rejected with the error + +554 Security failure + +If a STARTTLS command is issued within an existing TLS session, it is rejected +with a 554 error code. + +To enable TLS operations on a server, the tls_advertise_hosts option must be +set to match some hosts. The default is * which matches all hosts. + +If this is all you do, TLS encryption will be enabled but not authentication - +meaning that the peer has no assurance it is actually you he is talking to. You +gain protection from a passive sniffer listening on the wire but not from +someone able to intercept the communication. + +Further protection requires some further configuration at the server end. + +To make TLS work you need to set, in the server, + +tls_certificate = /some/file/name +tls_privatekey = /some/file/name + +These options are, in fact, expanded strings, so you can make them depend on +the identity of the client that is connected if you wish. The first file +contains the server's X509 certificate, and the second contains the private key +that goes with it. These files need to be PEM format and readable by the Exim +user, and must always be given as full path names. The key must not be +password-protected. They can be the same file if both the certificate and the +key are contained within it. If tls_privatekey is not set, or if its expansion +is forced to fail or results in an empty string, this is assumed to be the +case. The certificate file may also contain intermediate certificates that need +to be sent to the client to enable it to authenticate the server's certificate. + +For dual-stack (eg. RSA and ECDSA) configurations, these options can be +colon-separated lists of file paths. Ciphers using given authentication +algorithms require the presence of a suitable certificate to supply the +public-key. The server selects among the certificates to present to the client +depending on the selected cipher, hence the priority ordering for ciphers will +affect which certificate is used. + +If you do not understand about certificates and keys, please try to find a +source of this background information, which is not Exim-specific. (There are a +few comments below in section 42.12.) + +Note: These options do not apply when Exim is operating as a client - they +apply only in the case of a server. If you need to use a certificate in an Exim +client, you must set the options of the same names in an smtp transport. + +With just these options, an Exim server will be able to use TLS. It does not +require the client to have a certificate (but see below for how to insist on +this). There is one other option that may be needed in other situations. If + +tls_dhparam = /some/file/name + +is set, the SSL library is initialized for the use of Diffie-Hellman ciphers +with the parameters contained in the file. Set this to "none" to disable use of +DH entirely, by making no prime available: + +tls_dhparam = none + +This may also be set to a string identifying a standard prime to be used for +DH; if it is set to "default" or, for OpenSSL, is unset, then the prime used is +"ike23". There are a few standard primes available, see the documentation for +tls_dhparam for the complete list. + +See the command + +openssl dhparam + +for a way of generating file data. + +The strings supplied for these three options are expanded every time a client +host connects. It is therefore possible to use different certificates and keys +for different hosts, if you so wish, by making use of the client's IP address +in $sender_host_address to control the expansion. If a string expansion is +forced to fail, Exim behaves as if the option is not set. + +The variable $tls_in_cipher is set to the cipher suite that was negotiated for +an incoming TLS connection. It is included in the Received: header of an +incoming message (by default - you can, of course, change this), and it is also +included in the log line that records a message's arrival, keyed by "X=", +unless the tls_cipher log selector is turned off. The encrypted condition can +be used to test for specific cipher suites in ACLs. + +Once TLS has been established, the ACLs that run for subsequent SMTP commands +can check the name of the cipher suite and vary their actions accordingly. The +cipher suite names vary, depending on which TLS library is being used. For +example, OpenSSL uses the name DES-CBC3-SHA for the cipher suite which in other +contexts is known as TLS_RSA_WITH_3DES_EDE_CBC_SHA. Check the OpenSSL or GnuTLS +documentation for more details. + +For outgoing SMTP deliveries, $tls_out_cipher is used and logged (again +depending on the tls_cipher log selector). + + +42.7 Requesting and verifying client certificates +------------------------------------------------- + +If you want an Exim server to request a certificate when negotiating a TLS +session with a client, you must set either tls_verify_hosts or +tls_try_verify_hosts. You can, of course, set either of them to * to apply to +all TLS connections. For any host that matches one of these options, Exim +requests a certificate as part of the setup of the TLS session. The contents of +the certificate are verified by comparing it with a list of expected +trust-anchors or certificates. These may be the system default set (depending +on library version), an explicit file or, depending on library version, a +directory, identified by tls_verify_certificates. + +A file can contain multiple certificates, concatenated end to end. If a +directory is used (OpenSSL only), each certificate must be in a separate file, +with a name (or a symbolic link) of the form <hash>.0, where <hash> is a hash +value constructed from the certificate. You can compute the relevant hash by +running the command + +openssl x509 -hash -noout -in /cert/file + +where /cert/file contains a single certificate. + +There is no checking of names of the client against the certificate Subject +Name or Subject Alternate Names. + +The difference between tls_verify_hosts and tls_try_verify_hosts is what +happens if the client does not supply a certificate, or if the certificate does +not match any of the certificates in the collection named by +tls_verify_certificates. If the client matches tls_verify_hosts, the attempt to +set up a TLS session is aborted, and the incoming connection is dropped. If the +client matches tls_try_verify_hosts, the (encrypted) SMTP session continues. +ACLs that run for subsequent SMTP commands can detect the fact that no +certificate was verified, and vary their actions accordingly. For example, you +can insist on a certificate before accepting a message for relaying, but not +when the message is destined for local delivery. + +When a client supplies a certificate (whether it verifies or not), the value of +the Distinguished Name of the certificate is made available in the variable +$tls_in_peerdn during subsequent processing of the message. + +Because it is often a long text string, it is not included in the log line or +Received: header by default. You can arrange for it to be logged, keyed by "DN= +", by setting the tls_peerdn log selector, and you can use received_header_text +to change the Received: header. When no certificate is supplied, $tls_in_peerdn +is empty. + + +42.8 Revoked certificates +------------------------- + +Certificate issuing authorities issue Certificate Revocation Lists (CRLs) when +certificates are revoked. If you have such a list, you can pass it to an Exim +server using the global option called tls_crl and to an Exim client using an +identically named option for the smtp transport. In each case, the value of the +option is expanded and must then be the name of a file that contains a CRL in +PEM format. The downside is that clients have to periodically re-download a +potentially huge file from every certificate authority they know of. + +The way with most moving parts at query time is Online Certificate Status +Protocol (OCSP), where the client verifies the certificate against an OCSP +server run by the CA. This lets the CA track all usage of the certs. It +requires running software with access to the private key of the CA, to sign the +responses to the OCSP queries. OCSP is based on HTTP and can be proxied +accordingly. + +The only widespread OCSP server implementation (known to this writer) comes as +part of OpenSSL and aborts on an invalid request, such as connecting to the +port and then disconnecting. This requires re-entering the passphrase each time +some random client does this. + +The third way is OCSP Stapling; in this, the server using a certificate issued +by the CA periodically requests an OCSP proof of validity from the OCSP server, +then serves it up inline as part of the TLS negotiation. This approach adds no +extra round trips, does not let the CA track users, scales well with number of +certs issued by the CA and is resilient to temporary OCSP server failures, as +long as the server starts retrying to fetch an OCSP proof some time before its +current proof expires. The downside is that it requires server support. + +Unless Exim is built with the support disabled, or with GnuTLS earlier than +version 3.3.16 / 3.4.8 support for OCSP stapling is included. + +There is a global option called tls_ocsp_file. The file specified therein is +expected to be in DER format, and contain an OCSP proof. Exim will serve it as +part of the TLS handshake. This option will be re-expanded for SNI, if the +tls_certificate option contains "tls_in_sni", as per other TLS options. + +Exim does not at this time implement any support for fetching a new OCSP proof. +The burden is on the administrator to handle this, outside of Exim. The file +specified should be replaced atomically, so that the contents are always valid. +Exim will expand the tls_ocsp_file option on each connection, so a new file +will be handled transparently on the next connection. + +When built with OpenSSL Exim will check for a valid next update timestamp in +the OCSP proof; if not present, or if the proof has expired, it will be +ignored. + +For the client to be able to verify the stapled OCSP the server must also +supply, in its stapled information, any intermediate certificates for the chain +leading to the OCSP proof from the signer of the server certificate. There may +be zero or one such. These intermediate certificates should be added to the +server OCSP stapling file named by tls_ocsp_file. + +Note that the proof only covers the terminal server certificate, not any of the +chain from CA to it. + +There is no current way to staple a proof for a client certificate. + + A helper script "ocsp_fetch.pl" for fetching a proof from a CA + OCSP server is supplied. The server URL may be included in the + server certificate, if the CA is helpful. + + One failure mode seen was the OCSP Signer cert expiring before the end + of validity of the OCSP proof. The checking done by Exim/OpenSSL + noted this as invalid overall, but the re-fetch script did not. + + +42.9 Configuring an Exim client to use TLS +------------------------------------------ + +The tls_cipher and tls_peerdn log selectors apply to outgoing SMTP deliveries +as well as to incoming, the latter one causing logging of the server +certificate's DN. The remaining client configuration for TLS is all within the +smtp transport. + +It is not necessary to set any options to have TLS work in the smtp transport. +If Exim is built with TLS support, and TLS is advertised by a server, the smtp +transport always tries to start a TLS session. However, this can be prevented +by setting hosts_avoid_tls (an option of the transport) to a list of server +hosts for which TLS should not be used. + +If you do not want Exim to attempt to send messages unencrypted when an attempt +to set up an encrypted connection fails in any way, you can set +hosts_require_tls to a list of hosts for which encryption is mandatory. For +those hosts, delivery is always deferred if an encrypted connection cannot be +set up. If there are any other hosts for the address, they are tried in the +usual way. + +When the server host is not in hosts_require_tls, Exim may try to deliver the +message unencrypted. It always does this if the response to STARTTLS is a 5xx +code. For a temporary error code, or for a failure to negotiate a TLS session +after a success response code, what happens is controlled by the +tls_tempfail_tryclear option of the smtp transport. If it is false, delivery to +this host is deferred, and other hosts (if available) are tried. If it is true, +Exim attempts to deliver unencrypted after a 4xx response to STARTTLS, and if +STARTTLS is accepted, but the subsequent TLS negotiation fails, Exim closes the +current connection (because it is in an unknown state), opens a new one to the +same host, and then tries the delivery unencrypted. + +The tls_certificate and tls_privatekey options of the smtp transport provide +the client with a certificate, which is passed to the server if it requests it. +If the server is Exim, it will request a certificate only if tls_verify_hosts +or tls_try_verify_hosts matches the client. + +If the tls_verify_certificates option is set on the smtp transport, it +specifies a collection of expected server certificates. These may be the system +default set (depending on library version), a file, or (depending on library +version) a directory. The client verifies the server's certificate against this +collection, taking into account any revoked certificates that are in the list +defined by tls_crl. Failure to verify fails the TLS connection unless either of +the tls_verify_hosts or tls_try_verify_hosts options are set. + +The tls_verify_hosts and tls_try_verify_hosts options restrict certificate +verification to the listed servers. Verification either must or need not +succeed respectively. + +The tls_verify_cert_hostnames option lists hosts for which additional checks +are made: that the host name (the one in the DNS A record) is valid for the +certificate. The option defaults to always checking. + +The smtp transport has two OCSP-related options: hosts_require_ocsp; a +host-list for which a Certificate Status is requested and required for the +connection to proceed. The default value is empty. hosts_request_ocsp; a +host-list for which (additionally) a Certificate Status is requested (but not +necessarily verified). The default value is "*" meaning that requests are made +unless configured otherwise. + +The host(s) should also be in hosts_require_tls, and tls_verify_certificates +configured for the transport, for OCSP to be relevant. + +If tls_require_ciphers is set on the smtp transport, it must contain a list of +permitted cipher suites. If either of these checks fails, delivery to the +current host is abandoned, and the smtp transport tries to deliver to +alternative hosts, if any. + +Note: These options must be set in the smtp transport for Exim to use TLS when +it is operating as a client. Exim does not assume that a server certificate +(set by the global options of the same name) should also be used when operating +as a client. + +All the TLS options in the smtp transport are expanded before use, with $host +and $host_address containing the name and address of the server to which the +client is connected. Forced failure of an expansion causes Exim to behave as if +the relevant option were unset. + +Before an SMTP connection is established, the $tls_out_bits, $tls_out_cipher, +$tls_out_peerdn and $tls_out_sni variables are emptied. (Until the first +connection, they contain the values that were set when the message was +received.) If STARTTLS is subsequently successfully obeyed, these variables are +set to the relevant values for the outgoing connection. + + +42.10 Use of TLS Server Name Indication +--------------------------------------- + +With TLS1.0 or above, there is an extension mechanism by which extra +information can be included at various points in the protocol. One of these +extensions, documented in RFC 6066 (and before that RFC 4366) is "Server Name +Indication", commonly "SNI". This extension is sent by the client in the +initial handshake, so that the server can examine the servername within and +possibly choose to use different certificates and keys (and more) for this +session. + +This is analogous to HTTP's "Host:" header, and is the main mechanism by which +HTTPS-enabled web-sites can be virtual-hosted, many sites to one IP address. + +With SMTP to MX, there are the same problems here as in choosing the identity +against which to validate a certificate: you can't rely on insecure DNS to +provide the identity which you then cryptographically verify. So this will be +of limited use in that environment. + +With SMTP to Submission, there is a well-defined hostname which clients are +connecting to and can validate certificates against. Thus clients can choose to +include this information in the TLS negotiation. If this becomes wide-spread, +then hosters can choose to present different certificates to different clients. +Or even negotiate different cipher suites. + +The tls_sni option on an SMTP transport is an expanded string; the result, if +not empty, will be sent on a TLS session as part of the handshake. There's +nothing more to it. Choosing a sensible value not derived insecurely is the +only point of caution. The $tls_out_sni variable will be set to this string for +the lifetime of the client connection (including during authentication). + +Except during SMTP client sessions, if $tls_in_sni is set then it is a string +received from a client. It can be logged with the log_selector item "+tls_sni". + +If the string "tls_in_sni" appears in the main section's tls_certificate option +(prior to expansion) then the following options will be re-expanded during TLS +session handshake, to permit alternative values to be chosen: + + * tls_certificate + + * tls_crl + + * tls_privatekey + + * tls_verify_certificates + + * tls_ocsp_file + +Great care should be taken to deal with matters of case, various injection +attacks in the string ("../" or SQL), and ensuring that a valid filename can +always be referenced; it is important to remember that $tls_in_sni is arbitrary +unverified data provided prior to authentication. Further, the initial +certificate is loaded before SNI is arrived, so an expansion for +tls_certificate must have a default which is used when $tls_in_sni is empty. + +The Exim developers are proceeding cautiously and so far no other TLS options +are re-expanded. + +When Exim is built against OpenSSL, OpenSSL must have been built with support +for TLS Extensions. This holds true for OpenSSL 1.0.0+ and 0.9.8+ with +enable-tlsext in EXTRACONFIGURE. If you invoke openssl s_client -h and see +"-servername" in the output, then OpenSSL has support. + +When Exim is built against GnuTLS, SNI support is available as of GnuTLS +0.5.10. (Its presence predates the current API which Exim uses, so if Exim +built, then you have SNI support). + + +42.11 Multiple messages on the same encrypted TCP/IP connection +--------------------------------------------------------------- + +Exim sends multiple messages down the same TCP/IP connection by starting up an +entirely new delivery process for each message, passing the socket from one +process to the next. This implementation does not fit well with the use of TLS, +because there is quite a lot of state information associated with a TLS +connection, not just a socket identification. Passing all the state information +to a new process is not feasible. Consequently, for sending using TLS Exim +starts an additional proxy process for handling the encryption, piping the +unencrypted data stream from and to the delivery processes. + +An older mode of operation can be enabled on a per-host basis by the +hosts_noproxy_tls option on the smtp transport. If the host matches this list +the proxy process described above is not used; instead Exim shuts down an +existing TLS session being run by the delivery process before passing the +socket to a new process. The new process may then try to start a new TLS +session, and if successful, may try to re-authenticate if AUTH is in use, +before sending the next message. + +The RFC is not clear as to whether or not an SMTP session continues in clear +after TLS has been shut down, or whether TLS may be restarted again later, as +just described. However, if the server is Exim, this shutdown and +reinitialization works. It is not known which (if any) other servers operate +successfully if the client closes a TLS session and continues with unencrypted +SMTP, but there are certainly some that do not work. For such servers, Exim +should not pass the socket to another process, because the failure of the +subsequent attempt to use it would cause Exim to record a temporary host error, +and delay other deliveries to that host. + +To test for this case, Exim sends an EHLO command to the server after closing +down the TLS session. If this fails in any way, the connection is closed +instead of being passed to a new delivery process, but no retry information is +recorded. + +There is also a manual override; you can set hosts_nopass_tls on the smtp +transport to match those hosts for which Exim should not pass connections to +new processes if TLS has been used. + + +42.12 Certificates and all that +------------------------------- + +In order to understand fully how TLS works, you need to know about +certificates, certificate signing, and certificate authorities. This is a large +topic and an introductory guide is unsuitable for the Exim reference manual, so +instead we provide pointers to existing documentation. + +The Apache web-server was for a long time the canonical guide, so their +documentation is a good place to start; their SSL module's Introduction +document is currently at + +https://httpd.apache.org/docs/current/ssl/ssl_intro.html + +and their FAQ is at + +https://httpd.apache.org/docs/current/ssl/ssl_faq.html + +Eric Rescorla's book, SSL and TLS, published by Addison-Wesley (ISBN +0-201-61598-3) in 2001, contains both introductory and more in-depth +descriptions. More recently Ivan Risti?'s book Bulletproof SSL and TLS, +published by Feisty Duck (ISBN 978-1907117046) in 2013 is good. Ivan is the +author of the popular TLS testing tools at https://www.ssllabs.com/. + + +42.13 Certificate chains +------------------------ + +The file named by tls_certificate may contain more than one certificate. This +is useful in the case where the certificate that is being sent is validated by +an intermediate certificate which the other end does not have. Multiple +certificates must be in the correct order in the file. First the host's +certificate itself, then the first intermediate certificate to validate the +issuer of the host certificate, then the next intermediate certificate to +validate the issuer of the first intermediate certificate, and so on, until +finally (optionally) the root certificate. The root certificate must already be +trusted by the recipient for validation to succeed, of course, but if it's not +preinstalled, sending the root certificate along with the rest makes it +available for the user to install if the receiving end is a client MUA that can +interact with a user. + +Note that certificates using MD5 are unlikely to work on today's Internet; even +if your libraries allow loading them for use in Exim when acting as a server, +increasingly clients will not accept such certificates. The error diagnostics +in such a case can be frustratingly vague. + + +42.14 Self-signed certificates +------------------------------ + +You can create a self-signed certificate using the req command provided with +OpenSSL, like this: + +openssl req -x509 -newkey rsa:1024 -keyout file1 -out file2 \ + -days 9999 -nodes + +file1 and file2 can be the same file; the key and the certificate are delimited +and so can be identified independently. The -days option specifies a period for +which the certificate is valid. The -nodes option is important: if you do not +set it, the key is encrypted with a passphrase that you are prompted for, and +any use that is made of the key causes more prompting for the passphrase. This +is not helpful if you are going to use this certificate and key in an MTA, +where prompting is not possible. + +NB: we are now past the point where 9999 days takes us past the 32-bit Unix +epoch. If your system uses unsigned time_t (most do) and is 32-bit, then the +above command might produce a date in the past. Think carefully about the +lifetime of the systems you're deploying, and either reduce the duration of the +certificate or reconsider your platform deployment. (At time of writing, +reducing the duration is the most likely choice, but the inexorable progression +of time takes us steadily towards an era where this will not be a sensible +resolution). + +A self-signed certificate made in this way is sufficient for testing, and may +be adequate for all your requirements if you are mainly interested in +encrypting transfers, and not in secure identification. + +However, many clients require that the certificate presented by the server be a +user (also called "leaf" or "site") certificate, and not a self-signed +certificate. In this situation, the self-signed certificate described above +must be installed on the client host as a trusted root certification authority +(CA), and the certificate used by Exim must be a user certificate signed with +that self-signed certificate. + +For information on creating self-signed CA certificates and using them to sign +user certificates, see the General implementation overview chapter of the +Open-source PKI book, available online at https://sourceforge.net/projects/ +ospkibook/. + + +42.15 DANE +---------- + +DNS-based Authentication of Named Entities, as applied to SMTP over TLS, +provides assurance to a client that it is actually talking to the server it +wants to rather than some attacker operating a Man In The Middle (MITM) +operation. The latter can terminate the TLS connection you make, and make +another one to the server (so both you and the server still think you have an +encrypted connection) and, if one of the "well known" set of Certificate +Authorities has been suborned - something which *has* been seen already (2014), +a verifiable certificate (if you're using normal root CAs, eg. the Mozilla set, +as your trust anchors). + +What DANE does is replace the CAs with the DNS as the trust anchor. The +assurance is limited to a) the possibility that the DNS has been suborned, b) +mistakes made by the admins of the target server. The attack surface presented +by (a) is thought to be smaller than that of the set of root CAs. + +It also allows the server to declare (implicitly) that connections to it should +use TLS. An MITM could simply fail to pass on a server's STARTTLS. + +DANE scales better than having to maintain (and side-channel communicate) +copies of server certificates for every possible target server. It also scales +(slightly) better than having to maintain on an SMTP client a copy of the +standard CAs bundle. It also means not having to pay a CA for certificates. + +DANE requires a server operator to do three things: 1) run DNSSEC. This +provides assurance to clients that DNS lookups they do for the server have not +been tampered with. The domain MX record applying to this server, its A record, +its TLSA record and any associated CNAME records must all be covered by DNSSEC. +2) add TLSA DNS records. These say what the server certificate for a TLS +connection should be. 3) offer a server certificate, or certificate chain, in +TLS connections which is is anchored by one of the TLSA records. + +There are no changes to Exim specific to server-side operation of DANE. Support +for client-side operation of DANE can be included at compile time by defining +SUPPORT_DANE=yes in Local/Makefile. If it has been included, the macro +"_HAVE_DANE" will be defined. + +The TLSA record for the server may have "certificate usage" of DANE-TA(2) or +DANE-EE(3). These are the "Trust Anchor" and "End Entity" variants. The latter +specifies the End Entity directly, i.e. the certificate involved is that of the +server (and if only DANE-EE is used then it should be the sole one transmitted +during the TLS handshake); this is appropriate for a single system, using a +self-signed certificate. DANE-TA usage is effectively declaring a specific CA +to be used; this might be a private CA or a public, well-known one. A private +CA at simplest is just a self-signed certificate (with certain attributes) +which is used to sign server certificates, but running one securely does +require careful arrangement. With DANE-TA, as implemented in Exim and commonly +in other MTAs, the server TLS handshake must transmit the entire certificate +chain from CA to server-certificate. DANE-TA is commonly used for several +services and/or servers, each having a TLSA query-domain CNAME record, all of +which point to a single TLSA record. DANE-TA and DANE-EE can both be used +together. + +Our recommendation is to use DANE with a certificate from a public CA, because +this enables a variety of strategies for remote clients to verify your +certificate. You can then publish information both via DANE and another +technology, "MTA-STS", described below. + +When you use DANE-TA to publish trust anchor information, you ask entities +outside your administrative control to trust the Certificate Authority for +connections to you. If using a private CA then you should expect others to +still apply the technical criteria they'd use for a public CA to your +certificates. In particular, you should probably try to follow current best +practices for CA operation around hash algorithms and key sizes. Do not expect +other organizations to lower their security expectations just because a +particular profile might be reasonable for your own internal use. + +When this text was last updated, this in practice means to avoid use of SHA-1 +and MD5; if using RSA to use key sizes of at least 2048 bits (and no larger +than 4096, for interoperability); to use keyUsage fields correctly; to use +random serial numbers. The list of requirements is subject to change as best +practices evolve. If you're not already using a private CA, or it doesn't meet +these requirements, then we encourage you to avoid all these issues and use a +public CA such as Let's Encrypt instead. + +The TLSA record should have a Selector field of SPKI(1) and a Matching Type +field of SHA2-512(2). + +At the time of writing, https://www.huque.com/bin/gen_tlsa is useful for +quickly generating TLSA records; and commands like + + openssl x509 -in -pubkey -noout <certificate.pem \ + | openssl rsa -outform der -pubin 2>/dev/null \ + | openssl sha512 \ + | awk '{print $2}' + +are workable for 4th-field hashes. + +For use with the DANE-TA model, server certificates must have a correct name +(SubjectName or SubjectAltName). + +The Certificate issued by the CA published in the DANE-TA model should be +issued using a strong hash algorithm. Exim, and importantly various other MTAs +sending to you, will not re-enable hash algorithms which have been disabled by +default in TLS libraries. This means no MD5 and no SHA-1. SHA2-256 is the +minimum for reliable interoperability (and probably the maximum too, in 2018). + +The use of OCSP-stapling should be considered, allowing for fast revocation of +certificates (which would otherwise be limited by the DNS TTL on the TLSA +records). However, this is likely to only be usable with DANE-TA. NOTE: the +default of requesting OCSP for all hosts is modified iff DANE is in use, to: + + hosts_request_ocsp = ${if or { {= {0}{$tls_out_tlsa_usage}} \ + {= {4}{$tls_out_tlsa_usage}} } \ + {*}{}} + +The (new) variable $tls_out_tlsa_usage is a bitfield with numbered bits set for +TLSA record usage codes. The zero above means DANE was not in use, the four +means that only DANE-TA usage TLSA records were found. If the definition of +hosts_request_ocsp includes the string "tls_out_tlsa_usage", they are +re-expanded in time to control the OCSP request. + +This modification of hosts_request_ocsp is only done if it has the default +value of "*". Admins who change it, and those who use hosts_require_ocsp, +should consider the interaction with DANE in their OCSP settings. + +For client-side DANE there are three new smtp transport options, hosts_try_dane +, hosts_require_dane and dane_require_tls_ciphers. The require variant will +result in failure if the target host is not DNSSEC-secured. + +DANE will only be usable if the target host has DNSSEC-secured MX, A and TLSA +records. + +A TLSA lookup will be done if either of the above options match and the +host-lookup succeeded using dnssec. If a TLSA lookup is done and succeeds, a +DANE-verified TLS connection will be required for the host. If it does not, the +host will not be used; there is no fallback to non-DANE or non-TLS. + +If DANE is requested and usable, then the TLS cipher list configuration prefers +to use the option dane_require_tls_ciphers and falls back to +tls_require_ciphers only if that is unset. This lets you configure "decent +crypto" for DANE and "better than nothing crypto" as the default. Note though +that while GnuTLS lets the string control which versions of TLS/SSL will be +negotiated, OpenSSL does not and you're limited to ciphersuite constraints. + +If DANE is requested and useable (see above) the following transport options +are ignored: + + hosts_require_tls + tls_verify_hosts + tls_try_verify_hosts + tls_verify_certificates + tls_crl + tls_verify_cert_hostnames + +If DANE is not usable, whether requested or not, and CA-anchored verification +evaluation is wanted, the above variables should be set appropriately. + +Currently the dnssec_request_domains must be active and dnssec_require_domains +is ignored. + +If verification was successful using DANE then the "CV" item in the delivery +log line will show as "CV=dane". + +There is a new variable $tls_out_dane which will have "yes" if verification +succeeded using DANE and "no" otherwise (only useful in combination with +events; see 60), and a new variable $tls_out_tlsa_usage (detailed above). + +An event (see 60) of type "dane:fail" will be raised on failures to achieve +DANE-verified connection, if one was either requested and offered, or required. +This is intended to support TLS-reporting as defined in https://tools.ietf.org/ +html/draft-ietf-uta-smtp-tlsrpt-17. The $event_data will be one of the Result +Types defined in Section 4.3 of that document. + +Under GnuTLS, DANE is only supported from version 3.0.0 onwards. + +DANE is specified in published RFCs and decouples certificate authority trust +selection from a "race to the bottom" of "you must trust everything for mail to +get through". There is an alternative technology called MTA-STS, which instead +publishes MX trust anchor information on an HTTPS website. At the time this +text was last updated, MTA-STS was still a draft, not yet an RFC. Exim has no +support for MTA-STS as a client, but Exim mail server operators can choose to +publish information describing their TLS configuration using MTA-STS to let +those clients who do use that protocol derive trust information. + +The MTA-STS design requires a certificate from a public Certificate Authority +which is recognized by clients sending to you. That selection of which CAs are +trusted by others is outside your control. + +The most interoperable course of action is probably to use Let's Encrypt, with +automated certificate renewal; to publish the anchor information in +DNSSEC-secured DNS via TLSA records for DANE clients (such as Exim and Postfix) +and to publish anchor information for MTA-STS as well. This is what is done for +the exim.org domain itself (with caveats around occasionally broken MTA-STS +because of incompatible specification changes prior to reaching RFC status). + + + +=============================================================================== +43. ACCESS CONTROL LISTS + +Access Control Lists (ACLs) are defined in a separate section of the runtime +configuration file, headed by "begin acl". Each ACL definition starts with a +name, terminated by a colon. Here is a complete ACL section that contains just +one very small ACL: + +begin acl +small_acl: + accept hosts = one.host.only + +You can have as many lists as you like in the ACL section, and the order in +which they appear does not matter. The lists are self-terminating. + +The majority of ACLs are used to control Exim's behaviour when it receives +certain SMTP commands. This applies both to incoming TCP/IP connections, and +when a local process submits a message using SMTP by specifying the -bs option. +The most common use is for controlling which recipients are accepted in +incoming messages. In addition, you can define an ACL that is used to check +local non-SMTP messages. The default configuration file contains an example of +a realistic ACL for checking RCPT commands. This is discussed in chapter 7. + + +43.1 Testing ACLs +----------------- + +The -bh command line option provides a way of testing your ACL configuration +locally by running a fake SMTP session with which you interact. + + +43.2 Specifying when ACLs are used +---------------------------------- + +In order to cause an ACL to be used, you have to name it in one of the relevant +options in the main part of the configuration. These options are: + + acl_not_smtp ACL for non-SMTP messages + acl_not_smtp_mime ACL for non-SMTP MIME parts + acl_not_smtp_start ACL at start of non-SMTP message + acl_smtp_auth ACL for AUTH + acl_smtp_connect ACL for start of SMTP connection + acl_smtp_data ACL after DATA is complete + acl_smtp_data_prdr ACL for each recipient, after DATA is complete + acl_smtp_dkim ACL for each DKIM signer + acl_smtp_etrn ACL for ETRN + acl_smtp_expn ACL for EXPN + acl_smtp_helo ACL for HELO or EHLO + acl_smtp_mail ACL for MAIL + acl_smtp_mailauth ACL for the AUTH parameter of MAIL + acl_smtp_mime ACL for content-scanning MIME parts + acl_smtp_notquit ACL for non-QUIT terminations + acl_smtp_predata ACL at start of DATA command + acl_smtp_quit ACL for QUIT + acl_smtp_rcpt ACL for RCPT + acl_smtp_starttls ACL for STARTTLS + acl_smtp_vrfy ACL for VRFY + +For example, if you set + +acl_smtp_rcpt = small_acl + +the little ACL defined above is used whenever Exim receives a RCPT command in +an SMTP dialogue. The majority of policy tests on incoming messages can be done +when RCPT commands arrive. A rejection of RCPT should cause the sending MTA to +give up on the recipient address contained in the RCPT command, whereas +rejection at other times may cause the client MTA to keep on trying to deliver +the message. It is therefore recommended that you do as much testing as +possible at RCPT time. + + +43.3 The non-SMTP ACLs +---------------------- + +The non-SMTP ACLs apply to all non-interactive incoming messages, that is, they +apply to batched SMTP as well as to non-SMTP messages. (Batched SMTP is not +really SMTP.) Many of the ACL conditions (for example, host tests, and tests on +the state of the SMTP connection such as encryption and authentication) are not +relevant and are forbidden in these ACLs. However, the sender and recipients +are known, so the senders and sender_domains conditions and the $sender_address +and $recipients variables can be used. Variables such as $authenticated_sender +are also available. You can specify added header lines in any of these ACLs. + +The acl_not_smtp_start ACL is run right at the start of receiving a non-SMTP +message, before any of the message has been read. (This is the analogue of the +acl_smtp_predata ACL for SMTP input.) In the case of batched SMTP input, it +runs after the DATA command has been reached. The result of this ACL is +ignored; it cannot be used to reject a message. If you really need to, you +could set a value in an ACL variable here and reject based on that in the +acl_not_smtp ACL. However, this ACL can be used to set controls, and in +particular, it can be used to set + +control = suppress_local_fixups + +This cannot be used in the other non-SMTP ACLs because by the time they are +run, it is too late. + +The acl_not_smtp_mime ACL is available only when Exim is compiled with the +content-scanning extension. For details, see chapter 44. + +The acl_not_smtp ACL is run just before the local_scan() function. Any kind of +rejection is treated as permanent, because there is no way of sending a +temporary error for these kinds of message. + + +43.4 The SMTP connect ACL +------------------------- + +The ACL test specified by acl_smtp_connect happens at the start of an SMTP +session, after the test specified by host_reject_connection (which is now an +anomaly) and any TCP Wrappers testing (if configured). If the connection is +accepted by an accept verb that has a message modifier, the contents of the +message override the banner message that is otherwise specified by the +smtp_banner option. + + +43.5 The EHLO/HELO ACL +---------------------- + +The ACL test specified by acl_smtp_helo happens when the client issues an EHLO +or HELO command, after the tests specified by helo_accept_junk_hosts, +helo_allow_chars, helo_verify_hosts, and helo_try_verify_hosts. Note that a +client may issue more than one EHLO or HELO command in an SMTP session, and +indeed is required to issue a new EHLO or HELO after successfully setting up +encryption following a STARTTLS command. + +Note also that a deny neither forces the client to go away nor means that mail +will be refused on the connection. Consider checking for $sender_helo_name +being defined in a MAIL or RCPT ACL to do that. + +If the command is accepted by an accept verb that has a message modifier, the +message may not contain more than one line (it will be truncated at the first +newline and a panic logged if it does). Such a message cannot affect the EHLO +options that are listed on the second and subsequent lines of an EHLO response. + + +43.6 The DATA ACLs +------------------ + +Two ACLs are associated with the DATA command, because it is two-stage command, +with two responses being sent to the client. When the DATA command is received, +the ACL defined by acl_smtp_predata is obeyed. This gives you control after all +the RCPT commands, but before the message itself is received. It offers the +opportunity to give a negative response to the DATA command before the data is +transmitted. Header lines added by MAIL or RCPT ACLs are not visible at this +time, but any that are defined here are visible when the acl_smtp_data ACL is +run. + +You cannot test the contents of the message, for example, to verify addresses +in the headers, at RCPT time or when the DATA command is received. Such tests +have to appear in the ACL that is run after the message itself has been +received, before the final response to the DATA command is sent. This is the +ACL specified by acl_smtp_data, which is the second ACL that is associated with +the DATA command. + +If CHUNKING was advertised and a BDAT command sequence is received, the +acl_smtp_predata ACL is not run. The acl_smtp_data is run after the last BDAT +command and all of the data specified is received. + +For both of these ACLs, it is not possible to reject individual recipients. An +error response rejects the entire message. Unfortunately, it is known that some +MTAs do not treat hard (5xx) responses to the DATA command (either before or +after the data) correctly - they keep the message on their queues and try again +later, but that is their problem, though it does waste some of your resources. + +The acl_smtp_data ACL is run after the acl_smtp_data_prdr, the acl_smtp_dkim +and the acl_smtp_mime ACLs. + + +43.7 The SMTP DKIM ACL +---------------------- + +The acl_smtp_dkim ACL is available only when Exim is compiled with DKIM support +enabled (which is the default). + +The ACL test specified by acl_smtp_dkim happens after a message has been +received, and is executed for each DKIM signature found in a message. If not +otherwise specified, the default action is to accept. + +This ACL is evaluated before acl_smtp_mime and acl_smtp_data. + +For details on the operation of DKIM, see section 57.1. + + +43.8 The SMTP MIME ACL +---------------------- + +The acl_smtp_mime option is available only when Exim is compiled with the +content-scanning extension. For details, see chapter 44. + +This ACL is evaluated after acl_smtp_dkim but before acl_smtp_data. + + +43.9 The SMTP PRDR ACL +---------------------- + +The acl_smtp_data_prdr ACL is available only when Exim is compiled with PRDR +support enabled (which is the default). It becomes active only when the PRDR +feature is negotiated between client and server for a message, and more than +one recipient has been accepted. + +The ACL test specified by acl_smtp_data_prdr happens after a message has been +received, and is executed once for each recipient of the message with +$local_part and $domain valid. The test may accept, defer or deny for +individual recipients. The acl_smtp_data will still be called after this ACL +and can reject the message overall, even if this ACL has accepted it for some +or all recipients. + +PRDR may be used to support per-user content filtering. Without it one must +defer any recipient after the first that has a different content-filter +configuration. With PRDR, the RCPT-time check for this can be disabled when the +variable $prdr_requested is "yes". Any required difference in behaviour of the +main DATA-time ACL should however depend on the PRDR-time ACL having run, as +Exim will avoid doing so in some situations (e.g. single-recipient mails). + +See also the prdr_enable global option and the hosts_try_prdr smtp transport +option. + +This ACL is evaluated after acl_smtp_dkim but before acl_smtp_data. If the ACL +is not defined, processing completes as if the feature was not requested by the +client. + + +43.10 The QUIT ACL +------------------ + +The ACL for the SMTP QUIT command is anomalous, in that the outcome of the ACL +does not affect the response code to QUIT, which is always 221. Thus, the ACL +does not in fact control any access. For this reason, it may only accept or +warn as its final result. + +This ACL can be used for tasks such as custom logging at the end of an SMTP +session. For example, you can use ACL variables in other ACLs to count +messages, recipients, etc., and log the totals at QUIT time using one or more +logwrite modifiers on a warn verb. + +Warning: Only the $acl_cx variables can be used for this, because the $acl_mx +variables are reset at the end of each incoming message. + +You do not need to have a final accept, but if you do, you can use a message +modifier to specify custom text that is sent as part of the 221 response to +QUIT. + +This ACL is run only for a "normal" QUIT. For certain kinds of disastrous +failure (for example, failure to open a log file, or when Exim is bombing out +because it has detected an unrecoverable error), all SMTP commands from the +client are given temporary error responses until QUIT is received or the +connection is closed. In these special cases, the QUIT ACL does not run. + + +43.11 The not-QUIT ACL +---------------------- + +The not-QUIT ACL, specified by acl_smtp_notquit, is run in most cases when an +SMTP session ends without sending QUIT. However, when Exim itself is in bad +trouble, such as being unable to write to its log files, this ACL is not run, +because it might try to do things (such as write to log files) that make the +situation even worse. + +Like the QUIT ACL, this ACL is provided to make it possible to do customized +logging or to gather statistics, and its outcome is ignored. The delay modifier +is forbidden in this ACL, and the only permitted verbs are accept and warn. + +When the not-QUIT ACL is running, the variable $smtp_notquit_reason is set to a +string that indicates the reason for the termination of the SMTP connection. +The possible values are: + + "acl-drop" Another ACL issued a drop command + "bad-commands" Too many unknown or non-mail commands + "command-timeout" Timeout while reading SMTP commands + "connection-lost" The SMTP connection has been lost + "data-timeout" Timeout while reading message data + "local-scan-error" The local_scan() function crashed + "local-scan-timeout" The local_scan() function timed out + "signal-exit" SIGTERM or SIGINT + "synchronization-error" SMTP synchronization error + "tls-failed" TLS failed to start + +In most cases when an SMTP connection is closed without having received QUIT, +Exim sends an SMTP response message before actually closing the connection. +With the exception of the "acl-drop" case, the default message can be +overridden by the message modifier in the not-QUIT ACL. In the case of a drop +verb in another ACL, it is the message from the other ACL that is used. + + +43.12 Finding an ACL to use +--------------------------- + +The value of an acl_smtp_xxx option is expanded before use, so you can use +different ACLs in different circumstances. For example, + +acl_smtp_rcpt = ${if ={25}{$interface_port} \ + {acl_check_rcpt} {acl_check_rcpt_submit} } + +In the default configuration file there are some example settings for providing +an RFC 4409 message "submission" service on port 587 and an RFC 8314 +"submissions" service on port 465. You can use a string expansion like this to +choose an ACL for MUAs on these ports which is more appropriate for this +purpose than the default ACL on port 25. + +The expanded string does not have to be the name of an ACL in the configuration +file; there are other possibilities. Having expanded the string, Exim searches +for an ACL as follows: + + * If the string begins with a slash, Exim uses it as a filename, and reads + its contents as an ACL. The lines are processed in the same way as lines in + the Exim configuration file. In particular, continuation lines are + supported, blank lines are ignored, as are lines whose first non-whitespace + character is "#". If the file does not exist or cannot be read, an error + occurs (typically causing a temporary failure of whatever caused the ACL to + be run). For example: + + acl_smtp_data = /etc/acls/\ + ${lookup{$sender_host_address}lsearch\ + {/etc/acllist}{$value}{default}} + + This looks up an ACL file to use on the basis of the host's IP address, + falling back to a default if the lookup fails. If an ACL is successfully + read from a file, it is retained in memory for the duration of the Exim + process, so that it can be re-used without having to re-read the file. + + * If the string does not start with a slash, and does not contain any spaces, + Exim searches the ACL section of the configuration for an ACL whose name + matches the string. + + * If no named ACL is found, or if the string contains spaces, Exim parses the + string as an inline ACL. This can save typing in cases where you just want + to have something like + + acl_smtp_vrfy = accept + + in order to allow free use of the VRFY command. Such a string may contain + newlines; it is processed in the same way as an ACL that is read from a + file. + + +43.13 ACL return codes +---------------------- + +Except for the QUIT ACL, which does not affect the SMTP return code (see +section 43.10 above), the result of running an ACL is either "accept" or +"deny", or, if some test cannot be completed (for example, if a database is +down), "defer". These results cause 2xx, 5xx, and 4xx return codes, +respectively, to be used in the SMTP dialogue. A fourth return, "error", occurs +when there is an error such as invalid syntax in the ACL. This also causes a 4 +xx return code. + +For the non-SMTP ACL, "defer" and "error" are treated in the same way as +"deny", because there is no mechanism for passing temporary errors to the +submitters of non-SMTP messages. + +ACLs that are relevant to message reception may also return "discard". This has +the effect of "accept", but causes either the entire message or an individual +recipient address to be discarded. In other words, it is a blackholing +facility. Use it with care. + +If the ACL for MAIL returns "discard", all recipients are discarded, and no ACL +is run for subsequent RCPT commands. The effect of "discard" in a RCPT ACL is +to discard just the one recipient address. If there are no recipients left when +the message's data is received, the DATA ACL is not run. A "discard" return +from the DATA or the non-SMTP ACL discards all the remaining recipients. The +"discard" return is not permitted for the acl_smtp_predata ACL. + +If the ACL for VRFY returns "accept", a recipient verify (without callout) is +done on the address and the result determines the SMTP response. + +The local_scan() function is always run, even if there are no remaining +recipients; it may create new recipients. + + +43.14 Unset ACL options +----------------------- + +The default actions when any of the acl_xxx options are unset are not all the +same. Note: These defaults apply only when the relevant ACL is not defined at +all. For any defined ACL, the default action when control reaches the end of +the ACL statements is "deny". + +For acl_smtp_quit and acl_not_smtp_start there is no default because these two +are ACLs that are used only for their side effects. They cannot be used to +accept or reject anything. + +For acl_not_smtp, acl_smtp_auth, acl_smtp_connect, acl_smtp_data, acl_smtp_helo +, acl_smtp_mail, acl_smtp_mailauth, acl_smtp_mime, acl_smtp_predata, and +acl_smtp_starttls, the action when the ACL is not defined is "accept". + +For the others (acl_smtp_etrn, acl_smtp_expn, acl_smtp_rcpt, and acl_smtp_vrfy +), the action when the ACL is not defined is "deny". This means that +acl_smtp_rcpt must be defined in order to receive any messages over an SMTP +connection. For an example, see the ACL in the default configuration file. + + +43.15 Data for message ACLs +--------------------------- + +When a MAIL or RCPT ACL, or either of the DATA ACLs, is running, the variables +that contain information about the host and the message's sender (for example, +$sender_host_address and $sender_address) are set, and can be used in ACL +statements. In the case of RCPT (but not MAIL or DATA), $domain and $local_part +are set from the argument address. The entire SMTP command is available in +$smtp_command. + +When an ACL for the AUTH parameter of MAIL is running, the variables that +contain information about the host are set, but $sender_address is not yet set. +Section 33.2 contains a discussion of this parameter and how it is used. + +The $message_size variable is set to the value of the SIZE parameter on the +MAIL command at MAIL, RCPT and pre-data time, or to -1 if that parameter is not +given. The value is updated to the true message size by the time the final DATA +ACL is run (after the message data has been received). + +The $rcpt_count variable increases by one for each RCPT command received. The +$recipients_count variable increases by one each time a RCPT command is +accepted, so while an ACL for RCPT is being processed, it contains the number +of previously accepted recipients. At DATA time (for both the DATA ACLs), +$rcpt_count contains the total number of RCPT commands, and $recipients_count +contains the total number of accepted recipients. + + +43.16 Data for non-message ACLs +------------------------------- + +When an ACL is being run for AUTH, EHLO, ETRN, EXPN, HELO, STARTTLS, or VRFY, +the remainder of the SMTP command line is placed in $smtp_command_argument, and +the entire SMTP command is available in $smtp_command. These variables can be +tested using a condition condition. For example, here is an ACL for use with +AUTH, which insists that either the session is encrypted, or the CRAM-MD5 +authentication method is used. In other words, it does not permit +authentication methods that use cleartext passwords on unencrypted connections. + +acl_check_auth: + accept encrypted = * + accept condition = ${if eq{${uc:$smtp_command_argument}}\ + {CRAM-MD5}} + deny message = TLS encryption or CRAM-MD5 required + +(Another way of applying this restriction is to arrange for the authenticators +that use cleartext passwords not to be advertised when the connection is not +encrypted. You can use the generic server_advertise_condition authenticator +option to do this.) + + +43.17 Format of an ACL +---------------------- + +An individual ACL consists of a number of statements. Each statement starts +with a verb, optionally followed by a number of conditions and "modifiers". +Modifiers can change the way the verb operates, define error and log messages, +set variables, insert delays, and vary the processing of accepted messages. + +If all the conditions are met, the verb is obeyed. The same condition may be +used (with different arguments) more than once in the same statement. This +provides a means of specifying an "and" conjunction between conditions. For +example: + +deny dnslists = list1.example + dnslists = list2.example + +If there are no conditions, the verb is always obeyed. Exim stops evaluating +the conditions and modifiers when it reaches a condition that fails. What +happens then depends on the verb (and in one case, on a special modifier). Not +all the conditions make sense at every testing point. For example, you cannot +test a sender address in the ACL that is run for a VRFY command. + + +43.18 ACL verbs +--------------- + +The ACL verbs are as follows: + + * accept: If all the conditions are met, the ACL returns "accept". If any of + the conditions are not met, what happens depends on whether endpass appears + among the conditions (for syntax see below). If the failing condition is + before endpass, control is passed to the next ACL statement; if it is after + endpass, the ACL returns "deny". Consider this statement, used to check a + RCPT command: + + accept domains = +local_domains + endpass + verify = recipient + + If the recipient domain does not match the domains condition, control + passes to the next statement. If it does match, the recipient is verified, + and the command is accepted if verification succeeds. However, if + verification fails, the ACL yields "deny", because the failing condition is + after endpass. + + The endpass feature has turned out to be confusing to many people, so its + use is not recommended nowadays. It is always possible to rewrite an ACL so + that endpass is not needed, and it is no longer used in the default + configuration. + + If a message modifier appears on an accept statement, its action depends on + whether or not endpass is present. In the absence of endpass (when an + accept verb either accepts or passes control to the next statement), + message can be used to vary the message that is sent when an SMTP command + is accepted. For example, in a RCPT ACL you could have: + + accept <some conditions> + message = OK, I will allow you through today + + You can specify an SMTP response code, optionally followed by an "extended + response code" at the start of the message, but the first digit must be the + same as would be sent by default, which is 2 for an accept verb. + + If endpass is present in an accept statement, message specifies an error + message that is used when access is denied. This behaviour is retained for + backward compatibility, but current "best practice" is to avoid the use of + endpass. + + * defer: If all the conditions are true, the ACL returns "defer" which, in an + SMTP session, causes a 4xx response to be given. For a non-SMTP ACL, defer + is the same as deny, because there is no way of sending a temporary error. + For a RCPT command, defer is much the same as using a redirect router and + ":defer:" while verifying, but the defer verb can be used in any ACL, and + even for a recipient it might be a simpler approach. + + * deny: If all the conditions are met, the ACL returns "deny". If any of the + conditions are not met, control is passed to the next ACL statement. For + example, + + deny dnslists = blackholes.mail-abuse.org + + rejects commands from hosts that are on a DNS black list. + + * discard: This verb behaves like accept, except that it returns "discard" + from the ACL instead of "accept". It is permitted only on ACLs that are + concerned with receiving messages. When all the conditions are true, the + sending entity receives a "success" response. However, discard causes + recipients to be discarded. If it is used in an ACL for RCPT, just the one + recipient is discarded; if used for MAIL, DATA or in the non-SMTP ACL, all + the message's recipients are discarded. Recipients that are discarded + before DATA do not appear in the log line when the received_recipients log + selector is set. + + If the log_message modifier is set when discard operates, its contents are + added to the line that is automatically written to the log. The message + modifier operates exactly as it does for accept. + + * drop: This verb behaves like deny, except that an SMTP connection is + forcibly closed after the 5xx error message has been sent. For example: + + drop message = I don't take more than 20 RCPTs + condition = ${if > {$rcpt_count}{20}} + + There is no difference between deny and drop for the connect-time ACL. The + connection is always dropped after sending a 550 response. + + * require: If all the conditions are met, control is passed to the next ACL + statement. If any of the conditions are not met, the ACL returns "deny". + For example, when checking a RCPT command, + + require message = Sender did not verify + verify = sender + + passes control to subsequent statements only if the message's sender can be + verified. Otherwise, it rejects the command. Note the positioning of the + message modifier, before the verify condition. The reason for this is + discussed in section 43.20. + + * warn: If all the conditions are true, a line specified by the log_message + modifier is written to Exim's main log. Control always passes to the next + ACL statement. If any condition is false, the log line is not written. If + an identical log line is requested several times in the same message, only + one copy is actually written to the log. If you want to force duplicates to + be written, use the logwrite modifier instead. + + If log_message is not present, a warn verb just checks its conditions and + obeys any "immediate" modifiers (such as control, set, logwrite, add_header + , and remove_header) that appear before the first failing condition. There + is more about adding header lines in section 43.24. + + If any condition on a warn statement cannot be completed (that is, there is + some sort of defer), the log line specified by log_message is not written. + This does not include the case of a forced failure from a lookup, which is + considered to be a successful completion. After a defer, no further + conditions or modifiers in the warn statement are processed. The incident + is logged, and the ACL continues to be processed, from the next statement + onwards. + + When one of the warn conditions is an address verification that fails, the + text of the verification failure message is in $acl_verify_message. If you + want this logged, you must set it up explicitly. For example: + + warn !verify = sender + log_message = sender verify failed: $acl_verify_message + +At the end of each ACL there is an implicit unconditional deny. + +As you can see from the examples above, the conditions and modifiers are +written one to a line, with the first one on the same line as the verb, and +subsequent ones on following lines. If you have a very long condition, you can +continue it onto several physical lines by the usual backslash continuation +mechanism. It is conventional to align the conditions vertically. + + +43.19 ACL variables +------------------- + +There are some special variables that can be set during ACL processing. They +can be used to pass information between different ACLs, different invocations +of the same ACL in the same SMTP connection, and between ACLs and the routers, +transports, and filters that are used to deliver a message. The names of these +variables must begin with $acl_c or $acl_m, followed either by a digit or an +underscore, but the remainder of the name can be any sequence of alphanumeric +characters and underscores that you choose. There is no limit on the number of +ACL variables. The two sets act as follows: + + * The values of those variables whose names begin with $acl_c persist + throughout an SMTP connection. They are never reset. Thus, a value that is + set while receiving one message is still available when receiving the next + message on the same SMTP connection. + + * The values of those variables whose names begin with $acl_m persist only + while a message is being received. They are reset afterwards. They are also + reset by MAIL, RSET, EHLO, HELO, and after starting up a TLS session. + +When a message is accepted, the current values of all the ACL variables are +preserved with the message and are subsequently made available at delivery +time. The ACL variables are set by a modifier called set. For example: + +accept hosts = whatever + set acl_m4 = some value +accept authenticated = * + set acl_c_auth = yes + +Note: A leading dollar sign is not used when naming a variable that is to be +set. If you want to set a variable without taking any action, you can use a +warn verb without any other modifiers or conditions. + +What happens if a syntactically valid but undefined ACL variable is referenced +depends on the setting of the strict_acl_vars option. If it is false (the +default), an empty string is substituted; if it is true, an error is generated. + +Versions of Exim before 4.64 have a limited set of numbered variables, but +their names are compatible, so there is no problem with upgrading. + + +43.20 Condition and modifier processing +--------------------------------------- + +An exclamation mark preceding a condition negates its result. For example: + +deny domains = *.dom.example + !verify = recipient + +causes the ACL to return "deny" if the recipient domain ends in dom.example and +the recipient address cannot be verified. Sometimes negation can be used on the +right-hand side of a condition. For example, these two statements are +equivalent: + +deny hosts = !192.168.3.4 +deny !hosts = 192.168.3.4 + +However, for many conditions (verify being a good example), only left-hand side +negation of the whole condition is possible. + +The arguments of conditions and modifiers are expanded. A forced failure of an +expansion causes a condition to be ignored, that is, it behaves as if the +condition is true. Consider these two statements: + +accept senders = ${lookup{$host_name}lsearch\ + {/some/file}{$value}fail} +accept senders = ${lookup{$host_name}lsearch\ + {/some/file}{$value}{}} + +Each attempts to look up a list of acceptable senders. If the lookup succeeds, +the returned list is searched, but if the lookup fails the behaviour is +different in the two cases. The fail in the first statement causes the +condition to be ignored, leaving no further conditions. The accept verb +therefore succeeds. The second statement, however, generates an empty list when +the lookup fails. No sender can match an empty list, so the condition fails, +and therefore the accept also fails. + +ACL modifiers appear mixed in with conditions in ACL statements. Some of them +specify actions that are taken as the conditions for a statement are checked; +others specify text for messages that are used when access is denied or a +warning is generated. The control modifier affects the way an incoming message +is handled. + +The positioning of the modifiers in an ACL statement is important, because the +processing of a verb ceases as soon as its outcome is known. Only those +modifiers that have already been encountered will take effect. For example, +consider this use of the message modifier: + +require message = Can't verify sender + verify = sender + message = Can't verify recipient + verify = recipient + message = This message cannot be used + +If sender verification fails, Exim knows that the result of the statement is +"deny", so it goes no further. The first message modifier has been seen, so its +text is used as the error message. If sender verification succeeds, but +recipient verification fails, the second message is used. If recipient +verification succeeds, the third message becomes "current", but is never used +because there are no more conditions to cause failure. + +For the deny verb, on the other hand, it is always the last message modifier +that is used, because all the conditions must be true for rejection to happen. +Specifying more than one message modifier does not make sense, and the message +can even be specified after all the conditions. For example: + +deny hosts = ... + !senders = *@my.domain.example + message = Invalid sender from client host + +The "deny" result does not happen until the end of the statement is reached, by +which time Exim has set up the message. + + +43.21 ACL modifiers +------------------- + +The ACL modifiers are as follows: + +add_header = <text> + + This modifier specifies one or more header lines that are to be added to an + incoming message, assuming, of course, that the message is ultimately + accepted. For details, see section 43.24. + +continue = <text> + + This modifier does nothing of itself, and processing of the ACL always + continues with the next condition or modifier. The value of continue is in + the side effects of expanding its argument. Typically this could be used to + update a database. It is really just a syntactic tidiness, to avoid having + to write rather ugly lines like this: + + condition = ${if eq{0}{<some expansion>}{true}{true}} + + Instead, all you need is + + continue = <some expansion> + +control = <text> + + This modifier affects the subsequent processing of the SMTP connection or + of an incoming message that is accepted. The effect of the first type of + control lasts for the duration of the connection, whereas the effect of the + second type lasts only until the current message has been received. The + message-specific controls always apply to the whole message, not to + individual recipients, even if the control modifier appears in a RCPT ACL. + + As there are now quite a few controls that can be applied, they are + described separately in section 43.22. The control modifier can be used in + several different ways. For example: + + + It can be at the end of an accept statement: + + accept ...some conditions + control = queue_only + + In this case, the control is applied when this statement yields + "accept", in other words, when the conditions are all true. + + + It can be in the middle of an accept statement: + + accept ...some conditions... + control = queue_only + ...some more conditions... + + If the first set of conditions are true, the control is applied, even + if the statement does not accept because one of the second set of + conditions is false. In this case, some subsequent statement must yield + "accept" for the control to be relevant. + + + It can be used with warn to apply the control, leaving the decision + about accepting or denying to a subsequent verb. For example: + + warn ...some conditions... + control = freeze + accept ... + + This example of warn does not contain message, log_message, or logwrite + , so it does not add anything to the message and does not write a log + entry. + + + If you want to apply a control unconditionally, you can use it with a + require verb. For example: + + require control = no_multiline_responses + +delay = <time> + + This modifier may appear in any ACL except notquit. It causes Exim to wait + for the time interval before proceeding. However, when testing Exim using + the -bh option, the delay is not actually imposed (an appropriate message + is output instead). The time is given in the usual Exim notation, and the + delay happens as soon as the modifier is processed. In an SMTP session, + pending output is flushed before the delay is imposed. + + Like control, delay can be used with accept or deny, for example: + + deny ...some conditions... + delay = 30s + + The delay happens if all the conditions are true, before the statement + returns "deny". Compare this with: + + deny delay = 30s + ...some conditions... + + which waits for 30s before processing the conditions. The delay modifier + can also be used with warn and together with control: + + warn ...some conditions... + delay = 2m + control = freeze + accept ... + + If delay is encountered when the SMTP PIPELINING extension is in use, + responses to several commands are no longer buffered and sent in one packet + (as they would normally be) because all output is flushed before imposing + the delay. This optimization is disabled so that a number of small delays + do not appear to the client as one large aggregated delay that might + provoke an unwanted timeout. You can, however, disable output flushing for + delay by using a control modifier to set no_delay_flush. + +endpass + + This modifier, which has no argument, is recognized only in accept and + discard statements. It marks the boundary between the conditions whose + failure causes control to pass to the next statement, and the conditions + whose failure causes the ACL to return "deny". This concept has proved to + be confusing to some people, so the use of endpass is no longer recommended + as "best practice". See the description of accept above for more details. + +log_message = <text> + + This modifier sets up a message that is used as part of the log message if + the ACL denies access or a warn statement's conditions are true. For + example: + + require log_message = wrong cipher suite $tls_in_cipher + encrypted = DES-CBC3-SHA + + log_message is also used when recipients are discarded by discard. For + example: + + discard <some conditions> + log_message = Discarded $local_part@$domain because... + + When access is denied, log_message adds to any underlying error message + that may exist because of a condition failure. For example, while verifying + a recipient address, a :fail: redirection might have already set up a + message. + + The message may be defined before the conditions to which it applies, + because the string expansion does not happen until Exim decides that access + is to be denied. This means that any variables that are set by the + condition are available for inclusion in the message. For example, the + $dnslist_<xxx> variables are set after a DNS black list lookup succeeds. If + the expansion of log_message fails, or if the result is an empty string, + the modifier is ignored. + + If you want to use a warn statement to log the result of an address + verification, you can use $acl_verify_message to include the verification + error message. + + If log_message is used with a warn statement, "Warning:" is added to the + start of the logged message. If the same warning log message is requested + more than once while receiving a single email message, only one copy is + actually logged. If you want to log multiple copies, use logwrite instead + of log_message. In the absence of log_message and logwrite, nothing is + logged for a successful warn statement. + + If log_message is not present and there is no underlying error message (for + example, from the failure of address verification), but message is present, + the message text is used for logging rejections. However, if any text for + logging contains newlines, only the first line is logged. In the absence of + both log_message and message, a default built-in message is used for + logging rejections. + +log_reject_target = <log name list> + + This modifier makes it possible to specify which logs are used for messages + about ACL rejections. Its argument is a colon-separated list of words that + can be "main", "reject", or "panic". The default is "main:reject". The list + may be empty, in which case a rejection is not logged at all. For example, + this ACL fragment writes no logging information when access is denied: + + deny <some conditions> + log_reject_target = + + This modifier can be used in SMTP and non-SMTP ACLs. It applies to both + permanent and temporary rejections. Its effect lasts for the rest of the + current ACL. + +logwrite = <text> + + This modifier writes a message to a log file as soon as it is encountered + when processing an ACL. (Compare log_message, which, except in the case of + warn and discard, is used only if the ACL statement denies access.) The + logwrite modifier can be used to log special incidents in ACLs. For + example: + + accept <some special conditions> + control = freeze + logwrite = froze message because ... + + By default, the message is written to the main log. However, it may begin + with a colon, followed by a comma-separated list of log names, and then + another colon, to specify exactly which logs are to be written. For + example: + + logwrite = :main,reject: text for main and reject logs + logwrite = :panic: text for panic log only + +message = <text> + + This modifier sets up a text string that is expanded and used as a response + message when an ACL statement terminates the ACL with an "accept", "deny", + or "defer" response. (In the case of the accept and discard verbs, there is + some complication if endpass is involved; see the description of accept for + details.) + + The expansion of the message happens at the time Exim decides that the ACL + is to end, not at the time it processes message. If the expansion fails, or + generates an empty string, the modifier is ignored. Here is an example + where message must be specified first, because the ACL ends with a + rejection if the hosts condition fails: + + require message = Host not recognized + hosts = 10.0.0.0/8 + + (Once a condition has failed, no further conditions or modifiers are + processed.) + + For ACLs that are triggered by SMTP commands, the message is returned as + part of the SMTP response. The use of message with accept (or discard) is + meaningful only for SMTP, as no message is returned when a non-SMTP message + is accepted. In the case of the connect ACL, accepting with a message + modifier overrides the value of smtp_banner. For the EHLO/HELO ACL, a + customized accept message may not contain more than one line (otherwise it + will be truncated at the first newline and a panic logged), and it cannot + affect the EHLO options. + + When SMTP is involved, the message may begin with an overriding response + code, consisting of three digits optionally followed by an "extended + response code" of the form n.n.n, each code being followed by a space. For + example: + + deny message = 599 1.2.3 Host not welcome + hosts = 192.168.34.0/24 + + The first digit of the supplied response code must be the same as would be + sent by default. A panic occurs if it is not. Exim uses a 550 code when it + denies access, but for the predata ACL, note that the default success code + is 354, not 2xx. + + Notwithstanding the previous paragraph, for the QUIT ACL, unlike the + others, the message modifier cannot override the 221 response code. + + The text in a message modifier is literal; any quotes are taken as + literals, but because the string is expanded, backslash escapes are + processed anyway. If the message contains newlines, this gives rise to a + multi-line SMTP response. + + For ACLs that are called by an acl = ACL condition, the message is stored + in $acl_verify_message, from which the calling ACL may use it. + + If message is used on a statement that verifies an address, the message + specified overrides any message that is generated by the verification + process. However, the original message is available in the variable + $acl_verify_message, so you can incorporate it into your message if you + wish. In particular, if you want the text from :fail: items in redirect + routers to be passed back as part of the SMTP response, you should either + not use a message modifier, or make use of $acl_verify_message. + + For compatibility with previous releases of Exim, a message modifier that + is used with a warn verb behaves in a similar way to the add_header + modifier, but this usage is now deprecated. However, message acts only when + all the conditions are true, wherever it appears in an ACL command, whereas + add_header acts as soon as it is encountered. If message is used with warn + in an ACL that is not concerned with receiving a message, it has no effect. + +queue = <text> + + This modifier specifies the use of a named queue for spool files for the + message. It can only be used before the message is received (i.e. not in + the DATA ACL). This could be used, for example, for known high-volume burst + sources of traffic, or for quarantine of messages. Separate queue-runner + processes will be needed for named queues. If the text after expansion is + empty, the default queue is used. + +remove_header = <text> + + This modifier specifies one or more header names in a colon-separated list + that are to be removed from an incoming message, assuming, of course, that + the message is ultimately accepted. For details, see section 43.25. + +set <acl_name> = <value> + + This modifier puts a value into one of the ACL variables (see section 43.19 + ). + +udpsend = <parameters> + + This modifier sends a UDP packet, for purposes such as statistics + collection or behaviour monitoring. The parameters are expanded, and the + result of the expansion must be a colon-separated list consisting of a + destination server, port number, and the packet contents. The server can be + specified as a host name or IPv4 or IPv6 address. The separator can be + changed with the usual angle bracket syntax. For example, you might want to + collect information on which hosts connect when: + + udpsend = <; 2001:dB8::dead:beef ; 1234 ;\ + $tod_zulu $sender_host_address + + +43.22 Use of the control modifier +--------------------------------- + +The control modifier supports the following settings: + +control = allow_auth_unadvertised + + This modifier allows a client host to use the SMTP AUTH command even when + it has not been advertised in response to EHLO. Furthermore, because there + are apparently some really broken clients that do this, Exim will accept + AUTH after HELO (rather than EHLO) when this control is set. It should be + used only if you really need it, and you should limit its use to those + broken clients that do not work without it. For example: + + warn hosts = 192.168.34.25 + control = allow_auth_unadvertised + + Normally, when an Exim server receives an AUTH command, it checks the name + of the authentication mechanism that is given in the command to ensure that + it matches an advertised mechanism. When this control is set, the check + that a mechanism has been advertised is bypassed. Any configured mechanism + can be used by the client. This control is permitted only in the connection + and HELO ACLs. + +control = caseful_local_part, control = caselower_local_part + + These two controls are permitted only in the ACL specified by acl_smtp_rcpt + (that is, during RCPT processing). By default, the contents of $local_part + are lower cased before ACL processing. If "caseful_local_part" is + specified, any uppercase letters in the original local part are restored in + $local_part for the rest of the ACL, or until a control that sets + "caselower_local_part" is encountered. + + These controls affect only the current recipient. Moreover, they apply only + to local part handling that takes place directly in the ACL (for example, + as a key in lookups). If a test to verify the recipient is obeyed, the + case-related handling of the local part during the verification is + controlled by the router configuration (see the caseful_local_part generic + router option). + + This facility could be used, for example, to add a spam score to local + parts containing upper case letters. For example, using $acl_m4 to + accumulate the spam score: + + warn control = caseful_local_part + set acl_m4 = ${eval:\ + $acl_m4 + \ + ${if match{$local_part}{[A-Z]}{1}{0}}\ + } + control = caselower_local_part + + Notice that we put back the lower cased version afterwards, assuming that + is what is wanted for subsequent tests. + +control = cutthrough_delivery/<options> + + This option requests delivery be attempted while the item is being + received. + + The option is usable in the RCPT ACL. If enabled for a message received via + smtp and routed to an smtp transport, and only one transport, interface, + destination host and port combination is used for all recipients of the + message, then the delivery connection is made while the receiving + connection is open and data is copied from one to the other. + + An attempt to set this option for any recipient but the first for a mail + will be quietly ignored. If a recipient-verify callout (with use_sender) + connection is subsequently requested in the same ACL it is held open and + used for any subsequent recipients and the data, otherwise one is made + after the initial RCPT ACL completes. + + Note that routers are used in verify mode, and cannot depend on content of + received headers. Note also that headers cannot be modified by any of the + post-data ACLs (DATA, MIME and DKIM). Headers may be modified by routers + (subject to the above) and transports. The Received-By: header is generated + as soon as the body reception starts, rather than the traditional time + after the full message is received; this will affect the timestamp. + + All the usual ACLs are called; if one results in the message being + rejected, all effort spent in delivery (including the costs on the ultimate + destination) will be wasted. Note that in the case of data-time ACLs this + includes the entire message body. + + Cutthrough delivery is not supported via transport-filters or when DKIM + signing of outgoing messages is done, because it sends data to the ultimate + destination before the entire message has been received from the source. It + is not supported for messages received with the SMTP PRDR or CHUNKING + options in use. + + Should the ultimate destination system positively accept or reject the + mail, a corresponding indication is given to the source system and nothing + is queued. If the item is successfully delivered in cutthrough mode the + delivery log lines are tagged with ">>" rather than "=>" and appear before + the acceptance "<=" line. + + If there is a temporary error the item is queued for later delivery in the + usual fashion. This behaviour can be adjusted by appending the option defer + =<value> to the control; the default value is "spool" and the alternate + value "pass" copies an SMTP defer response from the target back to the + initiator and does not queue the message. Note that this is independent of + any recipient verify conditions in the ACL. + + Delivery in this mode avoids the generation of a bounce mail to a (possibly + faked) sender when the destination system is doing content-scan based + rejection. + +control = debug/<options> + + This control turns on debug logging, almost as though Exim had been invoked + with "-d", with the output going to a new logfile in the usual logs + directory, by default called debuglog. The filename can be adjusted with + the tag option, which may access any variables already defined. The logging + may be adjusted with the opts option, which takes the same values as the + "-d" command-line option. Logging started this way may be stopped, and the + file removed, with the kill option. Some examples (which depend on + variables that don't exist in all contexts): + + control = debug + control = debug/tag=.$sender_host_address + control = debug/opts=+expand+acl + control = debug/tag=.$message_exim_id/opts=+expand + control = debug/kill + +control = dkim_disable_verify + + This control turns off DKIM verification processing entirely. For details + on the operation and configuration of DKIM, see section 57.1. + +control = dscp/<value> + + This option causes the DSCP value associated with the socket for the + inbound connection to be adjusted to a given value, given as one of a + number of fixed strings or to numeric value. The -bI:dscp option may be + used to ask Exim which names it knows of. Common values include + "throughput", "mincost", and on newer systems "ef", "af41", etc. Numeric + values may be in the range 0 to 0x3F. + + The outbound packets from Exim will be marked with this value in the header + (for IPv4, the TOS field; for IPv6, the TCLASS field); there is no + guarantee that these values will have any effect, not be stripped by + networking equipment, or do much of anything without cooperation with your + Network Engineer and those of all network operators between the source and + destination. + +control = enforce_sync, control = no_enforce_sync + + These controls make it possible to be selective about when SMTP + synchronization is enforced. The global option smtp_enforce_sync specifies + the initial state of the switch (it is true by default). See the + description of this option in chapter 14 for details of SMTP + synchronization checking. + + The effect of these two controls lasts for the remainder of the SMTP + connection. They can appear in any ACL except the one for the non-SMTP + messages. The most straightforward place to put them is in the ACL defined + by acl_smtp_connect, which is run at the start of an incoming SMTP + connection, before the first synchronization check. The expected use is to + turn off the synchronization checks for badly-behaved hosts that you + nevertheless need to work with. + +control = fakedefer/<message> + + This control works in exactly the same way as fakereject (described below) + except that it causes an SMTP 450 response after the message data instead + of a 550 response. You must take care when using fakedefer because it + causes the messages to be duplicated when the sender retries. Therefore, + you should not use fakedefer if the message is to be delivered normally. + +control = fakereject/<message> + + This control is permitted only for the MAIL, RCPT, and DATA ACLs, in other + words, only when an SMTP message is being received. If Exim accepts the + message, instead the final 250 response, a 550 rejection message is sent. + However, Exim proceeds to deliver the message as normal. The control + applies only to the current message, not to any subsequent ones that may be + received in the same SMTP connection. + + The text for the 550 response is taken from the control modifier. If no + message is supplied, the following is used: + + 550-Your message has been rejected but is being + 550-kept for evaluation. + 550-If it was a legitimate message, it may still be + 550 delivered to the target recipient(s). + + This facility should be used with extreme caution. + +control = freeze + + This control is permitted only for the MAIL, RCPT, DATA, and non-SMTP ACLs, + in other words, only when a message is being received. If the message is + accepted, it is placed on Exim's queue and frozen. The control applies only + to the current message, not to any subsequent ones that may be received in + the same SMTP connection. + + This modifier can optionally be followed by "/no_tell". If the global + option freeze_tell is set, it is ignored for the current message (that is, + nobody is told about the freezing), provided all the control=freeze + modifiers that are obeyed for the current message have the "/no_tell" + option. + +control = no_delay_flush + + Exim normally flushes SMTP output before implementing a delay in an ACL, to + avoid unexpected timeouts in clients when the SMTP PIPELINING extension is + in use. This control, as long as it is encountered before the delay + modifier, disables such output flushing. + +control = no_callout_flush + + Exim normally flushes SMTP output before performing a callout in an ACL, to + avoid unexpected timeouts in clients when the SMTP PIPELINING extension is + in use. This control, as long as it is encountered before the verify + condition that causes the callout, disables such output flushing. + +control = no_mbox_unspool + + This control is available when Exim is compiled with the content scanning + extension. Content scanning may require a copy of the current message, or + parts of it, to be written in "mbox format" to a spool file, for passing to + a virus or spam scanner. Normally, such copies are deleted when they are no + longer needed. If this control is set, the copies are not deleted. The + control applies only to the current message, not to any subsequent ones + that may be received in the same SMTP connection. It is provided for + debugging purposes and is unlikely to be useful in production. + +control = no_multiline_responses + + This control is permitted for any ACL except the one for non-SMTP messages. + It seems that there are broken clients in use that cannot handle multiline + SMTP responses, despite the fact that RFC 821 defined them over 20 years + ago. + + If this control is set, multiline SMTP responses from ACL rejections are + suppressed. One way of doing this would have been to put out these + responses as one long line. However, RFC 2821 specifies a maximum of 512 + bytes per response ("use multiline responses for more" it says - ha!), and + some of the responses might get close to that. So this facility, which is + after all only a sop to broken clients, is implemented by doing two very + easy things: + + + Extra information that is normally output as part of a rejection caused + by sender verification failure is omitted. Only the final line + (typically "sender verification failed") is sent. + + + If a message modifier supplies a multiline response, only the first + line is output. + + The setting of the switch can, of course, be made conditional on the + calling host. Its effect lasts until the end of the SMTP connection. + +control = no_pipelining + + This control turns off the advertising of the PIPELINING extension to SMTP + in the current session. To be useful, it must be obeyed before Exim sends + its response to an EHLO command. Therefore, it should normally appear in an + ACL controlled by acl_smtp_connect or acl_smtp_helo. See also + pipelining_advertise_hosts. + +control = queue_only + + This control is permitted only for the MAIL, RCPT, DATA, and non-SMTP ACLs, + in other words, only when a message is being received. If the message is + accepted, it is placed on Exim's queue and left there for delivery by a + subsequent queue runner. No immediate delivery process is started. In other + words, it has the effect as the queue_only global option. However, the + control applies only to the current message, not to any subsequent ones + that may be received in the same SMTP connection. + +control = submission/<options> + + This control is permitted only for the MAIL, RCPT, and start of data ACLs + (the latter is the one defined by acl_smtp_predata). Setting it tells Exim + that the current message is a submission from a local MUA. In this case, + Exim operates in "submission mode", and applies certain fixups to the + message if necessary. For example, it adds a Date: header line if one is + not present. This control is not permitted in the acl_smtp_data ACL, + because that is too late (the message has already been created). + + Chapter 47 describes the processing that Exim applies to messages. Section + 47.1 covers the processing that happens in submission mode; the available + options for this control are described there. The control applies only to + the current message, not to any subsequent ones that may be received in the + same SMTP connection. + +control = suppress_local_fixups + + This control applies to locally submitted (non TCP/IP) messages, and is the + complement of "control = submission". It disables the fixups that are + normally applied to locally-submitted messages. Specifically: + + + Any Sender: header line is left alone (in this respect, it is a dynamic + version of local_sender_retain). + + + No Message-ID:, From:, or Date: header lines are added. + + + There is no check that From: corresponds to the actual sender. + + This control may be useful when a remotely-originated message is accepted, + passed to some scanning program, and then re-submitted for delivery. It can + be used only in the acl_smtp_mail, acl_smtp_rcpt, acl_smtp_predata, and + acl_not_smtp_start ACLs, because it has to be set before the message's data + is read. + + Note: This control applies only to the current message, not to any others + that are being submitted at the same time using -bs or -bS. + +control = utf8_downconvert + + This control enables conversion of UTF-8 in message addresses to a-label + form. For details see section 59.1. + + +43.23 Summary of message fixup control +-------------------------------------- + +All four possibilities for message fixups can be specified: + + * Locally submitted, fixups applied: the default. + + * Locally submitted, no fixups applied: use "control = + suppress_local_fixups". + + * Remotely submitted, no fixups applied: the default. + + * Remotely submitted, fixups applied: use "control = submission". + + +43.24 Adding header lines in ACLs +--------------------------------- + +The add_header modifier can be used to add one or more extra header lines to an +incoming message, as in this example: + +warn dnslists = sbl.spamhaus.org : \ + dialup.mail-abuse.org + add_header = X-blacklisted-at: $dnslist_domain + +The add_header modifier is permitted in the MAIL, RCPT, PREDATA, DATA, MIME, +DKIM, and non-SMTP ACLs (in other words, those that are concerned with +receiving a message). The message must ultimately be accepted for add_header to +have any significant effect. You can use add_header with any ACL verb, +including deny (though this is potentially useful only in a RCPT ACL). + +Headers will not be added to the message if the modifier is used in DATA, MIME +or DKIM ACLs for a message delivered by cutthrough routing. + +Leading and trailing newlines are removed from the data for the add_header +modifier; if it then contains one or more newlines that are not followed by a +space or a tab, it is assumed to contain multiple header lines. Each one is +checked for valid syntax; "X-ACL-Warn:" is added to the front of any line that +is not a valid header line. + +Added header lines are accumulated during the MAIL, RCPT, and predata ACLs. +They are added to the message before processing the DATA and MIME ACLs. +However, if an identical header line is requested more than once, only one copy +is actually added to the message. Further header lines may be accumulated +during the DATA and MIME ACLs, after which they are added to the message, again +with duplicates suppressed. Thus, it is possible to add two identical header +lines to an SMTP message, but only if one is added before DATA and one after. +In the case of non-SMTP messages, new headers are accumulated during the +non-SMTP ACLs, and are added to the message after all the ACLs have run. If a +message is rejected after DATA or by the non-SMTP ACL, all added header lines +are included in the entry that is written to the reject log. + +Header lines are not visible in string expansions of message headers until they +are added to the message. It follows that header lines defined in the MAIL, +RCPT, and predata ACLs are not visible until the DATA ACL and MIME ACLs are +run. Similarly, header lines that are added by the DATA or MIME ACLs are not +visible in those ACLs. Because of this restriction, you cannot use header lines +as a way of passing data between (for example) the MAIL and RCPT ACLs. If you +want to do this, you can use ACL variables, as described in section 43.19. + +The list of headers yet to be added is given by the $headers_added variable. + +The add_header modifier acts immediately as it is encountered during the +processing of an ACL. Notice the difference between these two cases: + +accept add_header = ADDED: some text + <some condition> + +accept <some condition> + add_header = ADDED: some text + +In the first case, the header line is always added, whether or not the +condition is true. In the second case, the header line is added only if the +condition is true. Multiple occurrences of add_header may occur in the same ACL +statement. All those that are encountered before a condition fails are +honoured. + +For compatibility with previous versions of Exim, a message modifier for a warn +verb acts in the same way as add_header, except that it takes effect only if +all the conditions are true, even if it appears before some of them. +Furthermore, only the last occurrence of message is honoured. This usage of +message is now deprecated. If both add_header and message are present on a warn +verb, both are processed according to their specifications. + +By default, new header lines are added to a message at the end of the existing +header lines. However, you can specify that any particular header line should +be added right at the start (before all the Received: lines), immediately after +the first block of Received: lines, or immediately before any line that is not +a Received: or Resent-something: header. + +This is done by specifying ":at_start:", ":after_received:", or +":at_start_rfc:" (or, for completeness, ":at_end:") before the text of the +header line, respectively. (Header text cannot start with a colon, as there has +to be a header name first.) For example: + +warn add_header = \ + :after_received:X-My-Header: something or other... + +If more than one header line is supplied in a single add_header modifier, each +one is treated independently and can therefore be placed differently. If you +add more than one line at the start, or after the Received: block, they end up +in reverse order. + +Warning: This facility currently applies only to header lines that are added in +an ACL. It does NOT work for header lines that are added in a system filter or +in a router or transport. + + +43.25 Removing header lines in ACLs +----------------------------------- + +The remove_header modifier can be used to remove one or more header lines from +an incoming message, as in this example: + +warn message = Remove internal headers + remove_header = x-route-mail1 : x-route-mail2 + +The remove_header modifier is permitted in the MAIL, RCPT, PREDATA, DATA, MIME, +DKIM, and non-SMTP ACLs (in other words, those that are concerned with +receiving a message). The message must ultimately be accepted for remove_header +to have any significant effect. You can use remove_header with any ACL verb, +including deny, though this is really not useful for any verb that doesn't +result in a delivered message. + +Headers will not be removed from the message if the modifier is used in DATA, +MIME or DKIM ACLs for a message delivered by cutthrough routing. + +More than one header can be removed at the same time by using a colon separated +list of header names. The header matching is case insensitive. Wildcards are +not permitted, nor is list expansion performed, so you cannot use hostlists to +create a list of headers, however both connection and message variable +expansion are performed ($acl_c_* and $acl_m_*), illustrated in this example: + +warn hosts = +internal_hosts + set acl_c_ihdrs = x-route-mail1 : x-route-mail2 +warn message = Remove internal headers + remove_header = $acl_c_ihdrs + +Header names for removal are accumulated during the MAIL, RCPT, and predata +ACLs. Matching header lines are removed from the message before processing the +DATA and MIME ACLs. If multiple header lines match, all are removed. There is +no harm in attempting to remove the same header twice nor in removing a +non-existent header. Further header lines to be removed may be accumulated +during the DATA and MIME ACLs, after which they are removed from the message, +if present. In the case of non-SMTP messages, headers to be removed are +accumulated during the non-SMTP ACLs, and are removed from the message after +all the ACLs have run. If a message is rejected after DATA or by the non-SMTP +ACL, there really is no effect because there is no logging of what headers +would have been removed. + +Header lines are not visible in string expansions until the DATA phase when it +is received. Any header lines removed in the MAIL, RCPT, and predata ACLs are +not visible in the DATA ACL and MIME ACLs. Similarly, header lines that are +removed by the DATA or MIME ACLs are still visible in those ACLs. Because of +this restriction, you cannot use header lines as a way of controlling data +passed between (for example) the MAIL and RCPT ACLs. If you want to do this, +you should instead use ACL variables, as described in section 43.19. + +The remove_header modifier acts immediately as it is encountered during the +processing of an ACL. Notice the difference between these two cases: + +accept remove_header = X-Internal + <some condition> + +accept <some condition> + remove_header = X-Internal + +In the first case, the header line is always removed, whether or not the +condition is true. In the second case, the header line is removed only if the +condition is true. Multiple occurrences of remove_header may occur in the same +ACL statement. All those that are encountered before a condition fails are +honoured. + +Warning: This facility currently applies only to header lines that are present +during ACL processing. It does NOT remove header lines that are added in a +system filter or in a router or transport. + + +43.26 ACL conditions +-------------------- + +Some of the conditions listed in this section are available only when Exim is +compiled with the content-scanning extension. They are included here briefly +for completeness. More detailed descriptions can be found in the discussion on +content scanning in chapter 44. + +Not all conditions are relevant in all circumstances. For example, testing +senders and recipients does not make sense in an ACL that is being run as the +result of the arrival of an ETRN command, and checks on message headers can be +done only in the ACLs specified by acl_smtp_data and acl_not_smtp. You can use +the same condition (with different parameters) more than once in the same ACL +statement. This provides a way of specifying an "and" conjunction. The +conditions are as follows: + +acl = <name of acl or ACL string or file name > + + The possible values of the argument are the same as for the acl_smtp_xxx + options. The named or inline ACL is run. If it returns "accept" the + condition is true; if it returns "deny" the condition is false. If it + returns "defer", the current ACL returns "defer" unless the condition is on + a warn verb. In that case, a "defer" return makes the condition false. This + means that further processing of the warn verb ceases, but processing of + the ACL continues. + + If the argument is a named ACL, up to nine space-separated optional values + can be appended; they appear within the called ACL in $acl_arg1 to + $acl_arg9, and $acl_narg is set to the count of values. Previous values of + these variables are restored after the call returns. The name and values + are expanded separately. Note that spaces in complex expansions which are + used as arguments will act as argument separators. + + If the nested acl returns "drop" and the outer condition denies access, the + connection is dropped. If it returns "discard", the verb must be accept or + discard, and the action is taken immediately - no further conditions are + tested. + + ACLs may be nested up to 20 deep; the limit exists purely to catch runaway + loops. This condition allows you to use different ACLs in different + circumstances. For example, different ACLs can be used to handle RCPT + commands for different local users or different local domains. + +authenticated = <string list> + + If the SMTP connection is not authenticated, the condition is false. + Otherwise, the name of the authenticator is tested against the list. To + test for authentication by any authenticator, you can set + + authenticated = * + +condition = <string> + + This feature allows you to make up custom conditions. If the result of + expanding the string is an empty string, the number zero, or one of the + strings "no" or "false", the condition is false. If the result is any + non-zero number, or one of the strings "yes" or "true", the condition is + true. For any other value, some error is assumed to have occurred, and the + ACL returns "defer". However, if the expansion is forced to fail, the + condition is ignored. The effect is to treat it as true, whether it is + positive or negative. + +decode = <location> + + This condition is available only when Exim is compiled with the + content-scanning extension, and it is allowed only in the ACL defined by + acl_smtp_mime. It causes the current MIME part to be decoded into a file. + If all goes well, the condition is true. It is false only if there are + problems such as a syntax error or a memory shortage. For more details, see + chapter 44. + +dnslists = <list of domain names and other data> + + This condition checks for entries in DNS black lists. These are also known + as "RBL lists", after the original Realtime Blackhole List, but note that + the use of the lists at mail-abuse.org now carries a charge. There are too + many different variants of this condition to describe briefly here. See + sections 43.27-43.37 for details. + +domains = <domain list> + + This condition is relevant only after a RCPT command. It checks that the + domain of the recipient address is in the domain list. If percent-hack + processing is enabled, it is done before this test is done. If the check + succeeds with a lookup, the result of the lookup is placed in $domain_data + until the next domains test. + + Note carefully (because many people seem to fall foul of this): you cannot + use domains in a DATA ACL. + +encrypted = <string list> + + If the SMTP connection is not encrypted, the condition is false. Otherwise, + the name of the cipher suite in use is tested against the list. To test for + encryption without testing for any specific cipher suite(s), set + + encrypted = * + +hosts = <host list> + + This condition tests that the calling host matches the host list. If you + have name lookups or wildcarded host names and IP addresses in the same + host list, you should normally put the IP addresses first. For example, you + could have: + + accept hosts = 10.9.8.7 : dbm;/etc/friendly/hosts + + The lookup in this example uses the host name for its key. This is implied + by the lookup type "dbm". (For a host address lookup you would use + "net-dbm" and it wouldn't matter which way round you had these two items.) + + The reason for the problem with host names lies in the left-to-right way + that Exim processes lists. It can test IP addresses without doing any DNS + lookups, but when it reaches an item that requires a host name, it fails if + it cannot find a host name to compare with the pattern. If the above list + is given in the opposite order, the accept statement fails for a host whose + name cannot be found, even if its IP address is 10.9.8.7. + + If you really do want to do the name check first, and still recognize the + IP address even if the name lookup fails, you can rewrite the ACL like + this: + + accept hosts = dbm;/etc/friendly/hosts + accept hosts = 10.9.8.7 + + The default action on failing to find the host name is to assume that the + host is not in the list, so the first accept statement fails. The second + statement can then check the IP address. + + If a hosts condition is satisfied by means of a lookup, the result of the + lookup is made available in the $host_data variable. This allows you, for + example, to set up a statement like this: + + deny hosts = net-lsearch;/some/file + message = $host_data + + which gives a custom error message for each denied host. + +local_parts = <local part list> + + This condition is relevant only after a RCPT command. It checks that the + local part of the recipient address is in the list. If percent-hack + processing is enabled, it is done before this test. If the check succeeds + with a lookup, the result of the lookup is placed in $local_part_data, + which remains set until the next local_parts test. + +malware = <option> + + This condition is available only when Exim is compiled with the + content-scanning extension. It causes the incoming message to be scanned + for viruses. For details, see chapter 44. + +mime_regex = <list of regular expressions> + + This condition is available only when Exim is compiled with the + content-scanning extension, and it is allowed only in the ACL defined by + acl_smtp_mime. It causes the current MIME part to be scanned for a match + with any of the regular expressions. For details, see chapter 44. + +ratelimit = <parameters> + + This condition can be used to limit the rate at which a user or host + submits messages. Details are given in section 43.38. + +recipients = <address list> + + This condition is relevant only after a RCPT command. It checks the entire + recipient address against a list of recipients. + +regex = <list of regular expressions> + + This condition is available only when Exim is compiled with the + content-scanning extension, and is available only in the DATA, MIME, and + non-SMTP ACLs. It causes the incoming message to be scanned for a match + with any of the regular expressions. For details, see chapter 44. + +sender_domains = <domain list> + + This condition tests the domain of the sender of the message against the + given domain list. Note: The domain of the sender address is in + $sender_address_domain. It is not put in $domain during the testing of this + condition. This is an exception to the general rule for testing domain + lists. It is done this way so that, if this condition is used in an ACL for + a RCPT command, the recipient's domain (which is in $domain) can be used to + influence the sender checking. + + Warning: It is a bad idea to use this condition on its own as a control on + relaying, because sender addresses are easily, and commonly, forged. + +senders = <address list> + + This condition tests the sender of the message against the given list. To + test for a bounce message, which has an empty sender, set + + senders = : + + Warning: It is a bad idea to use this condition on its own as a control on + relaying, because sender addresses are easily, and commonly, forged. + +spam = <username> + + This condition is available only when Exim is compiled with the + content-scanning extension. It causes the incoming message to be scanned by + SpamAssassin. For details, see chapter 44. + +verify = certificate + + This condition is true in an SMTP session if the session is encrypted, and + a certificate was received from the client, and the certificate was + verified. The server requests a certificate only if the client matches + tls_verify_hosts or tls_try_verify_hosts (see chapter 42). + +verify = csa + + This condition checks whether the sending host (the client) is authorized + to send email. Details of how this works are given in section 43.50. + +verify = header_names_ascii + + This condition is relevant only in an ACL that is run after a message has + been received, that is, in an ACL specified by acl_smtp_data or + acl_not_smtp. It checks all header names (not the content) to make sure + there are no non-ASCII characters, also excluding control characters. The + allowable characters are decimal ASCII values 33 through 126. + + Exim itself will handle headers with non-ASCII characters, but it can cause + problems for downstream applications, so this option will allow their + detection and rejection in the DATA ACL's. + +verify = header_sender/<options> + + This condition is relevant only in an ACL that is run after a message has + been received, that is, in an ACL specified by acl_smtp_data or + acl_not_smtp. It checks that there is a verifiable address in at least one + of the Sender:, Reply-To:, or From: header lines. Such an address is + loosely thought of as a "sender" address (hence the name of the test). + However, an address that appears in one of these headers need not be an + address that accepts bounce messages; only sender addresses in envelopes + are required to accept bounces. Therefore, if you use the callout option on + this check, you might want to arrange for a non-empty address in the MAIL + command. + + Details of address verification and the options are given later, starting + at section 43.44 (callouts are described in section 43.45). You can combine + this condition with the senders condition to restrict it to bounce messages + only: + + deny senders = : + message = A valid sender header is required for bounces + !verify = header_sender + +verify = header_syntax + + This condition is relevant only in an ACL that is run after a message has + been received, that is, in an ACL specified by acl_smtp_data or + acl_not_smtp. It checks the syntax of all header lines that can contain + lists of addresses (Sender:, From:, Reply-To:, To:, Cc:, and Bcc:), + returning true if there are no problems. Unqualified addresses (local parts + without domains) are permitted only in locally generated messages and from + hosts that match sender_unqualified_hosts or recipient_unqualified_hosts, + as appropriate. + + Note that this condition is a syntax check only. However, a common spamming + ploy used to be to send syntactically invalid headers such as + + To: @ + + and this condition can be used to reject such messages, though they are not + as common as they used to be. + +verify = helo + + This condition is true if a HELO or EHLO command has been received from the + client host, and its contents have been verified. If there has been no + previous attempt to verify the HELO/EHLO contents, it is carried out when + this condition is encountered. See the description of the helo_verify_hosts + and helo_try_verify_hosts options for details of how to request + verification independently of this condition. + + For SMTP input that does not come over TCP/IP (the -bs command line + option), this condition is always true. + +verify = not_blind + + This condition checks that there are no blind (bcc) recipients in the + message. Every envelope recipient must appear either in a To: header line + or in a Cc: header line for this condition to be true. Local parts are + checked case-sensitively; domains are checked case-insensitively. If + Resent-To: or Resent-Cc: header lines exist, they are also checked. This + condition can be used only in a DATA or non-SMTP ACL. + + There are, of course, many legitimate messages that make use of blind (bcc) + recipients. This check should not be used on its own for blocking messages. + +verify = recipient/<options> + + This condition is relevant only after a RCPT command. It verifies the + current recipient. Details of address verification are given later, + starting at section 43.44. After a recipient has been verified, the value + of $address_data is the last value that was set while routing the address. + This applies even if the verification fails. When an address that is being + verified is redirected to a single address, verification continues with the + new address, and in that case, the subsequent value of $address_data is the + value for the child address. + +verify = reverse_host_lookup/<options> + + This condition ensures that a verified host name has been looked up from + the IP address of the client host. (This may have happened already if the + host name was needed for checking a host list, or if the host matched + host_lookup.) Verification ensures that the host name obtained from a + reverse DNS lookup, or one of its aliases, does, when it is itself looked + up in the DNS, yield the original IP address. + + There is one possible option, "defer_ok". If this is present and a DNS + operation returns a temporary error, the verify condition succeeds. + + If this condition is used for a locally generated message (that is, when + there is no client host involved), it always succeeds. + +verify = sender/<options> + + This condition is relevant only after a MAIL or RCPT command, or after a + message has been received (the acl_smtp_data or acl_not_smtp ACLs). If the + message's sender is empty (that is, this is a bounce message), the + condition is true. Otherwise, the sender address is verified. + + If there is data in the $address_data variable at the end of routing, its + value is placed in $sender_address_data at the end of verification. This + value can be used in subsequent conditions and modifiers in the same ACL + statement. It does not persist after the end of the current statement. If + you want to preserve the value for longer, you can save it in an ACL + variable. + + Details of verification are given later, starting at section 43.44. Exim + caches the result of sender verification, to avoid doing it more than once + per message. + +verify = sender=<address>/<options> + + This is a variation of the previous option, in which a modified address is + verified as a sender. + + Note that '/' is legal in local-parts; if the address may have such (eg. is + generated from the received message) they must be protected from the + options parsing by doubling: + + verify = sender=${sg{${address:$h_sender:}}{/}{//}} + + +43.27 Using DNS lists +--------------------- + +In its simplest form, the dnslists condition tests whether the calling host is +on at least one of a number of DNS lists by looking up the inverted IP address +in one or more DNS domains. (Note that DNS list domains are not mail domains, +so the "+" syntax for named lists doesn't work - it is used for special options +instead.) For example, if the calling host's IP address is 192.168.62.43, and +the ACL statement is + +deny dnslists = blackholes.mail-abuse.org : \ + dialups.mail-abuse.org + +the following records are looked up: + +43.62.168.192.blackholes.mail-abuse.org +43.62.168.192.dialups.mail-abuse.org + +As soon as Exim finds an existing DNS record, processing of the list stops. +Thus, multiple entries on the list provide an "or" conjunction. If you want to +test that a host is on more than one list (an "and" conjunction), you can use +two separate conditions: + +deny dnslists = blackholes.mail-abuse.org + dnslists = dialups.mail-abuse.org + +If a DNS lookup times out or otherwise fails to give a decisive answer, Exim +behaves as if the host does not match the list item, that is, as if the DNS +record does not exist. If there are further items in the DNS list, they are +processed. + +This is usually the required action when dnslists is used with deny (which is +the most common usage), because it prevents a DNS failure from blocking mail. +However, you can change this behaviour by putting one of the following special +items in the list: + ++include_unknown behave as if the item is on the list ++exclude_unknown behave as if the item is not on the list (default) ++defer_unknown give a temporary error + +Each of these applies to any subsequent items on the list. For example: + +deny dnslists = +defer_unknown : foo.bar.example + +Testing the list of domains stops as soon as a match is found. If you want to +warn for one list and block for another, you can use two different statements: + +deny dnslists = blackholes.mail-abuse.org +warn message = X-Warn: sending host is on dialups list + dnslists = dialups.mail-abuse.org + +DNS list lookups are cached by Exim for the duration of the SMTP session (but +limited by the DNS return TTL value), so a lookup based on the IP address is +done at most once for any incoming connection (assuming long-enough TTL). Exim +does not share information between multiple incoming connections (but your +local name server cache should be active). + +There are a number of DNS lists to choose from, some commercial, some free, or +free for small deployments. An overview can be found at https:// +en.wikipedia.org/wiki/Comparison_of_DNS_blacklists. + + +43.28 Specifying the IP address for a DNS list lookup +----------------------------------------------------- + +By default, the IP address that is used in a DNS list lookup is the IP address +of the calling host. However, you can specify another IP address by listing it +after the domain name, introduced by a slash. For example: + +deny dnslists = black.list.tld/192.168.1.2 + +This feature is not very helpful with explicit IP addresses; it is intended for +use with IP addresses that are looked up, for example, the IP addresses of the +MX hosts or nameservers of an email sender address. For an example, see section +43.30 below. + + +43.29 DNS lists keyed on domain names +------------------------------------- + +There are some lists that are keyed on domain names rather than inverted IP +addresses (see, e.g., the domain based zones link at http:// +www.rfc-ignorant.org/). No reversing of components is used with these lists. +You can change the name that is looked up in a DNS list by listing it after the +domain name, introduced by a slash. For example, + +deny message = Sender's domain is listed at $dnslist_domain + dnslists = dsn.rfc-ignorant.org/$sender_address_domain + +This particular example is useful only in ACLs that are obeyed after the RCPT +or DATA commands, when a sender address is available. If (for example) the +message's sender is user@tld.example the name that is looked up by this example +is + +tld.example.dsn.rfc-ignorant.org + +A single dnslists condition can contain entries for both names and IP +addresses. For example: + +deny dnslists = sbl.spamhaus.org : \ + dsn.rfc-ignorant.org/$sender_address_domain + +The first item checks the sending host's IP address; the second checks a domain +name. The whole condition is true if either of the DNS lookups succeeds. + + +43.30 Multiple explicit keys for a DNS list +------------------------------------------- + +The syntax described above for looking up explicitly-defined values (either +names or IP addresses) in a DNS blacklist is a simplification. After the domain +name for the DNS list, what follows the slash can in fact be a list of items. +As with all lists in Exim, the default separator is a colon. However, because +this is a sublist within the list of DNS blacklist domains, it is necessary +either to double the separators like this: + +dnslists = black.list.tld/name.1::name.2 + +or to change the separator character, like this: + +dnslists = black.list.tld/<;name.1;name.2 + +If an item in the list is an IP address, it is inverted before the DNS +blacklist domain is appended. If it is not an IP address, no inversion occurs. +Consider this condition: + +dnslists = black.list.tld/<;192.168.1.2;a.domain + +The DNS lookups that occur are: + +2.1.168.192.black.list.tld +a.domain.black.list.tld + +Once a DNS record has been found (that matches a specific IP return address, if +specified - see section 43.33), no further lookups are done. If there is a +temporary DNS error, the rest of the sublist of domains or IP addresses is +tried. A temporary error for the whole dnslists item occurs only if no other +DNS lookup in this sublist succeeds. In other words, a successful lookup for +any of the items in the sublist overrides a temporary error for a previous +item. + +The ability to supply a list of items after the slash is in some sense just a +syntactic convenience. These two examples have the same effect: + +dnslists = black.list.tld/a.domain : black.list.tld/b.domain +dnslists = black.list.tld/a.domain::b.domain + +However, when the data for the list is obtained from a lookup, the second form +is usually much more convenient. Consider this example: + +deny message = The mail servers for the domain \ + $sender_address_domain \ + are listed at $dnslist_domain ($dnslist_value); \ + see $dnslist_text. + dnslists = sbl.spamhaus.org/<|${lookup dnsdb {>|a=<|\ + ${lookup dnsdb {>|mxh=\ + $sender_address_domain} }} } + +Note the use of ">|" in the dnsdb lookup to specify the separator for multiple +DNS records. The inner dnsdb lookup produces a list of MX hosts and the outer +dnsdb lookup finds the IP addresses for these hosts. The result of expanding +the condition might be something like this: + +dnslists = sbl.spamhaus.org/<|192.168.2.3|192.168.5.6|... + +Thus, this example checks whether or not the IP addresses of the sender +domain's mail servers are on the Spamhaus black list. + +The key that was used for a successful DNS list lookup is put into the variable +$dnslist_matched (see section 43.32). + + +43.31 Data returned by DNS lists +-------------------------------- + +DNS lists are constructed using address records in the DNS. The original RBL +just used the address 127.0.0.1 on the right hand side of each record, but the +RBL+ list and some other lists use a number of values with different meanings. +The values used on the RBL+ list are: + +127.1.0.1 RBL +127.1.0.2 DUL +127.1.0.3 DUL and RBL +127.1.0.4 RSS +127.1.0.5 RSS and RBL +127.1.0.6 RSS and DUL +127.1.0.7 RSS and DUL and RBL + +Section 43.33 below describes how you can distinguish between different values. +Some DNS lists may return more than one address record; see section 43.35 for +details of how they are checked. + + +43.32 Variables set from DNS lists +---------------------------------- + +When an entry is found in a DNS list, the variable $dnslist_domain contains the +name of the overall domain that matched (for example, "spamhaus.example"), +$dnslist_matched contains the key within that domain (for example, +"192.168.5.3"), and $dnslist_value contains the data from the DNS record. When +the key is an IP address, it is not reversed in $dnslist_matched (though it is, +of course, in the actual lookup). In simple cases, for example: + +deny dnslists = spamhaus.example + +the key is also available in another variable (in this case, +$sender_host_address). In more complicated cases, however, this is not true. +For example, using a data lookup (as described in section 43.30) might generate +a dnslists lookup like this: + +deny dnslists = spamhaus.example/<|192.168.1.2|192.168.6.7|... + +If this condition succeeds, the value in $dnslist_matched might be +"192.168.6.7" (for example). + +If more than one address record is returned by the DNS lookup, all the IP +addresses are included in $dnslist_value, separated by commas and spaces. The +variable $dnslist_text contains the contents of any associated TXT record. For +lists such as RBL+ the TXT record for a merged entry is often not very +meaningful. See section 43.36 for a way of obtaining more information. + +You can use the DNS list variables in message or log_message modifiers - +although these appear before the condition in the ACL, they are not expanded +until after it has failed. For example: + +deny hosts = !+local_networks + message = $sender_host_address is listed \ + at $dnslist_domain + dnslists = rbl-plus.mail-abuse.example + + +43.33 Additional matching conditions for DNS lists +-------------------------------------------------- + +You can add an equals sign and an IP address after a dnslists domain name in +order to restrict its action to DNS records with a matching right hand side. +For example, + +deny dnslists = rblplus.mail-abuse.org=127.0.0.2 + +rejects only those hosts that yield 127.0.0.2. Without this additional data, +any address record is considered to be a match. For the moment, we assume that +the DNS lookup returns just one record. Section 43.35 describes how multiple +records are handled. + +More than one IP address may be given for checking, using a comma as a +separator. These are alternatives - if any one of them matches, the dnslists +condition is true. For example: + +deny dnslists = a.b.c=127.0.0.2,127.0.0.3 + +If you want to specify a constraining address list and also specify names or IP +addresses to be looked up, the constraining address list must be specified +first. For example: + +deny dnslists = dsn.rfc-ignorant.org\ + =127.0.0.2/$sender_address_domain + +If the character "&" is used instead of "=", the comparison for each listed IP +address is done by a bitwise "and" instead of by an equality test. In other +words, the listed addresses are used as bit masks. The comparison is true if +all the bits in the mask are present in the address that is being tested. For +example: + +dnslists = a.b.c&0.0.0.3 + +matches if the address is x.x.x.3, x.x.x.7, x.x.x.11, etc. If you want to test +whether one bit or another bit is present (as opposed to both being present), +you must use multiple values. For example: + +dnslists = a.b.c&0.0.0.1,0.0.0.2 + +matches if the final component of the address is an odd number or two times an +odd number. + + +43.34 Negated DNS matching conditions +------------------------------------- + +You can supply a negative list of IP addresses as part of a dnslists condition. +Whereas + +deny dnslists = a.b.c=127.0.0.2,127.0.0.3 + +means "deny if the host is in the black list at the domain a.b.c and the IP +address yielded by the list is either 127.0.0.2 or 127.0.0.3", + +deny dnslists = a.b.c!=127.0.0.2,127.0.0.3 + +means "deny if the host is in the black list at the domain a.b.c and the IP +address yielded by the list is not 127.0.0.2 and not 127.0.0.3". In other +words, the result of the test is inverted if an exclamation mark appears before +the "=" (or the "&") sign. + +Note: This kind of negation is not the same as negation in a domain, host, or +address list (which is why the syntax is different). + +If you are using just one list, the negation syntax does not gain you much. The +previous example is precisely equivalent to + +deny dnslists = a.b.c + !dnslists = a.b.c=127.0.0.2,127.0.0.3 + +However, if you are using multiple lists, the negation syntax is clearer. +Consider this example: + +deny dnslists = sbl.spamhaus.org : \ + list.dsbl.org : \ + dnsbl.njabl.org!=127.0.0.3 : \ + relays.ordb.org + +Using only positive lists, this would have to be: + +deny dnslists = sbl.spamhaus.org : \ + list.dsbl.org +deny dnslists = dnsbl.njabl.org + !dnslists = dnsbl.njabl.org=127.0.0.3 +deny dnslists = relays.ordb.org + +which is less clear, and harder to maintain. + + +43.35 Handling multiple DNS records from a DNS list +--------------------------------------------------- + +A DNS lookup for a dnslists condition may return more than one DNS record, +thereby providing more than one IP address. When an item in a dnslists list is +followed by "=" or "&" and a list of IP addresses, in order to restrict the +match to specific results from the DNS lookup, there are two ways in which the +checking can be handled. For example, consider the condition: + +dnslists = a.b.c=127.0.0.1 + +What happens if the DNS lookup for the incoming IP address yields both +127.0.0.1 and 127.0.0.2 by means of two separate DNS records? Is the condition +true because at least one given value was found, or is it false because at +least one of the found values was not listed? And how does this affect negated +conditions? Both possibilities are provided for with the help of additional +separators "==" and "=&". + + * If "=" or "&" is used, the condition is true if any one of the looked up IP + addresses matches one of the listed addresses. For the example above, the + condition is true because 127.0.0.1 matches. + + * If "==" or "=&" is used, the condition is true only if every one of the + looked up IP addresses matches one of the listed addresses. If the + condition is changed to: + + dnslists = a.b.c==127.0.0.1 + + and the DNS lookup yields both 127.0.0.1 and 127.0.0.2, the condition is + false because 127.0.0.2 is not listed. You would need to have: + + dnslists = a.b.c==127.0.0.1,127.0.0.2 + + for the condition to be true. + +When "!" is used to negate IP address matching, it inverts the result, giving +the precise opposite of the behaviour above. Thus: + + * If "!=" or "!&" is used, the condition is true if none of the looked up IP + addresses matches one of the listed addresses. Consider: + + dnslists = a.b.c!&0.0.0.1 + + If the DNS lookup yields both 127.0.0.1 and 127.0.0.2, the condition is + false because 127.0.0.1 matches. + + * If "!==" or "!=&" is used, the condition is true if there is at least one + looked up IP address that does not match. Consider: + + dnslists = a.b.c!=&0.0.0.1 + + If the DNS lookup yields both 127.0.0.1 and 127.0.0.2, the condition is + true, because 127.0.0.2 does not match. You would need to have: + + dnslists = a.b.c!=&0.0.0.1,0.0.0.2 + + for the condition to be false. + +When the DNS lookup yields only a single IP address, there is no difference +between "=" and "==" and between "&" and "=&". + + +43.36 Detailed information from merged DNS lists +------------------------------------------------ + +When the facility for restricting the matching IP values in a DNS list is used, +the text from the TXT record that is set in $dnslist_text may not reflect the +true reason for rejection. This happens when lists are merged and the IP +address in the A record is used to distinguish them; unfortunately there is +only one TXT record. One way round this is not to use merged lists, but that +can be inefficient because it requires multiple DNS lookups where one would do +in the vast majority of cases when the host of interest is not on any of the +lists. + +A less inefficient way of solving this problem is available. If two domain +names, comma-separated, are given, the second is used first to do an initial +check, making use of any IP value restrictions that are set. If there is a +match, the first domain is used, without any IP value restrictions, to get the +TXT record. As a byproduct of this, there is also a check that the IP being +tested is indeed on the first list. The first domain is the one that is put in +$dnslist_domain. For example: + +deny message = \ + rejected because $sender_host_address is blacklisted \ + at $dnslist_domain\n$dnslist_text + dnslists = \ + sbl.spamhaus.org,sbl-xbl.spamhaus.org=127.0.0.2 : \ + dul.dnsbl.sorbs.net,dnsbl.sorbs.net=127.0.0.10 + +For the first blacklist item, this starts by doing a lookup in +sbl-xbl.spamhaus.org and testing for a 127.0.0.2 return. If there is a match, +it then looks in sbl.spamhaus.org, without checking the return value, and as +long as something is found, it looks for the corresponding TXT record. If there +is no match in sbl-xbl.spamhaus.org, nothing more is done. The second blacklist +item is processed similarly. + +If you are interested in more than one merged list, the same list must be given +several times, but because the results of the DNS lookups are cached, the DNS +calls themselves are not repeated. For example: + +deny dnslists = \ + http.dnsbl.sorbs.net,dnsbl.sorbs.net=127.0.0.2 : \ + socks.dnsbl.sorbs.net,dnsbl.sorbs.net=127.0.0.3 : \ + misc.dnsbl.sorbs.net,dnsbl.sorbs.net=127.0.0.4 : \ + dul.dnsbl.sorbs.net,dnsbl.sorbs.net=127.0.0.10 + +In this case there is one lookup in dnsbl.sorbs.net, and if none of the IP +values matches (or if no record is found), this is the only lookup that is +done. Only if there is a match is one of the more specific lists consulted. + + +43.37 DNS lists and IPv6 +------------------------ + +If Exim is asked to do a dnslist lookup for an IPv6 address, it inverts it +nibble by nibble. For example, if the calling host's IP address is +3ffe:ffff:836f:0a00:000a:0800:200a:c031, Exim might look up + +1.3.0.c.a.0.0.2.0.0.8.0.a.0.0.0.0.0.a.0.f.6.3.8. + f.f.f.f.e.f.f.3.blackholes.mail-abuse.org + +(split over two lines here to fit on the page). Unfortunately, some of the DNS +lists contain wildcard records, intended for IPv4, that interact badly with +IPv6. For example, the DNS entry + +*.3.some.list.example. A 127.0.0.1 + +is probably intended to put the entire 3.0.0.0/8 IPv4 network on the list. +Unfortunately, it also matches the entire 3::/4 IPv6 network. + +You can exclude IPv6 addresses from DNS lookups by making use of a suitable +condition condition, as in this example: + +deny condition = ${if isip4{$sender_host_address}} + dnslists = some.list.example + +If an explicit key is being used for a DNS lookup and it may be an IPv6 address +you should specify alternate list separators for both the outer (DNS list name) +list and inner (lookup keys) list: + + dnslists = <; dnsbl.example.com/<|$acl_m_addrslist + + +43.38 Rate limiting incoming messages +------------------------------------- + +The ratelimit ACL condition can be used to measure and control the rate at +which clients can send email. This is more powerful than the smtp_ratelimit_* +options, because those options control the rate of commands in a single SMTP +session only, whereas the ratelimit condition works across all connections +(concurrent and sequential) from the same client host. The syntax of the +ratelimit condition is: + +ratelimit = <m> / <p> / <options> / <key> + +If the average client sending rate is less than m messages per time period p +then the condition is false; otherwise it is true. + +As a side-effect, the ratelimit condition sets the expansion variable +$sender_rate to the client's computed rate, $sender_rate_limit to the +configured value of m, and $sender_rate_period to the configured value of p. + +The parameter p is the smoothing time constant, in the form of an Exim time +interval, for example, "8h" for eight hours. A larger time constant means that +it takes Exim longer to forget a client's past behaviour. The parameter m is +the maximum number of messages that a client is permitted to send in each time +interval. It also specifies the number of messages permitted in a fast burst. +By increasing both m and p but keeping m/p constant, you can allow a client to +send more messages in a burst without changing its long-term sending rate +limit. Conversely, if m and p are both small, messages must be sent at an even +rate. + +There is a script in util/ratelimit.pl which extracts sending rates from log +files, to assist with choosing appropriate settings for m and p when deploying +the ratelimit ACL condition. The script prints usage instructions when it is +run with no arguments. + +The key is used to look up the data for calculating the client's average +sending rate. This data is stored in Exim's spool directory, alongside the +retry and other hints databases. The default key is $sender_host_address, which +means Exim computes the sending rate of each client host IP address. By +changing the key you can change how Exim identifies clients for the purpose of +ratelimiting. For example, to limit the sending rate of each authenticated +user, independent of the computer they are sending from, set the key to +$authenticated_id. You must ensure that the lookup key is meaningful; for +example, $authenticated_id is only meaningful if the client has authenticated +(which you can check with the authenticated ACL condition). + +The lookup key does not have to identify clients: If you want to limit the rate +at which a recipient receives messages, you can use the key +"$local_part@$domain" with the per_rcpt option (see below) in a RCPT ACL. + +Each ratelimit condition can have up to four options. A per_* option specifies +what Exim measures the rate of, for example, messages or recipients or bytes. +You can adjust the measurement using the unique= and/or count= options. You can +also control when Exim updates the recorded rate using a strict, leaky, or +readonly option. The options are separated by a slash, like the other +parameters. They may appear in any order. + +Internally, Exim appends the smoothing constant p onto the lookup key with any +options that alter the meaning of the stored data. The limit m is not stored, +so you can alter the configured maximum rate and Exim will still remember +clients' past behaviour. If you change the per_* mode or add or remove the +unique= option, the lookup key changes so Exim will forget past behaviour. The +lookup key is not affected by changes to the update mode and the count= option. + + +43.39 Ratelimit options for what is being measured +-------------------------------------------------- + +The per_conn option limits the client's connection rate. It is not normally +used in the acl_not_smtp, acl_not_smtp_mime, or acl_not_smtp_start ACLs. + +The per_mail option limits the client's rate of sending messages. This is the +default if none of the per_* options is specified. It can be used in +acl_smtp_mail, acl_smtp_rcpt, acl_smtp_predata, acl_smtp_mime, acl_smtp_data, +or acl_not_smtp. + +The per_byte option limits the sender's email bandwidth. It can be used in the +same ACLs as the per_mail option, though it is best to use this option in the +acl_smtp_mime, acl_smtp_data or acl_not_smtp ACLs; if it is used in an earlier +ACL, Exim relies on the SIZE parameter given by the client in its MAIL command, +which may be inaccurate or completely missing. You can follow the limit m in +the configuration with K, M, or G to specify limits in kilobytes, megabytes, or +gigabytes, respectively. + +The per_rcpt option causes Exim to limit the rate at which recipients are +accepted. It can be used in the acl_smtp_rcpt, acl_smtp_predata, acl_smtp_mime, +acl_smtp_data, or acl_smtp_rcpt ACLs. In acl_smtp_rcpt the rate is updated one +recipient at a time; in the other ACLs the rate is updated with the total +(accepted) recipient count in one go. Note that in either case the rate +limiting engine will see a message with many recipients as a large high-speed +burst. + +The per_addr option is like the per_rcpt option, except it counts the number of +different recipients that the client has sent messages to in the last time +period. That is, if the client repeatedly sends messages to the same recipient, +its measured rate is not increased. This option can only be used in +acl_smtp_rcpt. + +The per_cmd option causes Exim to recompute the rate every time the condition +is processed. This can be used to limit the rate of any SMTP command. If it is +used in multiple ACLs it can limit the aggregate rate of multiple different +commands. + +The count= option can be used to alter how much Exim adds to the client's +measured rate. For example, the per_byte option is equivalent to "per_mail/ +count=$message_size". If there is no count= option, Exim increases the measured +rate by one (except for the per_rcpt option in ACLs other than acl_smtp_rcpt). +The count does not have to be an integer. + +The unique= option is described in section 43.42 below. + + +43.40 Ratelimit update modes +---------------------------- + +You can specify one of three options with the ratelimit condition to control +when its database is updated. This section describes the readonly mode, and the +next section describes the strict and leaky modes. + +If the ratelimit condition is used in readonly mode, Exim looks up a +previously-computed rate to check against the limit. + +For example, you can test the client's sending rate and deny it access (when it +is too fast) in the connect ACL. If the client passes this check then it can go +on to send a message, in which case its recorded rate will be updated in the +MAIL ACL. Subsequent connections from the same client will check this new rate. + +acl_check_connect: + deny ratelimit = 100 / 5m / readonly + log_message = RATE CHECK: $sender_rate/$sender_rate_period \ + (max $sender_rate_limit) +# ... +acl_check_mail: + warn ratelimit = 100 / 5m / strict + log_message = RATE UPDATE: $sender_rate/$sender_rate_period \ + (max $sender_rate_limit) + +If Exim encounters multiple ratelimit conditions with the same key when +processing a message then it may increase the client's measured rate more than +it should. For example, this will happen if you check the per_rcpt option in +both acl_smtp_rcpt and acl_smtp_data. However it's OK to check the same +ratelimit condition multiple times in the same ACL. You can avoid any multiple +update problems by using the readonly option on later ratelimit checks. + +The per_* options described above do not make sense in some ACLs. If you use a +per_* option in an ACL where it is not normally permitted then the update mode +defaults to readonly and you cannot specify the strict or leaky modes. In other +ACLs the default update mode is leaky (see the next section) so you must +specify the readonly option explicitly. + + +43.41 Ratelimit options for handling fast clients +------------------------------------------------- + +If a client's average rate is greater than the maximum, the rate limiting +engine can react in two possible ways, depending on the presence of the strict +or leaky update modes. This is independent of the other counter-measures (such +as rejecting the message) that may be specified by the rest of the ACL. + +The leaky (default) option means that the client's recorded rate is not updated +if it is above the limit. The effect of this is that Exim measures the client's +average rate of successfully sent email, + +up to the given limit. This is appropriate if the countermeasure when the +condition is true consists of refusing the message, and is generally the better +choice if you have clients that retry automatically. If the action when true is +anything more complex then this option is likely not what is wanted. + +The strict option means that the client's recorded rate is always updated. The +effect of this is that Exim measures the client's average rate of attempts to +send email, which can be much higher than the maximum it is actually allowed. +If the client is over the limit it may be subjected to counter-measures by the +ACL. It must slow down and allow sufficient time to pass that its computed rate +falls below the maximum before it can send email again. The time (the number of +smoothing periods) it must wait and not attempt to send mail can be calculated +with this formula: + + ln(peakrate/maxrate) + + +43.42 Limiting the rate of different events +------------------------------------------- + +The ratelimit unique= option controls a mechanism for counting the rate of +different events. For example, the per_addr option uses this mechanism to count +the number of different recipients that the client has sent messages to in the +last time period; it is equivalent to "per_rcpt/unique=$local_part@$domain". +You could use this feature to measure the rate that a client uses different +sender addresses with the options "per_mail/unique=$sender_address". + +For each ratelimit key Exim stores the set of unique= values that it has seen +for that key. The whole set is thrown away when it is older than the rate +smoothing period p, so each different event is counted at most once per period. +In the leaky update mode, an event that causes the client to go over the limit +is not added to the set, in the same way that the client's recorded rate is not +updated in the same situation. + +When you combine the unique= and readonly options, the specific unique= value +is ignored, and Exim just retrieves the client's stored rate. + +The unique= mechanism needs more space in the ratelimit database than the other +ratelimit options in order to store the event set. The number of unique values +is potentially as large as the rate limit, so the extra space required +increases with larger limits. + +The uniqueification is not perfect: there is a small probability that Exim will +think a new event has happened before. If the sender's rate is less than the +limit, Exim should be more than 99.9% correct. However in strict mode the +measured rate can go above the limit, in which case Exim may under-count events +by a significant margin. Fortunately, if the rate is high enough (2.7 times the +limit) that the false positive rate goes above 9%, then Exim will throw away +the over-full event set before the measured rate falls below the limit. +Therefore the only harm should be that exceptionally high sending rates are +logged incorrectly; any countermeasures you configure will be as effective as +intended. + + +43.43 Using rate limiting +------------------------- + +Exim's other ACL facilities are used to define what counter-measures are taken +when the rate limit is exceeded. This might be anything from logging a warning +(for example, while measuring existing sending rates in order to define +policy), through time delays to slow down fast senders, up to rejecting the +message. For example: + +# Log all senders' rates +warn ratelimit = 0 / 1h / strict + log_message = Sender rate $sender_rate / $sender_rate_period + +# Slow down fast senders; note the need to truncate $sender_rate +# at the decimal point. +warn ratelimit = 100 / 1h / per_rcpt / strict + delay = ${eval: ${sg{$sender_rate}{[.].*}{}} - \ + $sender_rate_limit }s + +# Keep authenticated users under control +deny authenticated = * + ratelimit = 100 / 1d / strict / $authenticated_id + +# System-wide rate limit +defer message = Sorry, too busy. Try again later. + ratelimit = 10 / 1s / $primary_hostname + +# Restrict incoming rate from each host, with a default +# set using a macro and special cases looked up in a table. +defer message = Sender rate exceeds $sender_rate_limit \ + messages per $sender_rate_period + ratelimit = ${lookup {$sender_host_address} \ + cdb {DB/ratelimits.cdb} \ + {$value} {RATELIMIT} } + +Warning: If you have a busy server with a lot of ratelimit tests, especially +with the per_rcpt option, you may suffer from a performance bottleneck caused +by locking on the ratelimit hints database. Apart from making your ACLs less +complicated, you can reduce the problem by using a RAM disk for Exim's hints +directory (usually /var/spool/exim/db/). However this means that Exim will lose +its hints data after a reboot (including retry hints, the callout cache, and +ratelimit data). + + +43.44 Address verification +-------------------------- + +Several of the verify conditions described in section 43.26 cause addresses to +be verified. Section 43.48 discusses the reporting of sender verification +failures. The verification conditions can be followed by options that modify +the verification process. The options are separated from the keyword and from +each other by slashes, and some of them contain parameters. For example: + +verify = sender/callout +verify = recipient/defer_ok/callout=10s,defer_ok + +The first stage of address verification, which always happens, is to run the +address through the routers, in "verify mode". Routers can detect the +difference between verification and routing for delivery, and their actions can +be varied by a number of generic options such as verify and verify_only (see +chapter 15). If routing fails, verification fails. The available options are as +follows: + + * If the callout option is specified, successful routing to one or more + remote hosts is followed by a "callout" to those hosts as an additional + check. Callouts and their sub-options are discussed in the next section. + + * If there is a defer error while doing verification routing, the ACL + normally returns "defer". However, if you include defer_ok in the options, + the condition is forced to be true instead. Note that this is a main + verification option as well as a suboption for callouts. + + * The no_details option is covered in section 43.48, which discusses the + reporting of sender address verification failures. + + * The success_on_redirect option causes verification always to succeed + immediately after a successful redirection. By default, if a redirection + generates just one address, that address is also verified. See further + discussion in section 43.49. + +After an address verification failure, $acl_verify_message contains the error +message that is associated with the failure. It can be preserved by coding like +this: + +warn !verify = sender + set acl_m0 = $acl_verify_message + +If you are writing your own custom rejection message or log message when +denying access, you can use this variable to include information about the +verification failure. + +In addition, $sender_verify_failure or $recipient_verify_failure (as +appropriate) contains one of the following words: + + * qualify: The address was unqualified (no domain), and the message was + neither local nor came from an exempted host. + + * route: Routing failed. + + * mail: Routing succeeded, and a callout was attempted; rejection occurred at + or before the MAIL command (that is, on initial connection, HELO, or MAIL). + + * recipient: The RCPT command in a callout was rejected. + + * postmaster: The postmaster check in a callout was rejected. + +The main use of these variables is expected to be to distinguish between +rejections of MAIL and rejections of RCPT in callouts. + +The above variables may also be set after a successful address verification to: + + * random: A random local-part callout succeeded + + +43.45 Callout verification +-------------------------- + +For non-local addresses, routing verifies the domain, but is unable to do any +checking of the local part. There are situations where some means of verifying +the local part is desirable. One way this can be done is to make an SMTP +callback to a delivery host for the sender address or a callforward to a +subsequent host for a recipient address, to see if the host accepts the +address. We use the term callout to cover both cases. Note that for a sender +address, the callback is not to the client host that is trying to deliver the +message, but to one of the hosts that accepts incoming mail for the sender's +domain. + +Exim does not do callouts by default. If you want them to happen, you must +request them by setting appropriate options on the verify condition, as +described below. This facility should be used with care, because it can add a +lot of resource usage to the cost of verifying an address. However, Exim does +cache the results of callouts, which helps to reduce the cost. Details of +caching are in section 43.47. + +Recipient callouts are usually used only between hosts that are controlled by +the same administration. For example, a corporate gateway host could use +callouts to check for valid recipients on an internal mailserver. A successful +callout does not guarantee that a real delivery to the address would succeed; +on the other hand, a failing callout does guarantee that a delivery would fail. + +If the callout option is present on a condition that verifies an address, a +second stage of verification occurs if the address is successfully routed to +one or more remote hosts. The usual case is routing by a dnslookup or a +manualroute router, where the router specifies the hosts. However, if a router +that does not set up hosts routes to an smtp transport with a hosts setting, +the transport's hosts are used. If an smtp transport has hosts_override set, +its hosts are always used, whether or not the router supplies a host list. +Callouts are only supported on smtp transports. + +The port that is used is taken from the transport, if it is specified and is a +remote transport. (For routers that do verification only, no transport need be +specified.) Otherwise, the default SMTP port is used. If a remote transport +specifies an outgoing interface, this is used; otherwise the interface is not +specified. Likewise, the text that is used for the HELO command is taken from +the transport's helo_data option; if there is no transport, the value of +$smtp_active_hostname is used. + +For a sender callout check, Exim makes SMTP connections to the remote hosts, to +test whether a bounce message could be delivered to the sender address. The +following SMTP commands are sent: + +HELO <local host name> +MAIL FROM:<> +RCPT TO:<the address to be tested> +QUIT + +LHLO is used instead of HELO if the transport's protocol option is set to +"lmtp". + +The callout may use EHLO, AUTH and/or STARTTLS given appropriate option +settings. + +A recipient callout check is similar. By default, it also uses an empty address +for the sender. This default is chosen because most hosts do not make use of +the sender address when verifying a recipient. Using the same address means +that a single cache entry can be used for each recipient. Some sites, however, +do make use of the sender address when verifying. These are catered for by the +use_sender and use_postmaster options, described in the next section. + +If the response to the RCPT command is a 2xx code, the verification succeeds. +If it is 5xx, the verification fails. For any other condition, Exim tries the +next host, if any. If there is a problem with all the remote hosts, the ACL +yields "defer", unless the defer_ok parameter of the callout option is given, +in which case the condition is forced to succeed. + +A callout may take a little time. For this reason, Exim normally flushes SMTP +output before performing a callout in an ACL, to avoid unexpected timeouts in +clients when the SMTP PIPELINING extension is in use. The flushing can be +disabled by using a control modifier to set no_callout_flush. + + +43.46 Additional parameters for callouts +---------------------------------------- + +The callout option can be followed by an equals sign and a number of optional +parameters, separated by commas. For example: + +verify = recipient/callout=10s,defer_ok + +The old syntax, which had callout_defer_ok and check_postmaster as separate +verify options, is retained for backwards compatibility, but is now deprecated. +The additional parameters for callout are as follows: + +<a time interval> + + This specifies the timeout that applies for the callout attempt to each + host. For example: + + verify = sender/callout=5s + + The default is 30 seconds. The timeout is used for each response from the + remote host. It is also used for the initial connection, unless overridden + by the connect parameter. + +connect = <time interval> + + This parameter makes it possible to set a different (usually smaller) + timeout for making the SMTP connection. For example: + + verify = sender/callout=5s,connect=1s + + If not specified, this timeout defaults to the general timeout value. + +defer_ok + + When this parameter is present, failure to contact any host, or any other + kind of temporary error, is treated as success by the ACL. However, the + cache is not updated in this circumstance. + +fullpostmaster + + This operates like the postmaster option (see below), but if the check for + postmaster@domain fails, it tries just postmaster, without a domain, in + accordance with the specification in RFC 2821. The RFC states that the + unqualified address postmaster should be accepted. + +mailfrom = <email address> + + When verifying addresses in header lines using the header_sender + verification option, Exim behaves by default as if the addresses are + envelope sender addresses from a message. Callout verification therefore + tests to see whether a bounce message could be delivered, by using an empty + address in the MAIL command. However, it is arguable that these addresses + might never be used as envelope senders, and could therefore justifiably + reject bounce messages (empty senders). The mailfrom callout parameter + allows you to specify what address to use in the MAIL command. For example: + + require verify = header_sender/callout=mailfrom=abcd@x.y.z + + This parameter is available only for the header_sender verification option. + +maxwait = <time interval> + + This parameter sets an overall timeout for performing a callout + verification. For example: + + verify = sender/callout=5s,maxwait=30s + + This timeout defaults to four times the callout timeout for individual SMTP + commands. The overall timeout applies when there is more than one host that + can be tried. The timeout is checked before trying the next host. This + prevents very long delays if there are a large number of hosts and all are + timing out (for example, when network connections are timing out). + +no_cache + + When this parameter is given, the callout cache is neither read nor + updated. + +postmaster + + When this parameter is set, a successful callout check is followed by a + similar check for the local part postmaster at the same domain. If this + address is rejected, the callout fails (but see fullpostmaster above). The + result of the postmaster check is recorded in a cache record; if it is a + failure, this is used to fail subsequent callouts for the domain without a + connection being made, until the cache record expires. + +postmaster_mailfrom = <email address> + + The postmaster check uses an empty sender in the MAIL command by default. + You can use this parameter to do a postmaster check using a different + address. For example: + + require verify = sender/callout=postmaster_mailfrom=abc@x.y.z + + If both postmaster and postmaster_mailfrom are present, the rightmost one + overrides. The postmaster parameter is equivalent to this example: + + require verify = sender/callout=postmaster_mailfrom= + + Warning: The caching arrangements for postmaster checking do not take + account of the sender address. It is assumed that either the empty address + or a fixed non-empty address will be used. All that Exim remembers is that + the postmaster check for the domain succeeded or failed. + +random + + When this parameter is set, before doing the normal callout check, Exim + does a check for a "random" local part at the same domain. The local part + is not really random - it is defined by the expansion of the option + callout_random_local_part, which defaults to + + $primary_hostname-$tod_epoch-testing + + The idea here is to try to determine whether the remote host accepts all + local parts without checking. If it does, there is no point in doing + callouts for specific local parts. If the "random" check succeeds, the + result is saved in a cache record, and used to force the current and + subsequent callout checks to succeed without a connection being made, until + the cache record expires. + +use_postmaster + + This parameter applies to recipient callouts only. For example: + + deny !verify = recipient/callout=use_postmaster + + It causes a non-empty postmaster address to be used in the MAIL command + when performing the callout for the recipient, and also for a "random" + check if that is configured. The local part of the address is "postmaster" + and the domain is the contents of $qualify_domain. + +use_sender + + This option applies to recipient callouts only. For example: + + require verify = recipient/callout=use_sender + + It causes the message's actual sender address to be used in the MAIL + command when performing the callout, instead of an empty address. There is + no need to use this option unless you know that the called hosts make use + of the sender when checking recipients. If used indiscriminately, it + reduces the usefulness of callout caching. + +hold + + This option applies to recipient callouts only. For example: + + require verify = recipient/callout=use_sender,hold + + It causes the connection to be held open and used for any further + recipients and for eventual delivery (should that be done quickly). Doing + this saves on TCP and SMTP startup costs, and TLS costs also when that is + used for the connections. The advantage is only gained if there are no + callout cache hits (which could be enforced by the no_cache option), if the + use_sender option is used, if neither the random nor the use_postmaster + option is used, and if no other callouts intervene. + +If you use any of the parameters that set a non-empty sender for the MAIL +command (mailfrom, postmaster_mailfrom, use_postmaster, or use_sender), you +should think about possible loops. Recipient checking is usually done between +two hosts that are under the same management, and the host that receives the +callouts is not normally configured to do callouts itself. Therefore, it is +normally safe to use use_postmaster or use_sender in these circumstances. + +However, if you use a non-empty sender address for a callout to an arbitrary +host, there is the likelihood that the remote host will itself initiate a +callout check back to your host. As it is checking what appears to be a message +sender, it is likely to use an empty address in MAIL, thus avoiding a callout +loop. However, to be on the safe side it would be best to set up your own ACLs +so that they do not do sender verification checks when the recipient is the +address you use for header sender or postmaster callout checking. + +Another issue to think about when using non-empty senders for callouts is +caching. When you set mailfrom or use_sender, the cache record is keyed by the +sender/recipient combination; thus, for any given recipient, many more actual +callouts are performed than when an empty sender or postmaster is used. + + +43.47 Callout caching +--------------------- + +Exim caches the results of callouts in order to reduce the amount of resources +used, unless you specify the no_cache parameter with the callout option. A +hints database called "callout" is used for the cache. Two different record +types are used: one records the result of a callout check for a specific +address, and the other records information that applies to the entire domain +(for example, that it accepts the local part postmaster). + +When an original callout fails, a detailed SMTP error message is given about +the failure. However, for subsequent failures use the cache data, this message +is not available. + +The expiry times for negative and positive address cache records are +independent, and can be set by the global options callout_negative_expire +(default 2h) and callout_positive_expire (default 24h), respectively. + +If a host gives a negative response to an SMTP connection, or rejects any +commands up to and including + +MAIL FROM:<> + +(but not including the MAIL command with a non-empty address), any callout +attempt is bound to fail. Exim remembers such failures in a domain cache +record, which it uses to fail callouts for the domain without making new +connections, until the domain record times out. There are two separate expiry +times for domain cache records: callout_domain_negative_expire (default 3h) and +callout_domain_positive_expire (default 7d). + +Domain records expire when the negative expiry time is reached if callouts +cannot be made for the domain, or if the postmaster check failed. Otherwise, +they expire when the positive expiry time is reached. This ensures that, for +example, a host that stops accepting "random" local parts will eventually be +noticed. + +The callout caching mechanism is based on the domain of the address that is +being tested. If the domain routes to several hosts, it is assumed that their +behaviour will be the same. + + +43.48 Sender address verification reporting +------------------------------------------- + +See section 43.44 for a general discussion of verification. When sender +verification fails in an ACL, the details of the failure are given as +additional output lines before the 550 response to the relevant SMTP command +(RCPT or DATA). For example, if sender callout is in use, you might see: + +MAIL FROM:<xyz@abc.example> +250 OK +RCPT TO:<pqr@def.example> +550-Verification failed for <xyz@abc.example> +550-Called: 192.168.34.43 +550-Sent: RCPT TO:<xyz@abc.example> +550-Response: 550 Unknown local part xyz in <xyz@abc.example> +550 Sender verification failed + +If more than one RCPT command fails in the same way, the details are given only +for the first of them. However, some administrators do not want to send out +this much information. You can suppress the details by adding "/no_details" to +the ACL statement that requests sender verification. For example: + +verify = sender/no_details + + +43.49 Redirection while verifying +--------------------------------- + +A dilemma arises when a local address is redirected by aliasing or forwarding +during verification: should the generated addresses themselves be verified, or +should the successful expansion of the original address be enough to verify it? +By default, Exim takes the following pragmatic approach: + + * When an incoming address is redirected to just one child address, + verification continues with the child address, and if that fails to verify, + the original verification also fails. + + * When an incoming address is redirected to more than one child address, + verification does not continue. A success result is returned. + +This seems the most reasonable behaviour for the common use of aliasing as a +way of redirecting different local parts to the same mailbox. It means, for +example, that a pair of alias entries of the form + +A.Wol: aw123 +aw123: :fail: Gone away, no forwarding address + +work as expected, with both local parts causing verification failure. When a +redirection generates more than one address, the behaviour is more like a +mailing list, where the existence of the alias itself is sufficient for +verification to succeed. + +It is possible, however, to change the default behaviour so that all successful +redirections count as successful verifications, however many new addresses are +generated. This is specified by the success_on_redirect verification option. +For example: + +require verify = recipient/success_on_redirect/callout=10s + +In this example, verification succeeds if a router generates a new address, and +the callout does not occur, because no address was routed to a remote host. + +When verification is being tested via the -bv option, the treatment of +redirections is as just described, unless the -v or any debugging option is +also specified. In that case, full verification is done for every generated +address and a report is output for each of them. + + +43.50 Client SMTP authorization (CSA) +------------------------------------- + +Client SMTP Authorization is a system that allows a site to advertise which +machines are and are not permitted to send email. This is done by placing +special SRV records in the DNS; these are looked up using the client's HELO +domain. At the time of writing, CSA is still an Internet Draft. Client SMTP +Authorization checks in Exim are performed by the ACL condition: + +verify = csa + +This fails if the client is not authorized. If there is a DNS problem, or if no +valid CSA SRV record is found, or if the client is authorized, the condition +succeeds. These three cases can be distinguished using the expansion variable +$csa_status, which can take one of the values "fail", "defer", "unknown", or +"ok". The condition does not itself defer because that would be likely to cause +problems for legitimate email. + +The error messages produced by the CSA code include slightly more detail. If +$csa_status is "defer", this may be because of problems looking up the CSA SRV +record, or problems looking up the CSA target address record. There are four +reasons for $csa_status being "fail": + + * The client's host name is explicitly not authorized. + + * The client's IP address does not match any of the CSA target IP addresses. + + * The client's host name is authorized but it has no valid target IP + addresses (for example, the target's addresses are IPv6 and the client is + using IPv4). + + * The client's host name has no CSA SRV record but a parent domain has + asserted that all subdomains must be explicitly authorized. + +The csa verification condition can take an argument which is the domain to use +for the DNS query. The default is: + +verify = csa/$sender_helo_name + +This implementation includes an extension to CSA. If the query domain is an +address literal such as [192.0.2.95], or if it is a bare IP address, Exim +searches for CSA SRV records in the reverse DNS as if the HELO domain was (for +example) 95.2.0.192.in-addr.arpa. Therefore it is meaningful to say: + +verify = csa/$sender_host_address + +In fact, this is the check that Exim performs if the client does not say HELO. +This extension can be turned off by setting the main configuration option +dns_csa_use_reverse to be false. + +If a CSA SRV record is not found for the domain itself, a search is performed +through its parent domains for a record which might be making assertions about +subdomains. The maximum depth of this search is limited using the main +configuration option dns_csa_search_limit, which is 5 by default. Exim does not +look for CSA SRV records in a top level domain, so the default settings handle +HELO domains as long as seven (hostname.five.four.three.two.one.com). This +encompasses the vast majority of legitimate HELO domains. + +The dnsdb lookup also has support for CSA. Although dnsdb also supports direct +SRV lookups, this is not sufficient because of the extra parent domain search +behaviour of CSA, and (as with PTR lookups) dnsdb also turns IP addresses into +lookups in the reverse DNS space. The result of a successful lookup such as: + +${lookup dnsdb {csa=$sender_helo_name}} + +has two space-separated fields: an authorization code and a target host name. +The authorization code can be "Y" for yes, "N" for no, "X" for explicit +authorization required but absent, or "?" for unknown. + + +43.51 Bounce address tag validation +----------------------------------- + +Bounce address tag validation (BATV) is a scheme whereby the envelope senders +of outgoing messages have a cryptographic, timestamped "tag" added to them. +Genuine incoming bounce messages should therefore always be addressed to +recipients that have a valid tag. This scheme is a way of detecting unwanted +bounce messages caused by sender address forgeries (often called "collateral +spam"), because the recipients of such messages do not include valid tags. + +There are two expansion items to help with the implementation of the BATV +"prvs" (private signature) scheme in an Exim configuration. This scheme signs +the original envelope sender address by using a simple key to add a hash of the +address and some time-based randomizing information. The prvs expansion item +creates a signed address, and the prvscheck expansion item checks one. The +syntax of these expansion items is described in section 11.5. The validity +period on signed addresses is seven days. + +As an example, suppose the secret per-address keys are stored in an MySQL +database. A query to look up the key for an address could be defined as a macro +like this: + +PRVSCHECK_SQL = ${lookup mysql{SELECT secret FROM batv_prvs \ + WHERE sender='${quote_mysql:$prvscheck_address}'\ + }{$value}} + +Suppose also that the senders who make use of BATV are defined by an address +list called batv_senders. Then, in the ACL for RCPT commands, you could use +this: + +# Bounces: drop unsigned addresses for BATV senders +deny message = This address does not send an unsigned reverse path + senders = : + recipients = +batv_senders + +# Bounces: In case of prvs-signed address, check signature. +deny message = Invalid reverse path signature. + senders = : + condition = ${prvscheck {$local_part@$domain}\ + {PRVSCHECK_SQL}{1}} + !condition = $prvscheck_result + +The first statement rejects recipients for bounce messages that are addressed +to plain BATV sender addresses, because it is known that BATV senders do not +send out messages with plain sender addresses. The second statement rejects +recipients that are prvs-signed, but with invalid signatures (either because +the key is wrong, or the signature has timed out). + +A non-prvs-signed address is not rejected by the second statement, because the +prvscheck expansion yields an empty string if its first argument is not a +prvs-signed address, thus causing the condition condition to be false. If the +first argument is a syntactically valid prvs-signed address, the yield is the +third string (in this case "1"), whether or not the cryptographic and timeout +checks succeed. The $prvscheck_result variable contains the result of the +checks (empty for failure, "1" for success). + +There is one more issue you must consider when implementing prvs-signing: you +have to ensure that the routers accept prvs-signed addresses and deliver them +correctly. The easiest way to handle this is to use a redirect router to remove +the signature with a configuration along these lines: + +batv_redirect: + driver = redirect + data = ${prvscheck {$local_part@$domain}{PRVSCHECK_SQL}} + +This works because, if the third argument of prvscheck is empty, the result of +the expansion of a prvs-signed address is the decoded value of the original +address. This router should probably be the first of your routers that handles +local addresses. + +To create BATV-signed addresses in the first place, a transport of this form +can be used: + +external_smtp_batv: + driver = smtp + return_path = ${prvs {$return_path} \ + {${lookup mysql{SELECT \ + secret FROM batv_prvs WHERE \ + sender='${quote_mysql:$sender_address}'} \ + {$value}fail}}} + +If no key can be found for the existing return path, no signing takes place. + + +43.52 Using an ACL to control relaying +-------------------------------------- + +An MTA is said to relay a message if it receives it from some host and delivers +it directly to another host as a result of a remote address contained within +it. Redirecting a local address via an alias or forward file and then passing +the message on to another host is not relaying, but a redirection as a result +of the "percent hack" is. + +Two kinds of relaying exist, which are termed "incoming" and "outgoing". A host +which is acting as a gateway or an MX backup is concerned with incoming +relaying from arbitrary hosts to a specific set of domains. On the other hand, +a host which is acting as a smart host for a number of clients is concerned +with outgoing relaying from those clients to the Internet at large. Often the +same host is fulfilling both functions, but in principle these two kinds of +relaying are entirely independent. What is not wanted is the transmission of +mail from arbitrary remote hosts through your system to arbitrary domains. + +You can implement relay control by means of suitable statements in the ACL that +runs for each RCPT command. For convenience, it is often easiest to use Exim's +named list facility to define the domains and hosts involved. For example, +suppose you want to do the following: + + * Deliver a number of domains to mailboxes on the local host (or process them + locally in some other way). Let's say these are my.dom1.example and + my.dom2.example. + + * Relay mail for a number of other domains for which you are the secondary + MX. These might be friend1.example and friend2.example. + + * Relay mail from the hosts on your local LAN, to whatever domains are + involved. Suppose your LAN is 192.168.45.0/24. + +In the main part of the configuration, you put the following definitions: + +domainlist local_domains = my.dom1.example : my.dom2.example +domainlist relay_to_domains = friend1.example : friend2.example +hostlist relay_from_hosts = 192.168.45.0/24 + +Now you can use these definitions in the ACL that is run for every RCPT +command: + +acl_check_rcpt: + accept domains = +local_domains : +relay_to_domains + accept hosts = +relay_from_hosts + +The first statement accepts any RCPT command that contains an address in the +local or relay domains. For any other domain, control passes to the second +statement, which accepts the command only if it comes from one of the relay +hosts. In practice, you will probably want to make your ACL more sophisticated +than this, for example, by including sender and recipient verification. The +default configuration includes a more comprehensive example, which is described +in chapter 7. + + +43.53 Checking a relay configuration +------------------------------------ + +You can check the relay characteristics of your configuration in the same way +that you can test any ACL behaviour for an incoming SMTP connection, by using +the -bh option to run a fake SMTP session with which you interact. + + + +=============================================================================== +44. CONTENT SCANNING AT ACL TIME + +The extension of Exim to include content scanning at ACL time, formerly known +as "exiscan", was originally implemented as a patch by Tom Kistner. The code +was integrated into the main source for Exim release 4.50, and Tom continues to +maintain it. Most of the wording of this chapter is taken from Tom's +specification. + +It is also possible to scan the content of messages at other times. The +local_scan() function (see chapter 45) allows for content scanning after all +the ACLs have run. A transport filter can be used to scan messages at delivery +time (see the transport_filter option, described in chapter 24). + +If you want to include the ACL-time content-scanning features when you compile +Exim, you need to arrange for WITH_CONTENT_SCAN to be defined in your Local/ +Makefile. When you do that, the Exim binary is built with: + + * Two additional ACLs (acl_smtp_mime and acl_not_smtp_mime) that are run for + all MIME parts for SMTP and non-SMTP messages, respectively. + + * Additional ACL conditions and modifiers: decode, malware, mime_regex, regex + , and spam. These can be used in the ACL that is run at the end of message + reception (the acl_smtp_data ACL). + + * An additional control feature ("no_mbox_unspool") that saves spooled copies + of messages, or parts of messages, for debugging purposes. + + * Additional expansion variables that are set in the new ACL and by the new + conditions. + + * Two new main configuration options: av_scanner and spamd_address. + +Content-scanning is continually evolving, and new features are still being +added. While such features are still unstable and liable to incompatible +changes, they are made available in Exim by setting options whose names begin +EXPERIMENTAL_ in Local/Makefile. Such features are not documented in this +manual. You can find out about them by reading the file called doc/ +experimental.txt. + +All the content-scanning facilities work on a MBOX copy of the message that is +temporarily created in a file called: + +<spool_directory>/scan/<message_id>/<message_id>.eml + +The .eml extension is a friendly hint to virus scanners that they can expect an +MBOX-like structure inside that file. The file is created when the first +content scanning facility is called. Subsequent calls to content scanning +conditions open the same file again. The directory is recursively removed when +the acl_smtp_data ACL has finished running, unless + +control = no_mbox_unspool + +has been encountered. When the MIME ACL decodes files, they are put into the +same directory by default. + + +44.1 Scanning for viruses +------------------------- + +The malware ACL condition lets you connect virus scanner software to Exim. It +supports a "generic" interface to scanners called via the shell, and +specialized interfaces for "daemon" type virus scanners, which are resident in +memory and thus are much faster. + +A timeout of 2 minutes is applied to a scanner call (by default); if it expires +then a defer action is taken. + +You can set the av_scanner option in the main part of the configuration to +specify which scanner to use, together with any additional options that are +needed. The basic syntax is as follows: + +av_scanner = <scanner-type>:<option1>:<option2>:[...] + +If you do not set av_scanner, it defaults to + +av_scanner = sophie:/var/run/sophie + +If the value of av_scanner starts with a dollar character, it is expanded +before use. The usual list-parsing of the content (see 6.20) applies. The +following scanner types are supported in this release, though individual ones +can be included or not at build time: + +avast + + This is the scanner daemon of Avast. It has been tested with Avast Core + Security (currently at version 2.2.0). You can get a trial version at + https://www.avast.com or for Linux at https://www.avast.com/ + linux-server-antivirus. This scanner type takes one option, which can be + either a full path to a UNIX socket, or host and port specifiers separated + by white space. The host may be a name or an IP address; the port is either + a single number or a pair of numbers with a dash between. A list of options + may follow. These options are interpreted on the Exim's side of the malware + scanner, or are given on separate lines to the daemon as options before the + main scan command. + + If "pass_unscanned" is set, any files the Avast scanner can't scan (e.g. + decompression bombs, or invalid archives) are considered clean. Use with + care. + + For example: + + av_scanner = avast:/var/run/avast/scan.sock:FLAGS -fullfiles:SENSITIVITY -pup + av_scanner = avast:/var/run/avast/scan.sock:pass_unscanned:FLAGS -fullfiles:SENSITIVITY -pup + av_scanner = avast:192.168.2.22 5036 + + If you omit the argument, the default path /var/run/avast/scan.sock is + used. If you use a remote host, you need to make Exim's spool directory + available to it, as the scanner is passed a file path, not file contents. + For information about available commands and their options you may use + + $ socat UNIX:/var/run/avast/scan.sock STDIO: + FLAGS + SENSITIVITY + PACK + + If the scanner returns a temporary failure (e.g. license issues, or + permission problems), the message is deferred and a paniclog entry is + written. The usual "defer_ok" option is available. + +aveserver + + This is the scanner daemon of Kaspersky Version 5. You can get a trial + version at https://www.kaspersky.com/. This scanner type takes one option, + which is the path to the daemon's UNIX socket. The default is shown in this + example: + + av_scanner = aveserver:/var/run/aveserver + +clamd + + This daemon-type scanner is GPL and free. You can get it at https:// + www.clamav.net/. Some older versions of clamd do not seem to unpack MIME + containers, so it used to be recommended to unpack MIME attachments in the + MIME ACL. This is no longer believed to be necessary. + + The options are a list of server specifiers, which may be a UNIX socket + specification, a TCP socket specification, or a (global) option. + + A socket specification consists of a space-separated list. For a Unix + socket the first element is a full path for the socket, for a TCP socket + the first element is the IP address and the second a port number, Any + further elements are per-server (non-global) options. These per-server + options are supported: + + retry=<timespec> Retry on connect fail + + The "retry" option specifies a time after which a single retry for a failed + connect is made. The default is to not retry. + + If a Unix socket file is specified, only one server is supported. + + Examples: + + av_scanner = clamd:/opt/clamd/socket + av_scanner = clamd:192.0.2.3 1234 + av_scanner = clamd:192.0.2.3 1234:local + av_scanner = clamd:192.0.2.3 1234 retry=10s + av_scanner = clamd:192.0.2.3 1234 : 192.0.2.4 1234 + + If the value of av_scanner points to a UNIX socket file or contains the + "local" option, then the ClamAV interface will pass a filename containing + the data to be scanned, which should normally result in less I/O happening + and be more efficient. Normally in the TCP case, the data is streamed to + ClamAV as Exim does not assume that there is a common filesystem with the + remote host. + + The final example shows that multiple TCP targets can be specified. Exim + will randomly use one for each incoming email (i.e. it load balances them). + Note that only TCP targets may be used if specifying a list of scanners; a + UNIX socket cannot be mixed in with TCP targets. If one of the servers + becomes unavailable, Exim will try the remaining one(s) until it finds one + that works. When a clamd server becomes unreachable, Exim will log a + message. Exim does not keep track of scanner state between multiple + messages, and the scanner selection is random, so the message will get + logged in the mainlog for each email that the down scanner gets chosen + first (message wrapped to be readable): + + 2013-10-09 14:30:39 1VTumd-0000Y8-BQ malware acl condition: + clamd: connection to localhost, port 3310 failed + (Connection refused) + + If the option is unset, the default is /tmp/clamd. Thanks to David Saez for + contributing the code for this scanner. + +cmdline + + This is the keyword for the generic command line scanner interface. It can + be used to attach virus scanners that are invoked from the shell. This + scanner type takes 3 mandatory options: + + 1. The full path and name of the scanner binary, with all command line + options, and a placeholder ("%s") for the directory to scan. + + 2. A regular expression to match against the STDOUT and STDERR output of + the virus scanner. If the expression matches, a virus was found. You + must make absolutely sure that this expression matches on "virus + found". This is called the "trigger" expression. + + 3. Another regular expression, containing exactly one pair of parentheses, + to match the name of the virus found in the scanners output. This is + called the "name" expression. + + For example, Sophos Sweep reports a virus on a line like this: + + Virus 'W32/Magistr-B' found in file ./those.bat + + For the trigger expression, we can match the phrase "found in file". For + the name expression, we want to extract the W32/Magistr-B string, so we can + match for the single quotes left and right of it. Altogether, this makes + the configuration setting: + + av_scanner = cmdline:\ + /path/to/sweep -ss -all -rec -archive %s:\ + found in file:'(.+)' + +drweb + + The DrWeb daemon scanner (https://www.sald.ru/) interface takes one option, + either a full path to a UNIX socket, or host and port specifiers separated + by white space. The host may be a name or an IP address; the port is either + a single number or a pair of numbers with a dash between. For example: + + av_scanner = drweb:/var/run/drwebd.sock + av_scanner = drweb:192.168.2.20 31337 + + If you omit the argument, the default path /usr/local/drweb/run/drwebd.sock + is used. Thanks to Alex Miller for contributing the code for this scanner. + +f-protd + + The f-protd scanner is accessed via HTTP over TCP. One argument is taken, + being a space-separated hostname and port number (or port-range). For + example: + + av_scanner = f-protd:localhost 10200-10204 + + If you omit the argument, the default values shown above are used. + +f-prot6d + + The f-prot6d scanner is accessed using the FPSCAND protocol over TCP. One + argument is taken, being a space-separated hostname and port number. For + example: + + av_scanner = f-prot6d:localhost 10200 + + If you omit the argument, the default values show above are used. + +fsecure + + The F-Secure daemon scanner (https://www.f-secure.com/) takes one argument + which is the path to a UNIX socket. For example: + + av_scanner = fsecure:/path/to/.fsav + + If no argument is given, the default is /var/run/.fsav. Thanks to Johan + Thelmen for contributing the code for this scanner. + +kavdaemon + + This is the scanner daemon of Kaspersky Version 4. This version of the + Kaspersky scanner is outdated. Please upgrade (see aveserver above). This + scanner type takes one option, which is the path to the daemon's UNIX + socket. For example: + + av_scanner = kavdaemon:/opt/AVP/AvpCtl + + The default path is /var/run/AvpCtl. + +mksd + + This was a daemon type scanner that is aimed mainly at Polish users, though + some documentation was available in English. The history can be shown at + https://en.wikipedia.org/wiki/Mks_vir and this appears to be a candidate + for removal from Exim, unless we are informed of other virus scanners which + use the same protocol to integrate. The only option for this scanner type + is the maximum number of processes used simultaneously to scan the + attachments, provided that mksd has been run with at least the same number + of child processes. For example: + + av_scanner = mksd:2 + + You can safely omit this option (the default value is 1). + +sock + + This is a general-purpose way of talking to simple scanner daemons running + on the local machine. There are four options: an address (which may be an + IP address and port, or the path of a Unix socket), a commandline to send + (may include a single %s which will be replaced with the path to the mail + file to be scanned), an RE to trigger on from the returned data, and an RE + to extract malware_name from the returned data. For example: + + av_scanner = sock:127.0.0.1 6001:%s:(SPAM|VIRUS):(.*)$ + + Note that surrounding whitespace is stripped from each option, meaning + there is no way to specify a trailing newline. The socket specifier and + both regular-expressions are required. Default for the commandline is %s\n + (note this does have a trailing newline); specify an empty element to get + this. + +sophie + + Sophie is a daemon that uses Sophos' libsavi library to scan for viruses. + You can get Sophie at http://sophie.sourceforge.net/. The only option for + this scanner type is the path to the UNIX socket that Sophie uses for + client communication. For example: + + av_scanner = sophie:/tmp/sophie + + The default path is /var/run/sophie, so if you are using this, you can omit + the option. + +When av_scanner is correctly set, you can use the malware condition in the DATA +ACL. Note: You cannot use the malware condition in the MIME ACL. + +The av_scanner option is expanded each time malware is called. This makes it +possible to use different scanners. See further below for an example. The +malware condition caches its results, so when you use it multiple times for the +same message, the actual scanning process is only carried out once. However, +using expandable items in av_scanner disables this caching, in which case each +use of the malware condition causes a new scan of the message. + +The malware condition takes a right-hand argument that is expanded before use +and taken as a list, slash-separated by default. The first element can then be +one of + + * "true", "*", or "1", in which case the message is scanned for viruses. The + condition succeeds if a virus was found, and fail otherwise. This is the + recommended usage. + + * "false" or "0" or an empty string, in which case no scanning is done and + the condition fails immediately. + + * A regular expression, in which case the message is scanned for viruses. The + condition succeeds if a virus is found and its name matches the regular + expression. This allows you to take special actions on certain types of + virus. Note that "/" characters in the RE must be doubled due to the + list-processing, unless the separator is changed (in the usual way 6.21). + +You can append a "defer_ok" element to the malware argument list to accept +messages even if there is a problem with the virus scanner. Otherwise, such a +problem causes the ACL to defer. + +You can append a "tmo=<val>" element to the malware argument list to specify a +non-default timeout. The default is two minutes. For example: + +malware = * / defer_ok / tmo=10s + +A timeout causes the ACL to defer. + +When a connection is made to the scanner the expansion variable +$callout_address is set to record the actual address used. + +When a virus is found, the condition sets up an expansion variable called +$malware_name that contains the name of the virus. You can use it in a message +modifier that specifies the error returned to the sender, and/or in logging +data. + +Beware the interaction of Exim's message_size_limit with any size limits +imposed by your anti-virus scanner. + +Here is a very simple scanning example: + +deny message = This message contains malware ($malware_name) + malware = * + +The next example accepts messages when there is a problem with the scanner: + +deny message = This message contains malware ($malware_name) + malware = */defer_ok + +The next example shows how to use an ACL variable to scan with both sophie and +aveserver. It assumes you have set: + +av_scanner = $acl_m0 + +in the main Exim configuration. + +deny message = This message contains malware ($malware_name) + set acl_m0 = sophie + malware = * + +deny message = This message contains malware ($malware_name) + set acl_m0 = aveserver + malware = * + + +44.2 Scanning with SpamAssassin and Rspamd +------------------------------------------ + +The spam ACL condition calls SpamAssassin's spamd daemon to get a spam score +and a report for the message. Support is also provided for Rspamd. + +For more information about installation and configuration of SpamAssassin or +Rspamd refer to their respective websites at https://spamassassin.apache.org/ +and https://www.rspamd.com/ + +SpamAssassin can be installed with CPAN by running: + +perl -MCPAN -e 'install Mail::SpamAssassin' + +SpamAssassin has its own set of configuration files. Please review its +documentation to see how you can tweak it. The default installation should work +nicely, however. + +By default, SpamAssassin listens on 127.0.0.1, TCP port 783 and if you intend +to use an instance running on the local host you do not need to set +spamd_address. If you intend to use another host or port for SpamAssassin, you +must set the spamd_address option in the global part of the Exim configuration +as follows (example): + +spamd_address = 192.168.99.45 783 + +The SpamAssassin protocol relies on a TCP half-close from the client. If your +SpamAssassin client side is running a Linux system with an iptables firewall, +consider setting net.netfilter.nf_conntrack_tcp_timeout_close_wait to at least +the timeout, Exim uses when waiting for a response from the SpamAssassin server +(currently defaulting to 120s). With a lower value the Linux connection +tracking may consider your half-closed connection as dead too soon. + +To use Rspamd (which by default listens on all local addresses on TCP port +11333) you should add variant=rspamd after the address/port pair, for example: + +spamd_address = 127.0.0.1 11333 variant=rspamd + +As of version 2.60, SpamAssassin also supports communication over UNIX sockets. +If you want to us these, supply spamd_address with an absolute filename instead +of an address/port pair: + +spamd_address = /var/run/spamd_socket + +You can have multiple spamd servers to improve scalability. These can reside on +other hardware reachable over the network. To specify multiple spamd servers, +put multiple address/port pairs in the spamd_address option, separated with +colons (the separator can be changed in the usual way 6.21): + +spamd_address = 192.168.2.10 783 : \ + 192.168.2.11 783 : \ + 192.168.2.12 783 + +Up to 32 spamd servers are supported. When a server fails to respond to the +connection attempt, all other servers are tried until one succeeds. If no +server responds, the spam condition defers. + +Unix and TCP socket specifications may be mixed in any order. Each element of +the list is a list itself, space-separated by default and changeable in the +usual way (6.21); take care to not double the separator. + +For TCP socket specifications a host name or IP (v4 or v6, but subject to +list-separator quoting rules) address can be used, and the port can be one or a +dash-separated pair. In the latter case, the range is tried in strict order. + +Elements after the first for Unix sockets, or second for TCP socket, are +options. The supported options are: + +pri=<priority> Selection priority +weight=<value> Selection bias +time=<start>-<end> Use only between these times of day +retry=<timespec> Retry on connect fail +tmo=<timespec> Connection time limit +variant=rspamd Use Rspamd rather than SpamAssassin protocol + +The "pri" option specifies a priority for the server within the list, higher +values being tried first. The default priority is 1. + +The "weight" option specifies a selection bias. Within a priority set servers +are queried in a random fashion, weighted by this value. The default value for +selection bias is 1. + +Time specifications for the "time" option are <hour>.<minute>.<second> in the +local time zone; each element being one or more digits. Either the seconds or +both minutes and seconds, plus the leading "." characters, may be omitted and +will be taken as zero. + +Timeout specifications for the "retry" and "tmo" options are the usual Exim +time interval standard, e.g. "20s" or "1m". + +The "tmo" option specifies an overall timeout for communication. The default +value is two minutes. + +The "retry" option specifies a time after which a single retry for a failed +connect is made. The default is to not retry. + +The spamd_address variable is expanded before use if it starts with a dollar +sign. In this case, the expansion may return a string that is used as the list +so that multiple spamd servers can be the result of an expansion. + +When a connection is made to the server the expansion variable $callout_address +is set to record the actual address used. + + +44.3 Calling SpamAssassin from an Exim ACL +------------------------------------------ + +Here is a simple example of the use of the spam condition in a DATA ACL: + +deny message = This message was classified as SPAM + spam = joe + +The right-hand side of the spam condition specifies a name. This is relevant if +you have set up multiple SpamAssassin profiles. If you do not want to scan +using a specific profile, but rather use the SpamAssassin system-wide default +profile, you can scan for an unknown name, or simply use "nobody". Rspamd does +not use this setting. However, you must put something on the right-hand side. + +The name allows you to use per-domain or per-user antispam profiles in +principle, but this is not straightforward in practice, because a message may +have multiple recipients, not necessarily all in the same domain. Because the +spam condition has to be called from a DATA-time ACL in order to be able to +read the contents of the message, the variables $local_part and $domain are not +set. Careful enforcement of single-recipient messages (e.g. by responding with +defer in the recipient ACL for all recipients after the first), or the use of +PRDR, are needed to use this feature. + +The right-hand side of the spam condition is expanded before being used, so you +can put lookups or conditions there. When the right-hand side evaluates to "0" +or "false", no scanning is done and the condition fails immediately. + +Scanning with SpamAssassin uses a lot of resources. If you scan every message, +large ones may cause significant performance degradation. As most spam messages +are quite small, it is recommended that you do not scan the big ones. For +example: + +deny message = This message was classified as SPAM + condition = ${if < {$message_size}{10K}} + spam = nobody + +The spam condition returns true if the threshold specified in the user's +SpamAssassin profile has been matched or exceeded. If you want to use the spam +condition for its side effects (see the variables below), you can make it +always return "true" by appending ":true" to the username. + +When the spam condition is run, it sets up a number of expansion variables. +Except for $spam_report, these variables are saved with the received message so +are available for use at delivery time. + +$spam_score + + The spam score of the message, for example, "3.4" or "30.5". This is useful + for inclusion in log or reject messages. + +$spam_score_int + + The spam score of the message, multiplied by ten, as an integer value. For + example "34" or "305". It may appear to disagree with $spam_score because + $spam_score is rounded and $spam_score_int is truncated. The integer value + is useful for numeric comparisons in conditions. + +$spam_bar + + A string consisting of a number of "+" or "-" characters, representing the + integer part of the spam score value. A spam score of 4.4 would have a + $spam_bar value of "++++". This is useful for inclusion in warning headers, + since MUAs can match on such strings. The maximum length of the spam bar is + 50 characters. + +$spam_report + + A multiline text table, containing the full SpamAssassin report for the + message. Useful for inclusion in headers or reject messages. This variable + is only usable in a DATA-time ACL. Beware that SpamAssassin may return + non-ASCII characters, especially when running in country-specific locales, + which are not legal unencoded in headers. + +$spam_action + + For SpamAssassin either 'reject' or 'no action' depending on the spam score + versus threshold. For Rspamd, the recommended action. + +The spam condition caches its results unless expansion in spamd_address was +used. If you call it again with the same user name, it does not scan again, but +rather returns the same values as before. + +The spam condition returns DEFER if there is any error while running the +message through SpamAssassin or if the expansion of spamd_address failed. If +you want to treat DEFER as FAIL (to pass on to the next ACL statement block), +append "/defer_ok" to the right-hand side of the spam condition, like this: + +deny message = This message was classified as SPAM + spam = joe/defer_ok + +This causes messages to be accepted even if there is a problem with spamd. + +Here is a longer, commented example of the use of the spam condition: + +# put headers in all messages (no matter if spam or not) +warn spam = nobody:true + add_header = X-Spam-Score: $spam_score ($spam_bar) + add_header = X-Spam-Report: $spam_report + +# add second subject line with *SPAM* marker when message +# is over threshold +warn spam = nobody + add_header = Subject: *SPAM* $h_Subject: + +# reject spam at high scores (> 12) +deny message = This message scored $spam_score spam points. + spam = nobody:true + condition = ${if >{$spam_score_int}{120}{1}{0}} + + +44.4 Scanning MIME parts +------------------------ + +The acl_smtp_mime global option specifies an ACL that is called once for each +MIME part of an SMTP message, including multipart types, in the sequence of +their position in the message. Similarly, the acl_not_smtp_mime option +specifies an ACL that is used for the MIME parts of non-SMTP messages. These +options may both refer to the same ACL if you want the same processing in both +cases. + +These ACLs are called (possibly many times) just before the acl_smtp_data ACL +in the case of an SMTP message, or just before the acl_not_smtp ACL in the case +of a non-SMTP message. However, a MIME ACL is called only if the message +contains a Content-Type: header line. When a call to a MIME ACL does not yield +"accept", ACL processing is aborted and the appropriate result code is sent to +the client. In the case of an SMTP message, the acl_smtp_data ACL is not called +when this happens. + +You cannot use the malware or spam conditions in a MIME ACL; these can only be +used in the DATA or non-SMTP ACLs. However, you can use the regex condition to +match against the raw MIME part. You can also use the mime_regex condition to +match against the decoded MIME part (see section 44.5). + +At the start of a MIME ACL, a number of variables are set from the header +information for the relevant MIME part. These are described below. The contents +of the MIME part are not by default decoded into a disk file except for MIME +parts whose content-type is "message/rfc822". If you want to decode a MIME part +into a disk file, you can use the decode condition. The general syntax is: + +decode = [/<path>/]<filename> + +The right hand side is expanded before use. After expansion, the value can be: + + 1. "0" or "false", in which case no decoding is done. + + 2. The string "default". In that case, the file is put in the temporary + "default" directory <spool_directory>/scan/<message_id>/ with a sequential + filename consisting of the message id and a sequence number. The full path + and name is available in $mime_decoded_filename after decoding. + + 3. A full path name starting with a slash. If the full name is an existing + directory, it is used as a replacement for the default directory. The + filename is then sequentially assigned. If the path does not exist, it is + used as the full path and filename. + + 4. If the string does not start with a slash, it is used as the filename, and + the default path is then used. + +The decode condition normally succeeds. It is only false for syntax errors or +unusual circumstances such as memory shortages. You can easily decode a file +with its original, proposed filename using + +decode = $mime_filename + +However, you should keep in mind that $mime_filename might contain anything. If +you place files outside of the default path, they are not automatically +unlinked. + +For RFC822 attachments (these are messages attached to messages, with a +content-type of "message/rfc822"), the ACL is called again in the same manner +as for the primary message, only that the $mime_is_rfc822 expansion variable is +set (see below). Attached messages are always decoded to disk before being +checked, and the files are unlinked once the check is done. + +The MIME ACL supports the regex and mime_regex conditions. These can be used to +match regular expressions against raw and decoded MIME parts, respectively. +They are described in section 44.5. + +The following list describes all expansion variables that are available in the +MIME ACL: + +$mime_boundary + + If the current part is a multipart (see $mime_is_multipart) below, it + should have a boundary string, which is stored in this variable. If the + current part has no boundary parameter in the Content-Type: header, this + variable contains the empty string. + +$mime_charset + + This variable contains the character set identifier, if one was found in + the Content-Type: header. Examples for charset identifiers are: + + us-ascii + gb2312 (Chinese) + iso-8859-1 + + Please note that this value is not normalized, so you should do matches + case-insensitively. + +$mime_content_description + + This variable contains the normalized content of the Content-Description: + header. It can contain a human-readable description of the parts content. + Some implementations repeat the filename for attachments here, but they are + usually only used for display purposes. + +$mime_content_disposition + + This variable contains the normalized content of the Content-Disposition: + header. You can expect strings like "attachment" or "inline" here. + +$mime_content_id + + This variable contains the normalized content of the Content-ID: header. + This is a unique ID that can be used to reference a part from another part. + +$mime_content_size + + This variable is set only after the decode modifier (see above) has been + successfully run. It contains the size of the decoded part in kilobytes. + The size is always rounded up to full kilobytes, so only a completely empty + part has a $mime_content_size of zero. + +$mime_content_transfer_encoding + + This variable contains the normalized content of the + Content-transfer-encoding: header. This is a symbolic name for an encoding + type. Typical values are "base64" and "quoted-printable". + +$mime_content_type + + If the MIME part has a Content-Type: header, this variable contains its + value, lowercased, and without any options (like "name" or "charset"). Here + are some examples of popular MIME types, as they may appear in this + variable: + + text/plain + text/html + application/octet-stream + image/jpeg + audio/midi + + If the MIME part has no Content-Type: header, this variable contains the + empty string. + +$mime_decoded_filename + + This variable is set only after the decode modifier (see above) has been + successfully run. It contains the full path and filename of the file + containing the decoded data. + +$mime_filename + + This is perhaps the most important of the MIME variables. It contains a + proposed filename for an attachment, if one was found in either the + Content-Type: or Content-Disposition: headers. The filename will be RFC2047 + or RFC2231 decoded, but no additional sanity checks are done. If no + filename was found, this variable contains the empty string. + +$mime_is_coverletter + + This variable attempts to differentiate the "cover letter" of an e-mail + from attached data. It can be used to clamp down on flashy or unnecessarily + encoded content in the cover letter, while not restricting attachments at + all. + + The variable contains 1 (true) for a MIME part believed to be part of the + cover letter, and 0 (false) for an attachment. At present, the algorithm is + as follows: + + 1. The outermost MIME part of a message is always a cover letter. + + 2. If a multipart/alternative or multipart/related MIME part is a cover + letter, so are all MIME subparts within that multipart. + + 3. If any other multipart is a cover letter, the first subpart is a cover + letter, and the rest are attachments. + + 4. All parts contained within an attachment multipart are attachments. + + As an example, the following will ban "HTML mail" (including that sent with + alternative plain text), while allowing HTML files to be attached. HTML + coverletter mail attached to non-HTML coverletter mail will also be + allowed: + + deny message = HTML mail is not accepted here + !condition = $mime_is_rfc822 + condition = $mime_is_coverletter + condition = ${if eq{$mime_content_type}{text/html}{1}{0}} + +$mime_is_multipart + + This variable has the value 1 (true) when the current part has the main + type "multipart", for example, "multipart/alternative" or "multipart/ + mixed". Since multipart entities only serve as containers for other parts, + you may not want to carry out specific actions on them. + +$mime_is_rfc822 + + This variable has the value 1 (true) if the current part is not a part of + the checked message itself, but part of an attached message. Attached + message decoding is fully recursive. + +$mime_part_count + + This variable is a counter that is raised for each processed MIME part. It + starts at zero for the very first part (which is usually a multipart). The + counter is per-message, so it is reset when processing RFC822 attachments + (see $mime_is_rfc822). The counter stays set after acl_smtp_mime is + complete, so you can use it in the DATA ACL to determine the number of MIME + parts of a message. For non-MIME messages, this variable contains the value + -1. + + +44.5 Scanning with regular expressions +-------------------------------------- + +You can specify your own custom regular expression matches on the full body of +the message, or on individual MIME parts. + +The regex condition takes one or more regular expressions as arguments and +matches them against the full message (when called in the DATA ACL) or a raw +MIME part (when called in the MIME ACL). The regex condition matches linewise, +with a maximum line length of 32K characters. That means you cannot have +multiline matches with the regex condition. + +The mime_regex condition can be called only in the MIME ACL. It matches up to +32K of decoded content (the whole content at once, not linewise). If the part +has not been decoded with the decode modifier earlier in the ACL, it is decoded +automatically when mime_regex is executed (using default path and filename +values). If the decoded data is larger than 32K, only the first 32K characters +are checked. + +The regular expressions are passed as a colon-separated list. To include a +literal colon, you must double it. Since the whole right-hand side string is +expanded before being used, you must also escape dollar signs and backslashes +with more backslashes, or use the "\N" facility to disable expansion. Here is a +simple example that contains two regular expressions: + +deny message = contains blacklisted regex ($regex_match_string) + regex = [Mm]ortgage : URGENT BUSINESS PROPOSAL + +The conditions returns true if any one of the regular expressions matches. The +$regex_match_string expansion variable is then set up and contains the matching +regular expression. The expansion variables $regex1 $regex2 etc are set to any +substrings captured by the regular expression. + +Warning: With large messages, these conditions can be fairly CPU-intensive. + + + +=============================================================================== +45. ADDING A LOCAL SCAN FUNCTION TO EXIM + +In these days of email worms, viruses, and ever-increasing spam, some sites +want to apply a lot of checking to messages before accepting them. + +The content scanning extension (chapter 44) has facilities for passing messages +to external virus and spam scanning software. You can also do a certain amount +in Exim itself through string expansions and the condition condition in the ACL +that runs after the SMTP DATA command or the ACL for non-SMTP messages (see +chapter 43), but this has its limitations. + +To allow for further customization to a site's own requirements, there is the +possibility of linking Exim with a private message scanning function, written +in C. If you want to run code that is written in something other than C, you +can of course use a little C stub to call it. + +The local scan function is run once for every incoming message, at the point +when Exim is just about to accept the message. It can therefore be used to +control non-SMTP messages from local processes as well as messages arriving via +SMTP. + +Exim applies a timeout to calls of the local scan function, and there is an +option called local_scan_timeout for setting it. The default is 5 minutes. Zero +means "no timeout". Exim also sets up signal handlers for SIGSEGV, SIGILL, +SIGFPE, and SIGBUS before calling the local scan function, so that the most +common types of crash are caught. If the timeout is exceeded or one of those +signals is caught, the incoming message is rejected with a temporary error if +it is an SMTP message. For a non-SMTP message, the message is dropped and Exim +ends with a non-zero code. The incident is logged on the main and reject logs. + + +45.1 Building Exim to use a local scan function +----------------------------------------------- + +To make use of the local scan function feature, you must tell Exim where your +function is before building Exim, by setting + +both HAVE_LOCAL_SCAN and + +LOCAL_SCAN_SOURCE in your Local/Makefile. A recommended place to put it is in +the Local directory, so you might set + +HAVE_LOCAL_SCAN=yes +LOCAL_SCAN_SOURCE=Local/local_scan.c + +for example. The function must be called local_scan(). It is called by Exim +after it has received a message, when the success return code is about to be +sent. This is after all the ACLs have been run. The return code from your +function controls whether the message is actually accepted or not. There is a +commented template function (that just accepts the message) in the file _src/ +local_scan.c_. + +If you want to make use of Exim's runtime configuration file to set options for +your local_scan() function, you must also set + +LOCAL_SCAN_HAS_OPTIONS=yes + +in Local/Makefile (see section 45.3 below). + + +45.2 API for local_scan() +------------------------- + +You must include this line near the start of your code: + +#include "local_scan.h" + +This header file defines a number of variables and other values, and the +prototype for the function itself. Exim is coded to use unsigned char values +almost exclusively, and one of the things this header defines is a shorthand +for "unsigned char" called "uschar". It also contains the following macro +definitions, to simplify casting character strings and pointers to character +strings: + +#define CS (char *) +#define CCS (const char *) +#define CSS (char **) +#define US (unsigned char *) +#define CUS (const unsigned char *) +#define USS (unsigned char **) + +The function prototype for local_scan() is: + +extern int local_scan(int fd, uschar **return_text); + +The arguments are as follows: + + * fd is a file descriptor for the file that contains the body of the message + (the -D file). The file is open for reading and writing, but updating it is + not recommended. Warning: You must not close this file descriptor. + + The descriptor is positioned at character 19 of the file, which is the + first character of the body itself, because the first 19 characters are the + message id followed by "-D" and a newline. If you rewind the file, you + should use the macro SPOOL_DATA_START_OFFSET to reset to the start of the + data, just in case this changes in some future version. + + * return_text is an address which you can use to return a pointer to a text + string at the end of the function. The value it points to on entry is NULL. + +The function must return an int value which is one of the following macros: + +"LOCAL_SCAN_ACCEPT" + + The message is accepted. If you pass back a string of text, it is saved + with the message, and made available in the variable $local_scan_data. No + newlines are permitted (if there are any, they are turned into spaces) and + the maximum length of text is 1000 characters. + +"LOCAL_SCAN_ACCEPT_FREEZE" + + This behaves as LOCAL_SCAN_ACCEPT, except that the accepted message is + queued without immediate delivery, and is frozen. + +"LOCAL_SCAN_ACCEPT_QUEUE" + + This behaves as LOCAL_SCAN_ACCEPT, except that the accepted message is + queued without immediate delivery. + +"LOCAL_SCAN_REJECT" + + The message is rejected; the returned text is used as an error message + which is passed back to the sender and which is also logged. Newlines are + permitted - they cause a multiline response for SMTP rejections, but are + converted to "\n" in log lines. If no message is given, "Administrative + prohibition" is used. + +"LOCAL_SCAN_TEMPREJECT" + + The message is temporarily rejected; the returned text is used as an error + message as for LOCAL_SCAN_REJECT. If no message is given, "Temporary local + problem" is used. + +"LOCAL_SCAN_REJECT_NOLOGHDR" + + This behaves as LOCAL_SCAN_REJECT, except that the header of the rejected + message is not written to the reject log. It has the effect of unsetting + the rejected_header log selector for just this rejection. If + rejected_header is already unset (see the discussion of the log_selection + option in section 52.15), this code is the same as LOCAL_SCAN_REJECT. + +"LOCAL_SCAN_TEMPREJECT_NOLOGHDR" + + This code is a variation of LOCAL_SCAN_TEMPREJECT in the same way that + LOCAL_SCAN_REJECT_NOLOGHDR is a variation of LOCAL_SCAN_REJECT. + +If the message is not being received by interactive SMTP, rejections are +reported by writing to stderr or by sending an email, as configured by the -oe +command line options. + + +45.3 Configuration options for local_scan() +------------------------------------------- + +It is possible to have option settings in the main configuration file that set +values in static variables in the local_scan() module. If you want to do this, +you must have the line + +LOCAL_SCAN_HAS_OPTIONS=yes + +in your Local/Makefile when you build Exim. (This line is in OS/ +Makefile-Default, commented out). Then, in the local_scan() source file, you +must define static variables to hold the option values, and a table to define +them. + +The table must be a vector called local_scan_options, of type "optionlist". +Each entry is a triplet, consisting of a name, an option type, and a pointer to +the variable that holds the value. The entries must appear in alphabetical +order. Following local_scan_options you must also define a variable called +local_scan_options_count that contains the number of entries in the table. Here +is a short example, showing two kinds of option: + +static int my_integer_option = 42; +static uschar *my_string_option = US"a default string"; + +optionlist local_scan_options[] = { + { "my_integer", opt_int, &my_integer_option }, + { "my_string", opt_stringptr, &my_string_option } +}; + +int local_scan_options_count = + sizeof(local_scan_options)/sizeof(optionlist); + +The values of the variables can now be changed from Exim's runtime +configuration file by including a local scan section as in this example: + +begin local_scan +my_integer = 99 +my_string = some string of text... + +The available types of option data are as follows: + +opt_bool + + This specifies a boolean (true/false) option. The address should point to a + variable of type "BOOL", which will be set to TRUE or FALSE, which are + macros that are defined as "1" and "0", respectively. If you want to detect + whether such a variable has been set at all, you can initialize it to + TRUE_UNSET. (BOOL variables are integers underneath, so can hold more than + two values.) + +opt_fixed + + This specifies a fixed point number, such as is used for load averages. The + address should point to a variable of type "int". The value is stored + multiplied by 1000, so, for example, 1.4142 is truncated and stored as + 1414. + +opt_int + + This specifies an integer; the address should point to a variable of type + "int". The value may be specified in any of the integer formats accepted by + Exim. + +opt_mkint + + This is the same as opt_int, except that when such a value is output in a + -bP listing, if it is an exact number of kilobytes or megabytes, it is + printed with the suffix K or M. + +opt_octint + + This also specifies an integer, but the value is always interpreted as an + octal integer, whether or not it starts with the digit zero, and it is + always output in octal. + +opt_stringptr + + This specifies a string value; the address must be a pointer to a variable + that points to a string (for example, of type "uschar *"). + +opt_time + + This specifies a time interval value. The address must point to a variable + of type "int". The value that is placed there is a number of seconds. + +If the -bP command line option is followed by "local_scan", Exim prints out the +values of all the local_scan() options. + + +45.4 Available Exim variables +----------------------------- + +The header local_scan.h gives you access to a number of C variables. These are +the only ones that are guaranteed to be maintained from release to release. +Note, however, that you can obtain the value of any Exim expansion variable, +including $recipients, by calling expand_string(). The exported C variables are +as follows: + +int body_linecount + + This variable contains the number of lines in the message's body. It is not + valid if the spool_files_wireformat option is used. + +int body_zerocount + + This variable contains the number of binary zero bytes in the message's + body. It is not valid if the spool_files_wireformat option is used. + +unsigned int debug_selector + + This variable is set to zero when no debugging is taking place. Otherwise, + it is a bitmap of debugging selectors. Two bits are identified for use in + local_scan(); they are defined as macros: + + + The "D_v" bit is set when -v was present on the command line. This is a + testing option that is not privileged - any caller may set it. All the + other selector bits can be set only by admin users. + + + The "D_local_scan" bit is provided for use by local_scan(); it is set + by the "+local_scan" debug selector. It is not included in the default + set of debugging bits. + + Thus, to write to the debugging output only when "+local_scan" has been + selected, you should use code like this: + + if ((debug_selector & D_local_scan) != 0) + debug_printf("xxx", ...); + +uschar *expand_string_message + + After a failing call to expand_string() (returned value NULL), the variable + expand_string_message contains the error message, zero-terminated. + +header_line *header_list + + A pointer to a chain of header lines. The header_line structure is + discussed below. + +header_line *header_last + + A pointer to the last of the header lines. + +uschar *headers_charset + + The value of the headers_charset configuration option. + +BOOL host_checking + + This variable is TRUE during a host checking session that is initiated by + the -bh command line option. + +uschar *interface_address + + The IP address of the interface that received the message, as a string. + This is NULL for locally submitted messages. + +int interface_port + + The port on which this message was received. When testing with the -bh + command line option, the value of this variable is -1 unless a port has + been specified via the -oMi option. + +uschar *message_id + + This variable contains Exim's message id for the incoming message (the + value of $message_exim_id) as a zero-terminated string. + +uschar *received_protocol + + The name of the protocol by which the message was received. + +int recipients_count + + The number of accepted recipients. + +recipient_item *recipients_list + + The list of accepted recipients, held in a vector of length + recipients_count. The recipient_item structure is discussed below. You can + add additional recipients by calling receive_add_recipient() (see below). + You can delete recipients by removing them from the vector and adjusting + the value in recipients_count. In particular, by setting recipients_count + to zero you remove all recipients. If you then return the value + "LOCAL_SCAN_ACCEPT", the message is accepted, but immediately blackholed. + To replace the recipients, you can set recipients_count to zero and then + call receive_add_recipient() as often as needed. + +uschar *sender_address + + The envelope sender address. For bounce messages this is the empty string. + +uschar *sender_host_address + + The IP address of the sending host, as a string. This is NULL for + locally-submitted messages. + +uschar *sender_host_authenticated + + The name of the authentication mechanism that was used, or NULL if the + message was not received over an authenticated SMTP connection. + +uschar *sender_host_name + + The name of the sending host, if known. + +int sender_host_port + + The port on the sending host. + +BOOL smtp_input + + This variable is TRUE for all SMTP input, including BSMTP. + +BOOL smtp_batched_input + + This variable is TRUE for BSMTP input. + +int store_pool + + The contents of this variable control which pool of memory is used for new + requests. See section 45.8 for details. + + +45.5 Structure of header lines +------------------------------ + +The header_line structure contains the members listed below. You can add +additional header lines by calling the header_add() function (see below). You +can cause header lines to be ignored (deleted) by setting their type to *. + +struct header_line *next + + A pointer to the next header line, or NULL for the last line. + +int type + + A code identifying certain headers that Exim recognizes. The codes are + printing characters, and are documented in chapter 56 of this manual. + Notice in particular that any header line whose type is * is not + transmitted with the message. This flagging is used for header lines that + have been rewritten, or are to be removed (for example, Envelope-sender: + header lines.) Effectively, * means "deleted". + +int slen + + The number of characters in the header line, including the terminating and + any internal newlines. + +uschar *text + + A pointer to the text of the header. It always ends with a newline, + followed by a zero byte. Internal newlines are preserved. + + +45.6 Structure of recipient items +--------------------------------- + +The recipient_item structure contains these members: + +uschar *address + + This is a pointer to the recipient address as it was received. + +int pno + + This is used in later Exim processing when top level addresses are created + by the one_time option. It is not relevant at the time local_scan() is run + and must always contain -1 at this stage. + +uschar *errors_to + + If this value is not NULL, bounce messages caused by failing to deliver to + the recipient are sent to the address it contains. In other words, it + overrides the envelope sender for this one recipient. (Compare the + errors_to generic router option.) If a local_scan() function sets an + errors_to field to an unqualified address, Exim qualifies it using the + domain from qualify_recipient. When local_scan() is called, the errors_to + field is NULL for all recipients. + + +45.7 Available Exim functions +----------------------------- + +The header local_scan.h gives you access to a number of Exim functions. These +are the only ones that are guaranteed to be maintained from release to release: + +pid_t child_open + (uschar **argv, uschar **envp, int newumask, int *infdptr, int *outfdptr, + BOOL make_leader) + + This function creates a child process that runs the command specified by + argv. The environment for the process is specified by envp, which can be + NULL if no environment variables are to be passed. A new umask is supplied + for the process in newumask. + + Pipes to the standard input and output of the new process are set up and + returned to the caller via the infdptr and outfdptr arguments. The standard + error is cloned to the standard output. If there are any file descriptors + "in the way" in the new process, they are closed. If the final argument is + TRUE, the new process is made into a process group leader. + + The function returns the pid of the new process, or -1 if things go wrong. + +int child_close(pid_t pid, int timeout) + + This function waits for a child process to terminate, or for a timeout (in + seconds) to expire. A timeout value of zero means wait as long as it takes. + The return value is as follows: + + + >= 0 + + The process terminated by a normal exit and the value is the process + ending status. + + + < 0 and > -256 + + The process was terminated by a signal and the value is the negation of + the signal number. + + + -256 + + The process timed out. + + + -257 + + The was some other error in wait(); errno is still set. + +pid_t child_open_exim(int *fd) + + This function provide you with a means of submitting a new message to Exim. + (Of course, you can also call /usr/sbin/sendmail yourself if you want, but + this packages it all up for you.) The function creates a pipe, forks a + subprocess that is running + + exim -t -oem -oi -f <> + + and returns to you (via the "int *" argument) a file descriptor for the + pipe that is connected to the standard input. The yield of the function is + the PID of the subprocess. You can then write a message to the file + descriptor, with recipients in To:, Cc:, and/or Bcc: header lines. + + When you have finished, call child_close() to wait for the process to + finish and to collect its ending status. A timeout value of zero is usually + fine in this circumstance. Unless you have made a mistake with the + recipient addresses, you should get a return code of zero. + +pid_t child_open_exim2(int *fd, uschar *sender, uschar *sender_authentication) + + This function is a more sophisticated version of child_open(). The command + that it runs is: + + exim -t -oem -oi -f sender -oMas sender_authentication + + The third argument may be NULL, in which case the -oMas option is omitted. + +void debug_printf(char *, ...) + + This is Exim's debugging function, with arguments as for (printf(). The + output is written to the standard error stream. If no debugging is + selected, calls to debug_printf() have no effect. Normally, you should make + calls conditional on the "local_scan" debug selector by coding like this: + + if ((debug_selector & D_local_scan) != 0) + debug_printf("xxx", ...); + +uschar *expand_string(uschar *string) + + This is an interface to Exim's string expansion code. The return value is + the expanded string, or NULL if there was an expansion failure. The C + variable expand_string_message contains an error message after an expansion + failure. If expansion does not change the string, the return value is the + pointer to the input string. Otherwise, the return value points to a new + block of memory that was obtained by a call to store_get(). See section + 45.8 below for a discussion of memory handling. + +void header_add(int type, char *format, ...) + + This function allows you to an add additional header line at the end of the + existing ones. The first argument is the type, and should normally be a + space character. The second argument is a format string and any number of + substitution arguments as for sprintf(). You may include internal newlines + if you want, and you must ensure that the string ends with a newline. + +void header_add_at_position + (BOOL after, uschar *name, BOOL topnot, int type, char *format, ...) + + This function adds a new header line at a specified point in the header + chain. The header itself is specified as for header_add(). + + If name is NULL, the new header is added at the end of the chain if after + is true, or at the start if after is false. If name is not NULL, the header + lines are searched for the first non-deleted header that matches the name. + If one is found, the new header is added before it if after is false. If + after is true, the new header is added after the found header and any + adjacent subsequent ones with the same name (even if marked "deleted"). If + no matching non-deleted header is found, the topnot option controls where + the header is added. If it is true, addition is at the top; otherwise at + the bottom. Thus, to add a header after all the Received: headers, or at + the top if there are no Received: headers, you could use + + header_add_at_position(TRUE, US"Received", TRUE, + ' ', "X-xxx: ..."); + + Normally, there is always at least one non-deleted Received: header, but + there may not be if received_header_text expands to an empty string. + +void header_remove(int occurrence, uschar *name) + + This function removes header lines. If occurrence is zero or negative, all + occurrences of the header are removed. If occurrence is greater than zero, + that particular instance of the header is removed. If no header(s) can be + found that match the specification, the function does nothing. + +BOOL header_testname(header_line *hdr, uschar *name, int length, BOOL notdel) + + This function tests whether the given header has the given name. It is not + just a string comparison, because white space is permitted between the name + and the colon. If the notdel argument is true, a false return is forced for + all "deleted" headers; otherwise they are not treated specially. For + example: + + if (header_testname(h, US"X-Spam", 6, TRUE)) ... + +uschar *lss_b64encode(uschar *cleartext, int length) + + This function base64-encodes a string, which is passed by address and + length. The text may contain bytes of any value, including zero. The result + is passed back in dynamic memory that is obtained by calling store_get(). + It is zero-terminated. + +int lss_b64decode(uschar *codetext, uschar **cleartext) + + This function decodes a base64-encoded string. Its arguments are a + zero-terminated base64-encoded string and the address of a variable that is + set to point to the result, which is in dynamic memory. The length of the + decoded string is the yield of the function. If the input is invalid base64 + data, the yield is -1. A zero byte is added to the end of the output string + to make it easy to interpret as a C string (assuming it contains no zeros + of its own). The added zero byte is not included in the returned count. + +int lss_match_domain(uschar *domain, uschar *list) + + This function checks for a match in a domain list. Domains are always + matched caselessly. The return value is one of the following: + + OK match succeeded + FAIL match failed + DEFER match deferred + + DEFER is usually caused by some kind of lookup defer, such as the inability + to contact a database. + +int lss_match_local_part(uschar *localpart, uschar *list, BOOL caseless) + + This function checks for a match in a local part list. The third argument + controls case-sensitivity. The return values are as for lss_match_domain(). + +int lss_match_address(uschar *address, uschar *list, BOOL caseless) + + This function checks for a match in an address list. The third argument + controls the case-sensitivity of the local part match. The domain is always + matched caselessly. The return values are as for lss_match_domain(). + +int lss_match_host(uschar *host_name, uschar *host_address, uschar *list) + + This function checks for a match in a host list. The most common usage is + expected to be + + lss_match_host(sender_host_name, sender_host_address, ...) + + An empty address field matches an empty item in the host list. If the host + name is NULL, the name corresponding to $sender_host_address is + automatically looked up if a host name is required to match an item in the + list. The return values are as for lss_match_domain(), but in addition, + lss_match_host() returns ERROR in the case when it had to look up a host + name, but the lookup failed. + +void log_write(unsigned int selector, int which, char *format, ...) + + This function writes to Exim's log files. The first argument should be zero + (it is concerned with log_selector). The second argument can be "LOG_MAIN" + or "LOG_REJECT" or "LOG_PANIC" or the inclusive "or" of any combination of + them. It specifies to which log or logs the message is written. The + remaining arguments are a format and relevant insertion arguments. The + string should not contain any newlines, not even at the end. + +void receive_add_recipient(uschar *address, int pno) + + This function adds an additional recipient to the message. The first + argument is the recipient address. If it is unqualified (has no domain), it + is qualified with the qualify_recipient domain. The second argument must + always be -1. + + This function does not allow you to specify a private errors_to address (as + described with the structure of recipient_item above), because it pre-dates + the addition of that field to the structure. However, it is easy to add + such a value afterwards. For example: + + receive_add_recipient(US"monitor@mydom.example", -1); + recipients_list[recipients_count-1].errors_to = + US"postmaster@mydom.example"; + +BOOL receive_remove_recipient(uschar *recipient) + + This is a convenience function to remove a named recipient from the list of + recipients. It returns true if a recipient was removed, and false if no + matching recipient could be found. The argument must be a complete email + address. + +uschar rfc2047_decode + (uschar *string, BOOL lencheck, uschar *target, int zeroval, int *lenptr, + uschar **error) + + This function decodes strings that are encoded according to RFC 2047. + Typically these are the contents of header lines. First, each "encoded + word" is decoded from the Q or B encoding into a byte-string. Then, if + provided with the name of a charset encoding, and if the iconv() function + is available, an attempt is made to translate the result to the named + character set. If this fails, the binary string is returned with an error + message. + + The first argument is the string to be decoded. If lencheck is TRUE, the + maximum MIME word length is enforced. The third argument is the target + encoding, or NULL if no translation is wanted. + + If a binary zero is encountered in the decoded string, it is replaced by + the contents of the zeroval argument. For use with Exim headers, the value + must not be 0 because header lines are handled as zero-terminated strings. + + The function returns the result of processing the string, zero-terminated; + if lenptr is not NULL, the length of the result is set in the variable to + which it points. When zeroval is 0, lenptr should not be NULL. + + If an error is encountered, the function returns NULL and uses the error + argument to return an error message. The variable pointed to by error is + set to NULL if there is no error; it may be set non-NULL even when the + function returns a non-NULL value if decoding was successful, but there was + a problem with translation. + +int smtp_fflush(void) + + This function is used in conjunction with smtp_printf(), as described + below. + +void smtp_printf(char *, ...) + + The arguments of this function are like printf(); it writes to the SMTP + output stream. You should use this function only when there is an SMTP + output stream, that is, when the incoming message is being received via + interactive SMTP. This is the case when smtp_input is TRUE and + smtp_batched_input is FALSE. If you want to test for an incoming message + from another host (as opposed to a local process that used the -bs command + line option), you can test the value of sender_host_address, which is + non-NULL when a remote host is involved. + + If an SMTP TLS connection is established, smtp_printf() uses the TLS output + function, so it can be used for all forms of SMTP connection. + + Strings that are written by smtp_printf() from within local_scan() must + start with an appropriate response code: 550 if you are going to return + LOCAL_SCAN_REJECT, 451 if you are going to return LOCAL_SCAN_TEMPREJECT, + and 250 otherwise. Because you are writing the initial lines of a + multi-line response, the code must be followed by a hyphen to indicate that + the line is not the final response line. You must also ensure that the + lines you write terminate with CRLF. For example: + + smtp_printf("550-this is some extra info\r\n"); + return LOCAL_SCAN_REJECT; + + Note that you can also create multi-line responses by including newlines in + the data returned via the return_text argument. The added value of using + smtp_printf() is that, for instance, you could introduce delays between + multiple output lines. + + The smtp_printf() function does not return any error indication, because it + does not automatically flush pending output, and therefore does not test + the state of the stream. (In the main code of Exim, flushing and error + detection is done when Exim is ready for the next SMTP input command.) If + you want to flush the output and check for an error (for example, the + dropping of a TCP/IP connection), you can call smtp_fflush(), which has no + arguments. It flushes the output stream, and returns a non-zero value if + there is an error. + +void *store_get(int) + + This function accesses Exim's internal store (memory) manager. It gets a + new chunk of memory whose size is given by the argument. Exim bombs out if + it ever runs out of memory. See the next section for a discussion of memory + handling. + +void *store_get_perm(int) + + This function is like store_get(), but it always gets memory from the + permanent pool. See the next section for a discussion of memory handling. + +uschar *string_copy(uschar *string) + + See below. + +uschar *string_copyn(uschar *string, int length) + + See below. + +uschar *string_sprintf(char *format, ...) + + These three functions create strings using Exim's dynamic memory + facilities. The first makes a copy of an entire string. The second copies + up to a maximum number of characters, indicated by the second argument. The + third uses a format and insertion arguments to create a new string. In each + case, the result is a pointer to a new string in the current memory pool. + See the next section for more discussion. + + +45.8 More about Exim's memory handling +-------------------------------------- + +No function is provided for freeing memory, because that is never needed. The +dynamic memory that Exim uses when receiving a message is automatically +recycled if another message is received by the same process (this applies only +to incoming SMTP connections - other input methods can supply only one message +at a time). After receiving the last message, a reception process terminates. + +Because it is recycled, the normal dynamic memory cannot be used for holding +data that must be preserved over a number of incoming messages on the same SMTP +connection. However, Exim in fact uses two pools of dynamic memory; the second +one is not recycled, and can be used for this purpose. + +If you want to allocate memory that remains available for subsequent messages +in the same SMTP connection, you should set + +store_pool = POOL_PERM + +before calling the function that does the allocation. There is no need to +restore the value if you do not need to; however, if you do want to revert to +the normal pool, you can either restore the previous value of store_pool or set +it explicitly to POOL_MAIN. + +The pool setting applies to all functions that get dynamic memory, including +expand_string(), store_get(), and the string_xxx() functions. There is also a +convenience function called store_get_perm() that gets a block of memory from +the permanent pool while preserving the value of store_pool. + + + +=============================================================================== +46. SYSTEM-WIDE MESSAGE FILTERING + +The previous chapters (on ACLs and the local scan function) describe checks +that can be applied to messages before they are accepted by a host. There is +also a mechanism for checking messages once they have been received, but before +they are delivered. This is called the system filter. + +The system filter operates in a similar manner to users' filter files, but it +is run just once per message (however many recipients the message has). It +should not normally be used as a substitute for routing, because deliver +commands in a system router provide new envelope recipient addresses. The +system filter must be an Exim filter. It cannot be a Sieve filter. + +The system filter is run at the start of a delivery attempt, before any routing +is done. If a message fails to be completely delivered at the first attempt, +the system filter is run again at the start of every retry. If you want your +filter to do something only once per message, you can make use of the +first_delivery condition in an if command in the filter to prevent it happening +on retries. + +Warning: Because the system filter runs just once, variables that are specific +to individual recipient addresses, such as $local_part and $domain, are not +set, and the "personal" condition is not meaningful. If you want to run a +centrally-specified filter for each recipient address independently, you can do +so by setting up a suitable redirect router, as described in section 46.8 +below. + + +46.1 Specifying a system filter +------------------------------- + +The name of the file that contains the system filter must be specified by +setting system_filter. If you want the filter to run under a uid and gid other +than root, you must also set system_filter_user and system_filter_group as +appropriate. For example: + +system_filter = /etc/mail/exim.filter +system_filter_user = exim + +If a system filter generates any deliveries directly to files or pipes (via the +save or pipe commands), transports to handle these deliveries must be specified +by setting system_filter_file_transport and system_filter_pipe_transport, +respectively. Similarly, system_filter_reply_transport must be set to handle +any messages generated by the reply command. + + +46.2 Testing a system filter +---------------------------- + +You can run simple tests of a system filter in the same way as for a user +filter, but you should use -bF rather than -bf, so that features that are +permitted only in system filters are recognized. + +If you want to test the combined effect of a system filter and a user filter, +you can use both -bF and -bf on the same command line. + + +46.3 Contents of a system filter +-------------------------------- + +The language used to specify system filters is the same as for users' filter +files. It is described in the separate end-user document Exim's interface to +mail filtering. However, there are some additional features that are available +only in system filters; these are described in subsequent sections. If they are +encountered in a user's filter file or when testing with -bf, they cause +errors. + +There are two special conditions which, though available in users' filter +files, are designed for use in system filters. The condition first_delivery is +true only for the first attempt at delivering a message, and manually_thawed is +true only if the message has been frozen, and subsequently thawed by an admin +user. An explicit forced delivery counts as a manual thaw, but thawing as a +result of the auto_thaw setting does not. + +Warning: If a system filter uses the first_delivery condition to specify an +"unseen" (non-significant) delivery, and that delivery does not succeed, it +will not be tried again. If you want Exim to retry an unseen delivery until it +succeeds, you should arrange to set it up every time the filter runs. + +When a system filter finishes running, the values of the variables $n0 - $n9 +are copied into $sn0 - $sn9 and are thereby made available to users' filter +files. Thus a system filter can, for example, set up "scores" to which users' +filter files can refer. + + +46.4 Additional variable for system filters +------------------------------------------- + +The expansion variable $recipients, containing a list of all the recipients of +the message (separated by commas and white space), is available in system +filters. It is not available in users' filters for privacy reasons. + + +46.5 Defer, freeze, and fail commands for system filters +-------------------------------------------------------- + +There are three extra commands (defer, freeze and fail) which are always +available in system filters, but are not normally enabled in users' filters. +(See the allow_defer, allow_freeze and allow_fail options for the redirect +router.) These commands can optionally be followed by the word text and a +string containing an error message, for example: + +fail text "this message looks like spam to me" + +The keyword text is optional if the next character is a double quote. + +The defer command defers delivery of the original recipients of the message. +The fail command causes all the original recipients to be failed, and a bounce +message to be created. The freeze command suspends all delivery attempts for +the original recipients. In all cases, any new deliveries that are specified by +the filter are attempted as normal after the filter has run. + +The freeze command is ignored if the message has been manually unfrozen and not +manually frozen since. This means that automatic freezing by a system filter +can be used as a way of checking out suspicious messages. If a message is found +to be all right, manually unfreezing it allows it to be delivered. + +The text given with a fail command is used as part of the bounce message as +well as being written to the log. If the message is quite long, this can fill +up a lot of log space when such failures are common. To reduce the size of the +log message, Exim interprets the text in a special way if it starts with the +two characters "<<" and contains ">>" later. The text between these two strings +is written to the log, and the rest of the text is used in the bounce message. +For example: + +fail "<<filter test 1>>Your message is rejected \ + because it contains attachments that we are \ + not prepared to receive." + +Take great care with the fail command when basing the decision to fail on the +contents of the message, because the bounce message will of course include the +contents of the original message and will therefore trigger the fail command +again (causing a mail loop) unless steps are taken to prevent this. Testing the +error_message condition is one way to prevent this. You could use, for example + +if $message_body contains "this is spam" and not error_message +then fail text "spam is not wanted here" endif + +though of course that might let through unwanted bounce messages. The +alternative is clever checking of the body and/or headers to detect bounces +generated by the filter. + +The interpretation of a system filter file ceases after a defer, freeze, or +fail command is obeyed. However, any deliveries that were set up earlier in the +filter file are honoured, so you can use a sequence such as + +mail ... +freeze + +to send a specified message when the system filter is freezing (or deferring or +failing) a message. The normal deliveries for the message do not, of course, +take place. + + +46.6 Adding and removing headers in a system filter +--------------------------------------------------- + +Two filter commands that are available only in system filters are: + +headers add <string> +headers remove <string> + +The argument for the headers add is a string that is expanded and then added to +the end of the message's headers. It is the responsibility of the filter +maintainer to make sure it conforms to RFC 2822 syntax. Leading white space is +ignored, and if the string is otherwise empty, or if the expansion is forced to +fail, the command has no effect. + +You can use "\n" within the string, followed by white space, to specify +continued header lines. More than one header may be added in one command by +including "\n" within the string without any following white space. For +example: + +headers add "X-header-1: ....\n \ + continuation of X-header-1 ...\n\ + X-header-2: ...." + +Note that the header line continuation white space after the first newline must +be placed before the backslash that continues the input string, because white +space after input continuations is ignored. + +The argument for headers remove is a colon-separated list of header names. This +command applies only to those headers that are stored with the message; those +that are added at delivery time (such as Envelope-To: and Return-Path:) cannot +be removed by this means. If there is more than one header with the same name, +they are all removed. + +The headers command in a system filter makes an immediate change to the set of +header lines that was received with the message (with possible additions from +ACL processing). Subsequent commands in the system filter operate on the +modified set, which also forms the basis for subsequent message delivery. +Unless further modified during routing or transporting, this set of headers is +used for all recipients of the message. + +During routing and transporting, the variables that refer to the contents of +header lines refer only to those lines that are in this set. Thus, header lines +that are added by a system filter are visible to users' filter files and to all +routers and transports. This contrasts with the manipulation of header lines by +routers and transports, which is not immediate, but which instead is saved up +until the message is actually being written (see section 47.17). + +If the message is not delivered at the first attempt, header lines that were +added by the system filter are stored with the message, and so are still +present at the next delivery attempt. Header lines that were removed are still +present, but marked "deleted" so that they are not transported with the +message. For this reason, it is usual to make the headers command conditional +on first_delivery so that the set of header lines is not modified more than +once. + +Because header modification in a system filter acts immediately, you have to +use an indirect approach if you want to modify the contents of a header line. +For example: + +headers add "Old-Subject: $h_subject:" +headers remove "Subject" +headers add "Subject: new subject (was: $h_old-subject:)" +headers remove "Old-Subject" + + +46.7 Setting an errors address in a system filter +------------------------------------------------- + +In a system filter, if a deliver command is followed by + +errors_to <some address> + +in order to change the envelope sender (and hence the error reporting) for that +delivery, any address may be specified. (In a user filter, only the current +user's address can be set.) For example, if some mail is being monitored, you +might use + +unseen deliver monitor@spying.example errors_to root@local.example + +to take a copy which would not be sent back to the normal error reporting +address if its delivery failed. + + +46.8 Per-address filtering +-------------------------- + +In contrast to the system filter, which is run just once per message for each +delivery attempt, it is also possible to set up a system-wide filtering +operation that runs once for each recipient address. In this case, variables +such as $local_part and $domain can be used, and indeed, the choice of filter +file could be made dependent on them. This is an example of a router which +implements such a filter: + +central_filter: + check_local_user + driver = redirect + domains = +local_domains + file = /central/filters/$local_part + no_verify + allow_filter + allow_freeze + +The filter is run in a separate process under its own uid. Therefore, either +check_local_user must be set (as above), in which case the filter is run as the +local user, or the user option must be used to specify which user to use. If +both are set, user overrides. + +Care should be taken to ensure that none of the commands in the filter file +specify a significant delivery if the message is to go on to be delivered to +its intended recipient. The router will not then claim to have dealt with the +address, so it will be passed on to subsequent routers to be delivered in the +normal way. + + + +=============================================================================== +47. MESSAGE PROCESSING + +Exim performs various transformations on the sender and recipient addresses of +all messages that it handles, and also on the messages' header lines. Some of +these are optional and configurable, while others always take place. All of +this processing, except rewriting as a result of routing, and the addition or +removal of header lines while delivering, happens when a message is received, +before it is placed on Exim's queue. + +Some of the automatic processing takes place by default only for +"locally-originated" messages. This adjective is used to describe messages that +are not received over TCP/IP, but instead are passed to an Exim process on its +standard input. This includes the interactive "local SMTP" case that is set up +by the -bs command line option. + +Note: Messages received over TCP/IP on the loopback interface (127.0.0.1 or +::1) are not considered to be locally-originated. Exim does not treat the +loopback interface specially in any way. + +If you want the loopback interface to be treated specially, you must ensure +that there are appropriate entries in your ACLs. + + +47.1 Submission mode for non-local messages +------------------------------------------- + +Processing that happens automatically for locally-originated messages (unless +suppress_local_fixups is set) can also be requested for messages that are +received over TCP/IP. The term "submission mode" is used to describe this +state. Submission mode is set by the modifier + +control = submission + +in a MAIL, RCPT, or pre-data ACL for an incoming message (see sections 43.21 +and 43.22). This makes Exim treat the message as a local submission, and is +normally used when the source of the message is known to be an MUA running on a +client host (as opposed to an MTA). For example, to set submission mode for +messages originating on the IPv4 loopback interface, you could include the +following in the MAIL ACL: + +warn hosts = 127.0.0.1 + control = submission + +There are some options that can be used when setting submission mode. A slash +is used to separate options. For example: + +control = submission/sender_retain + +Specifying sender_retain has the effect of setting local_sender_retain true and +local_from_check false for the current incoming message. The first of these +allows an existing Sender: header in the message to remain, and the second +suppresses the check to ensure that From: matches the authenticated sender. +With this setting, Exim still fixes up messages by adding Date: and Message-ID: +header lines if they are missing, but makes no attempt to check sender +authenticity in header lines. + +When sender_retain is not set, a submission mode setting may specify a domain +to be used when generating a From: or Sender: header line. For example: + +control = submission/domain=some.domain + +The domain may be empty. How this value is used is described in sections 47.11 +and 47.16. There is also a name option that allows you to specify the user's +full name for inclusion in a created Sender: or From: header line. For example: + +accept authenticated = * + control = submission/domain=wonderland.example/\ + name=${lookup {$authenticated_id} \ + lsearch {/etc/exim/namelist}} + +Because the name may contain any characters, including slashes, the name option +must be given last. The remainder of the string is used as the name. For the +example above, if /etc/exim/namelist contains: + +bigegg: Humpty Dumpty + +then when the sender has authenticated as bigegg, the generated Sender: line +would be: + +Sender: Humpty Dumpty <bigegg@wonderland.example> + +By default, submission mode forces the return path to the same address as is +used to create the Sender: header. However, if sender_retain is specified, the +return path is also left unchanged. + +Note: The changes caused by submission mode take effect after the predata ACL. +This means that any sender checks performed before the fix-ups use the +untrusted sender address specified by the user, not the trusted sender address +specified by submission mode. Although this might be slightly unexpected, it +does mean that you can configure ACL checks to spot that a user is trying to +spoof another's address. + + +47.2 Line endings +----------------- + +RFC 2821 specifies that CRLF (two characters: carriage-return, followed by +linefeed) is the line ending for messages transmitted over the Internet using +SMTP over TCP/IP. However, within individual operating systems, different +conventions are used. For example, Unix-like systems use just LF, but others +use CRLF or just CR. + +Exim was designed for Unix-like systems, and internally, it stores messages +using the system's convention of a single LF as a line terminator. When +receiving a message, all line endings are translated to this standard format. +Originally, it was thought that programs that passed messages directly to an +MTA within an operating system would use that system's convention. Experience +has shown that this is not the case; for example, there are Unix applications +that use CRLF in this circumstance. For this reason, and for compatibility with +other MTAs, the way Exim handles line endings for all messages is now as +follows: + + * LF not preceded by CR is treated as a line ending. + + * CR is treated as a line ending; if it is immediately followed by LF, the LF + is ignored. + + * The sequence "CR, dot, CR" does not terminate an incoming SMTP message, nor + a local message in the state where a line containing only a dot is a + terminator. + + * If a bare CR is encountered within a header line, an extra space is added + after the line terminator so as not to end the header line. The reasoning + behind this is that bare CRs in header lines are most likely either to be + mistakes, or people trying to play silly games. + + * If the first header line received in a message ends with CRLF, a subsequent + bare LF in a header line is treated in the same way as a bare CR in a + header line. + + +47.3 Unqualified addresses +-------------------------- + +By default, Exim expects every envelope address it receives from an external +host to be fully qualified. Unqualified addresses cause negative responses to +SMTP commands. However, because SMTP is used as a means of transporting +messages from MUAs running on personal workstations, there is sometimes a +requirement to accept unqualified addresses from specific hosts or IP networks. + +Exim has two options that separately control which hosts may send unqualified +sender or recipient addresses in SMTP commands, namely sender_unqualified_hosts +and recipient_unqualified_hosts. In both cases, if an unqualified address is +accepted, it is qualified by adding the value of qualify_domain or +qualify_recipient, as appropriate. + +Unqualified addresses in header lines are automatically qualified for messages +that are locally originated, unless the -bnq option is given on the command +line. For messages received over SMTP, unqualified addresses in header lines +are qualified only if unqualified addresses are permitted in SMTP commands. In +other words, such qualification is also controlled by sender_unqualified_hosts +and recipient_unqualified_hosts, + + +47.4 The UUCP From line +----------------------- + +Messages that have come from UUCP (and some other applications) often begin +with a line containing the envelope sender and a timestamp, following the word +"From". Examples of two common formats are: + +From a.oakley@berlin.mus Fri Jan 5 12:35 GMT 1996 +From f.butler@berlin.mus Fri, 7 Jan 97 14:00:00 GMT + +This line precedes the RFC 2822 header lines. For compatibility with Sendmail, +Exim recognizes such lines at the start of messages that are submitted to it +via the command line (that is, on the standard input). It does not recognize +such lines in incoming SMTP messages, unless the sending host matches +ignore_fromline_hosts or the -bs option was used for a local message and +ignore_fromline_local is set. The recognition is controlled by a regular +expression that is defined by the uucp_from_pattern option, whose default value +matches the two common cases shown above and puts the address that follows +"From" into $1. + +When the caller of Exim for a non-SMTP message that contains a "From" line is a +trusted user, the message's sender address is constructed by expanding the +contents of uucp_sender_address, whose default value is "$1". This is then +parsed as an RFC 2822 address. If there is no domain, the local part is +qualified with qualify_domain unless it is the empty string. However, if the +command line -f option is used, it overrides the "From" line. + +If the caller of Exim is not trusted, the "From" line is recognized, but the +sender address is not changed. This is also the case for incoming SMTP messages +that are permitted to contain "From" lines. + +Only one "From" line is recognized. If there is more than one, the second is +treated as a data line that starts the body of the message, as it is not valid +as a header line. This also happens if a "From" line is present in an incoming +SMTP message from a source that is not permitted to send them. + + +47.5 Resent- header lines +------------------------- + +RFC 2822 makes provision for sets of header lines starting with the string +"Resent-" to be added to a message when it is resent by the original recipient +to somebody else. These headers are Resent-Date:, Resent-From:, Resent-Sender:, +Resent-To:, Resent-Cc:, Resent-Bcc: and Resent-Message-ID:. The RFC says: + + Resent fields are strictly informational. They MUST NOT be used in the + normal processing of replies or other such automatic actions on messages. + +This leaves things a bit vague as far as other processing actions such as +address rewriting are concerned. Exim treats Resent- header lines as follows: + + * A Resent-From: line that just contains the login id of the submitting user + is automatically rewritten in the same way as From: (see below). + + * If there's a rewriting rule for a particular header line, it is also + applied to Resent- header lines of the same type. For example, a rule that + rewrites From: also rewrites Resent-From:. + + * For local messages, if Sender: is removed on input, Resent-Sender: is also + removed. + + * For a locally-submitted message, if there are any Resent- header lines but + no Resent-Date:, Resent-From:, or Resent-Message-Id:, they are added as + necessary. It is the contents of Resent-Message-Id: (rather than + Message-Id:) which are included in log lines in this case. + + * The logic for adding Sender: is duplicated for Resent-Sender: when any + Resent- header lines are present. + + +47.6 The Auto-Submitted: header line +------------------------------------ + +Whenever Exim generates an autoreply, a bounce, or a delay warning message, it +includes the header line: + +Auto-Submitted: auto-replied + + +47.7 The Bcc: header line +------------------------- + +If Exim is called with the -t option, to take recipient addresses from a +message's header, it removes any Bcc: header line that may exist (after +extracting its addresses). If -t is not present on the command line, any +existing Bcc: is not removed. + + +47.8 The Date: header line +-------------------------- + +If a locally-generated or submission-mode message has no Date: header line, +Exim adds one, using the current date and time, unless the +suppress_local_fixups control has been specified. + + +47.9 The Delivery-date: header line +----------------------------------- + +Delivery-date: header lines are not part of the standard RFC 2822 header set. +Exim can be configured to add them to the final delivery of messages. (See the +generic delivery_date_add transport option.) They should not be present in +messages in transit. If the delivery_date_remove configuration option is set +(the default), Exim removes Delivery-date: header lines from incoming messages. + + +47.10 The Envelope-to: header line +---------------------------------- + +Envelope-to: header lines are not part of the standard RFC 2822 header set. +Exim can be configured to add them to the final delivery of messages. (See the +generic envelope_to_add transport option.) They should not be present in +messages in transit. If the envelope_to_remove configuration option is set (the +default), Exim removes Envelope-to: header lines from incoming messages. + + +47.11 The From: header line +--------------------------- + +If a submission-mode message does not contain a From: header line, Exim adds +one if either of the following conditions is true: + + * The envelope sender address is not empty (that is, this is not a bounce + message). The added header line copies the envelope sender address. + + * The SMTP session is authenticated and $authenticated_id is not empty. + + 1. If no domain is specified by the submission control, the local part is + $authenticated_id and the domain is $qualify_domain. + + 2. If a non-empty domain is specified by the submission control, the local + part is $authenticated_id, and the domain is the specified domain. + + 3. If an empty domain is specified by the submission control, + $authenticated_id is assumed to be the complete address. + +A non-empty envelope sender takes precedence. + +If a locally-generated incoming message does not contain a From: header line, +and the suppress_local_fixups control is not set, Exim adds one containing the +sender's address. The calling user's login name and full name are used to +construct the address, as described in section 47.18. They are obtained from +the password data by calling getpwuid() (but see the unknown_login +configuration option). The address is qualified with qualify_domain. + +For compatibility with Sendmail, if an incoming, non-SMTP message has a From: +header line containing just the unqualified login name of the calling user, +this is replaced by an address containing the user's login name and full name +as described in section 47.18. + + +47.12 The Message-ID: header line +--------------------------------- + +If a locally-generated or submission-mode incoming message does not contain a +Message-ID: or Resent-Message-ID: header line, and the suppress_local_fixups +control is not set, Exim adds a suitable header line to the message. If there +are any Resent-: headers in the message, it creates Resent-Message-ID:. The id +is constructed from Exim's internal message id, preceded by the letter E to +ensure it starts with a letter, and followed by @ and the primary host name. +Additional information can be included in this header line by setting the +message_id_header_text and/or message_id_header_domain options. + + +47.13 The Received: header line +------------------------------- + +A Received: header line is added at the start of every message. The contents +are defined by the received_header_text configuration option, and Exim +automatically adds a semicolon and a timestamp to the configured string. + +The Received: header is generated as soon as the message's header lines have +been received. At this stage, the timestamp in the Received: header line is the +time that the message started to be received. This is the value that is seen by +the DATA ACL and by the local_scan() function. + +Once a message is accepted, the timestamp in the Received: header line is +changed to the time of acceptance, which is (apart from a small delay while the +-H spool file is written) the earliest time at which delivery could start. + + +47.14 The References: header line +--------------------------------- + +Messages created by the autoreply transport include a References: header line. +This is constructed according to the rules that are described in section 3.64 +of RFC 2822 (which states that replies should contain such a header line), and +section 3.14 of RFC 3834 (which states that automatic responses are not +different in this respect). However, because some mail processing software does +not cope well with very long header lines, no more than 12 message IDs are +copied from the References: header line in the incoming message. If there are +more than 12, the first one and then the final 11 are copied, before adding the +message ID of the incoming message. + + +47.15 The Return-path: header line +---------------------------------- + +Return-path: header lines are defined as something an MTA may insert when it +does the final delivery of messages. (See the generic return_path_add transport +option.) Therefore, they should not be present in messages in transit. If the +return_path_remove configuration option is set (the default), Exim removes +Return-path: header lines from incoming messages. + + +47.16 The Sender: header line +----------------------------- + +For a locally-originated message from an untrusted user, Exim may remove an +existing Sender: header line, and it may add a new one. You can modify these +actions by setting the local_sender_retain option true, the local_from_check +option false, or by using the suppress_local_fixups control setting. + +When a local message is received from an untrusted user and local_from_check is +true (the default), and the suppress_local_fixups control has not been set, a +check is made to see if the address given in the From: header line is the +correct (local) sender of the message. The address that is expected has the +login name as the local part and the value of qualify_domain as the domain. +Prefixes and suffixes for the local part can be permitted by setting +local_from_prefix and local_from_suffix appropriately. If From: does not +contain the correct sender, a Sender: line is added to the message. + +If you set local_from_check false, this checking does not occur. However, the +removal of an existing Sender: line still happens, unless you also set +local_sender_retain to be true. It is not possible to set both of these options +true at the same time. + +By default, no processing of Sender: header lines is done for messages received +over TCP/IP or for messages submitted by trusted users. However, when a message +is received over TCP/IP in submission mode, and sender_retain is not specified +on the submission control, the following processing takes place: + +First, any existing Sender: lines are removed. Then, if the SMTP session is +authenticated, and $authenticated_id is not empty, a sender address is created +as follows: + + * If no domain is specified by the submission control, the local part is + $authenticated_id and the domain is $qualify_domain. + + * If a non-empty domain is specified by the submission control, the local + part is $authenticated_id, and the domain is the specified domain. + + * If an empty domain is specified by the submission control, + $authenticated_id is assumed to be the complete address. + +This address is compared with the address in the From: header line. If they are +different, a Sender: header line containing the created address is added. +Prefixes and suffixes for the local part in From: can be permitted by setting +local_from_prefix and local_from_suffix appropriately. + +Note: Whenever a Sender: header line is created, the return path for the +message (the envelope sender address) is changed to be the same address, except +in the case of submission mode when sender_retain is specified. + + +47.17 Adding and removing header lines in routers and transports +---------------------------------------------------------------- + +When a message is delivered, the addition and removal of header lines can be +specified in a system filter, or on any of the routers and transports that +process the message. Section 46.6 contains details about modifying headers in a +system filter. Header lines can also be added in an ACL as a message is +received (see section 43.24). + +In contrast to what happens in a system filter, header modifications that are +specified on routers and transports apply only to the particular recipient +addresses that are being processed by those routers and transports. These +changes do not actually take place until a copy of the message is being +transported. Therefore, they do not affect the basic set of header lines, and +they do not affect the values of the variables that refer to header lines. + +Note: In particular, this means that any expansions in the configuration of the +transport cannot refer to the modified header lines, because such expansions +all occur before the message is actually transported. + +For both routers and transports, the argument of a headers_add option must be +in the form of one or more RFC 2822 header lines, separated by newlines (coded +as "\n"). For example: + +headers_add = X-added-header: added by $primary_hostname\n\ + X-added-second: another added header line + +Exim does not check the syntax of these added header lines. + +Multiple headers_add options for a single router or transport can be specified; +the values will append to a single list of header lines. Each header-line is +separately expanded. + +The argument of a headers_remove option must consist of a colon-separated list +of header names. This is confusing, because header names themselves are often +terminated by colons. In this case, the colons are the list separators, not +part of the names. For example: + +headers_remove = return-receipt-to:acknowledge-to + +Multiple headers_remove options for a single router or transport can be +specified; the arguments will append to a single header-names list. Each item +is separately expanded. Note that colons in complex expansions which are used +to form all or part of a headers_remove list will act as list separators. + +When headers_add or headers_remove is specified on a router, items are expanded +at routing time, and then associated with all addresses that are accepted by +that router, and also with any new addresses that it generates. If an address +passes through several routers as a result of aliasing or forwarding, the +changes are cumulative. + +However, this does not apply to multiple routers that result from the use of +the unseen option. Any header modifications that were specified by the "unseen" +router or its predecessors apply only to the "unseen" delivery. + +Addresses that end up with different headers_add or headers_remove settings +cannot be delivered together in a batch, so a transport is always dealing with +a set of addresses that have the same header-processing requirements. + +The transport starts by writing the original set of header lines that arrived +with the message, possibly modified by the system filter. As it writes out +these lines, it consults the list of header names that were attached to the +recipient address(es) by headers_remove options in routers, and it also +consults the transport's own headers_remove option. Header lines whose names +are on either of these lists are not written out. If there are multiple +instances of any listed header, they are all skipped. + +After the remaining original header lines have been written, new header lines +that were specified by routers' headers_add options are written, in the order +in which they were attached to the address. These are followed by any header +lines specified by the transport's headers_add option. + +This way of handling header line modifications in routers and transports has +the following consequences: + + * The original set of header lines, possibly modified by the system filter, + remains "visible", in the sense that the $header_xxx variables refer to it, + at all times. + + * Header lines that are added by a router's headers_add option are not + accessible by means of the $header_xxx expansion syntax in subsequent + routers or the transport. + + * Conversely, header lines that are specified for removal by headers_remove + in a router remain visible to subsequent routers and the transport. + + * Headers added to an address by headers_add in a router cannot be removed by + a later router or by a transport. + + * An added header can refer to the contents of an original header that is to + be removed, even it has the same name as the added header. For example: + + headers_remove = subject + headers_add = Subject: new subject (was: $h_subject:) + +Warning: The headers_add and headers_remove options cannot be used for a +redirect router that has the one_time option set. + + +47.18 Constructed addresses +--------------------------- + +When Exim constructs a sender address for a locally-generated message, it uses +the form + +<user name> <login@qualify_domain> + +For example: + +Zaphod Beeblebrox <zaphod@end.univ.example> + +The user name is obtained from the -F command line option if set, or otherwise +by looking up the calling user by getpwuid() and extracting the "gecos" field +from the password entry. If the "gecos" field contains an ampersand character, +this is replaced by the login name with the first letter upper cased, as is +conventional in a number of operating systems. See the gecos_name option for a +way to tailor the handling of the "gecos" field. The unknown_username option +can be used to specify user names in cases when there is no password file +entry. + +In all cases, the user name is made to conform to RFC 2822 by quoting all or +parts of it if necessary. In addition, if it contains any non-printing +characters, it is encoded as described in RFC 2047, which defines a way of +including non-ASCII characters in header lines. The value of the +headers_charset option specifies the name of the encoding that is used (the +characters are assumed to be in this encoding). The setting of +print_topbitchars controls whether characters with the top bit set (that is, +with codes greater than 127) count as printing characters or not. + + +47.19 Case of local parts +------------------------- + +RFC 2822 states that the case of letters in the local parts of addresses cannot +be assumed to be non-significant. Exim preserves the case of local parts of +addresses, but by default it uses a lower-cased form when it is routing, +because on most Unix systems, usernames are in lower case and case-insensitive +routing is required. However, any particular router can be made to use the +original case for local parts by setting the caseful_local_part generic router +option. + +If you must have mixed-case user names on your system, the best way to proceed, +assuming you want case-independent handling of incoming email, is to set up +your first router to convert incoming local parts in your domains to the +correct case by means of a file lookup. For example: + +correct_case: + driver = redirect + domains = +local_domains + data = ${lookup{$local_part}cdb\ + {/etc/usercased.cdb}{$value}fail}\ + @$domain + +For this router, the local part is forced to lower case by the default action ( +caseful_local_part is not set). The lower-cased local part is used to look up a +new local part in the correct case. If you then set caseful_local_part on any +subsequent routers which process your domains, they will operate on local parts +with the correct case in a case-sensitive manner. + + +47.20 Dots in local parts +------------------------- + +RFC 2822 forbids empty components in local parts. That is, an unquoted local +part may not begin or end with a dot, nor have two consecutive dots in the +middle. However, it seems that many MTAs do not enforce this, so Exim permits +empty components for compatibility. + + +47.21 Rewriting addresses +------------------------- + +Rewriting of sender and recipient addresses, and addresses in headers, can +happen automatically, or as the result of configuration options, as described +in chapter 31. The headers that may be affected by this are Bcc:, Cc:, From:, +Reply-To:, Sender:, and To:. + +Automatic rewriting includes qualification, as mentioned above. The other case +in which it can happen is when an incomplete non-local domain is given. The +routing process may cause this to be expanded into the full domain name. For +example, a header such as + +To: hare@teaparty + +might get rewritten as + +To: hare@teaparty.wonderland.fict.example + +Rewriting as a result of routing is the one kind of message processing that +does not happen at input time, as it cannot be done until the address has been +routed. + +Strictly, one should not do any deliveries of a message until all its addresses +have been routed, in case any of the headers get changed as a result of +routing. However, doing this in practice would hold up many deliveries for +unreasonable amounts of time, just because one address could not immediately be +routed. Exim therefore does not delay other deliveries when routing of one or +more addresses is deferred. + + + +=============================================================================== +48. SMTP PROCESSING + +Exim supports a number of different ways of using the SMTP protocol, and its +LMTP variant, which is an interactive protocol for transferring messages into a +closed mail store application. This chapter contains details of how SMTP is +processed. For incoming mail, the following are available: + + * SMTP over TCP/IP (Exim daemon or inetd); + + * SMTP over the standard input and output (the -bs option); + + * Batched SMTP on the standard input (the -bS option). + +For mail delivery, the following are available: + + * SMTP over TCP/IP (the smtp transport); + + * LMTP over TCP/IP (the smtp transport with the protocol option set to + "lmtp"); + + * LMTP over a pipe to a process running in the local host (the lmtp + transport); + + * Batched SMTP to a file or pipe (the appendfile and pipe transports with the + use_bsmtp option set). + +Batched SMTP is the name for a process in which batches of messages are stored +in or read from files (or pipes), in a format in which SMTP commands are used +to contain the envelope information. + + +48.1 Outgoing SMTP and LMTP over TCP/IP +--------------------------------------- + +Outgoing SMTP and LMTP over TCP/IP is implemented by the smtp transport. The +protocol option selects which protocol is to be used, but the actual processing +is the same in both cases. + +If, in response to its EHLO command, Exim is told that the SIZE parameter is +supported, it adds SIZE=<n> to each subsequent MAIL command. The value of <n> +is the message size plus the value of the size_addition option (default 1024) +to allow for additions to the message such as per-transport header lines, or +changes made in a transport filter. If size_addition is set negative, the use +of SIZE is suppressed. + +If the remote server advertises support for PIPELINING, Exim uses the +pipelining extension to SMTP (RFC 2197) to reduce the number of TCP/IP packets +required for the transaction. + +If the remote server advertises support for the STARTTLS command, and Exim was +built to support TLS encryption, it tries to start a TLS session unless the +server matches hosts_avoid_tls. See chapter 42 for more details. Either a match +in that or hosts_verify_avoid_tls apply when the transport is called for +verification. + +If the remote server advertises support for the AUTH command, Exim scans the +authenticators configuration for any suitable client settings, as described in +chapter 33. + +Responses from the remote host are supposed to be terminated by CR followed by +LF. However, there are known to be hosts that do not send CR characters, so in +order to be able to interwork with such hosts, Exim treats LF on its own as a +line terminator. + +If a message contains a number of different addresses, all those with the same +characteristics (for example, the same envelope sender) that resolve to the +same set of hosts, in the same order, are sent in a single SMTP transaction, +even if they are for different domains, unless there are more than the setting +of the max_rcpts option in the smtp transport allows, in which case they are +split into groups containing no more than max_rcpts addresses each. If +remote_max_parallel is greater than one, such groups may be sent in parallel +sessions. The order of hosts with identical MX values is not significant when +checking whether addresses can be batched in this way. + +When the smtp transport suffers a temporary failure that is not +message-related, Exim updates its transport-specific database, which contains +records indexed by host name that remember which messages are waiting for each +particular host. It also updates the retry database with new retry times. + +Exim's retry hints are based on host name plus IP address, so if one address of +a multi-homed host is broken, it will soon be skipped most of the time. See the +next section for more detail about error handling. + +When a message is successfully delivered over a TCP/IP SMTP connection, Exim +looks in the hints database for the transport to see if there are any queued +messages waiting for the host to which it is connected. If it finds one, it +creates a new Exim process using the -MC option (which can only be used by a +process running as root or the Exim user) and passes the TCP/IP socket to it so +that it can deliver another message using the same socket. The new process does +only those deliveries that are routed to the connected host, and may in turn +pass the socket on to a third process, and so on. + +The connection_max_messages option of the smtp transport can be used to limit +the number of messages sent down a single TCP/IP connection. + +The second and subsequent messages delivered down an existing connection are +identified in the main log by the addition of an asterisk after the closing +square bracket of the IP address. + + +48.2 Errors in outgoing SMTP +---------------------------- + +Three different kinds of error are recognized for outgoing SMTP: host errors, +message errors, and recipient errors. + +Host errors + + A host error is not associated with a particular message or with a + particular recipient of a message. The host errors are: + + + Connection refused or timed out, + + + Any error response code on connection, + + + Any error response code to EHLO or HELO, + + + Loss of connection at any time, except after ".", + + + I/O errors at any time, + + + Timeouts during the session, other than in response to MAIL, RCPT or + the "." at the end of the data. + + For a host error, a permanent error response on connection, or in response + to EHLO, causes all addresses routed to the host to be failed. Any other + host error causes all addresses to be deferred, and retry data to be + created for the host. It is not tried again, for any message, until its + retry time arrives. If the current set of addresses are not all delivered + in this run (to some alternative host), the message is added to the list of + those waiting for this host, so if it is still undelivered when a + subsequent successful delivery is made to the host, it will be sent down + the same SMTP connection. + +Message errors + + A message error is associated with a particular message when sent to a + particular host, but not with a particular recipient of the message. The + message errors are: + + + Any error response code to MAIL, DATA, or the "." that terminates the + data, + + + Timeout after MAIL, + + + Timeout or loss of connection after the "." that terminates the data. A + timeout after the DATA command itself is treated as a host error, as is + loss of connection at any other time. + + For a message error, a permanent error response (5xx) causes all addresses + to be failed, and a delivery error report to be returned to the sender. A + temporary error response (4xx), or one of the timeouts, causes all + addresses to be deferred. Retry data is not created for the host, but + instead, a retry record for the combination of host plus message id is + created. The message is not added to the list of those waiting for this + host. This ensures that the failing message will not be sent to this host + again until the retry time arrives. However, other messages that are routed + to the host are not affected, so if it is some property of the message that + is causing the error, it will not stop the delivery of other mail. + + If the remote host specified support for the SIZE parameter in its response + to EHLO, Exim adds SIZE=nnn to the MAIL command, so an over-large message + will cause a message error because the error arrives as a response to MAIL. + +Recipient errors + + A recipient error is associated with a particular recipient of a message. + The recipient errors are: + + + Any error response to RCPT, + + + Timeout after RCPT. + + For a recipient error, a permanent error response (5xx) causes the + recipient address to be failed, and a bounce message to be returned to the + sender. A temporary error response (4xx) or a timeout causes the failing + address to be deferred, and routing retry data to be created for it. This + is used to delay processing of the address in subsequent queue runs, until + its routing retry time arrives. This applies to all messages, but because + it operates only in queue runs, one attempt will be made to deliver a new + message to the failing address before the delay starts to operate. This + ensures that, if the failure is really related to the message rather than + the recipient ("message too big for this recipient" is a possible example), + other messages have a chance of getting delivered. If a delivery to the + address does succeed, the retry information gets cleared, so all stuck + messages get tried again, and the retry clock is reset. + + The message is not added to the list of those waiting for this host. Use of + the host for other messages is unaffected, and except in the case of a + timeout, other recipients are processed independently, and may be + successfully delivered in the current SMTP session. After a timeout it is + of course impossible to proceed with the session, so all addresses get + deferred. However, those other than the one that failed do not suffer any + subsequent retry delays. Therefore, if one recipient is causing trouble, + the others have a chance of getting through when a subsequent delivery + attempt occurs before the failing recipient's retry time. + +In all cases, if there are other hosts (or IP addresses) available for the +current set of addresses (for example, from multiple MX records), they are +tried in this run for any undelivered addresses, subject of course to their own +retry data. In other words, recipient error retry data does not take effect +until the next delivery attempt. + +Some hosts have been observed to give temporary error responses to every MAIL +command at certain times ("insufficient space" has been seen). It would be nice +if such circumstances could be recognized, and defer data for the host itself +created, but this is not possible within the current Exim design. What actually +happens is that retry data for every (host, message) combination is created. + +The reason that timeouts after MAIL and RCPT are treated specially is that +these can sometimes arise as a result of the remote host's verification +procedures. Exim makes this assumption, and treats them as if a temporary error +response had been received. A timeout after "." is treated specially because it +is known that some broken implementations fail to recognize the end of the +message if the last character of the last line is a binary zero. Thus, it is +helpful to treat this case as a message error. + +Timeouts at other times are treated as host errors, assuming a problem with the +host, or the connection to it. If a timeout after MAIL, RCPT, or "." is really +a connection problem, the assumption is that at the next try the timeout is +likely to occur at some other point in the dialogue, causing it then to be +treated as a host error. + +There is experimental evidence that some MTAs drop the connection after the +terminating "." if they do not like the contents of the message for some +reason, in contravention of the RFC, which indicates that a 5xx response should +be given. That is why Exim treats this case as a message rather than a host +error, in order not to delay other messages to the same host. + + +48.3 Incoming SMTP messages over TCP/IP +--------------------------------------- + +Incoming SMTP messages can be accepted in one of two ways: by running a +listening daemon, or by using inetd. In the latter case, the entry in /etc/ +inetd.conf should be like this: + +smtp stream tcp nowait exim /opt/exim/bin/exim in.exim -bs + +Exim distinguishes between this case and the case of a locally running user +agent using the -bs option by checking whether or not the standard input is a +socket. When it is, either the port must be privileged (less than 1024), or the +caller must be root or the Exim user. If any other user passes a socket with an +unprivileged port number, Exim prints a message on the standard error stream +and exits with an error code. + +By default, Exim does not make a log entry when a remote host connects or +disconnects (either via the daemon or inetd), unless the disconnection is +unexpected. It can be made to write such log entries by setting the +smtp_connection log selector. + +Commands from the remote host are supposed to be terminated by CR followed by +LF. However, there are known to be hosts that do not send CR characters. In +order to be able to interwork with such hosts, Exim treats LF on its own as a +line terminator. Furthermore, because common code is used for receiving +messages from all sources, a CR on its own is also interpreted as a line +terminator. However, the sequence "CR, dot, CR" does not terminate incoming +SMTP data. + +One area that sometimes gives rise to problems concerns the EHLO or HELO +commands. Some clients send syntactically invalid versions of these commands, +which Exim rejects by default. (This is nothing to do with verifying the data +that is sent, so helo_verify_hosts is not relevant.) You can tell Exim not to +apply a syntax check by setting helo_accept_junk_hosts to match the broken +hosts that send invalid commands. + +The amount of disk space available is checked whenever SIZE is received on a +MAIL command, independently of whether message_size_limit or check_spool_space +is configured, unless smtp_check_spool_space is set false. A temporary error is +given if there is not enough space. If check_spool_space is set, the check is +for that amount of space plus the value given with SIZE, that is, it checks +that the addition of the incoming message will not reduce the space below the +threshold. + +When a message is successfully received, Exim includes the local message id in +its response to the final "." that terminates the data. If the remote host logs +this text it can help with tracing what has happened to a message. + +The Exim daemon can limit the number of simultaneous incoming connections it is +prepared to handle (see the smtp_accept_max option). It can also limit the +number of simultaneous incoming connections from a single remote host (see the +smtp_accept_max_per_host option). Additional connection attempts are rejected +using the SMTP temporary error code 421. + +The Exim daemon does not rely on the SIGCHLD signal to detect when a subprocess +has finished, as this can get lost at busy times. Instead, it looks for +completed subprocesses every time it wakes up. Provided there are other things +happening (new incoming calls, starts of queue runs), completed processes will +be noticed and tidied away. On very quiet systems you may sometimes see a +"defunct" Exim process hanging about. This is not a problem; it will be noticed +when the daemon next wakes up. + +When running as a daemon, Exim can reserve some SMTP slots for specific hosts, +and can also be set up to reject SMTP calls from non-reserved hosts at times of +high system load - for details see the smtp_accept_reserve, smtp_load_reserve, +and smtp_reserve_hosts options. The load check applies in both the daemon and +inetd cases. + +Exim normally starts a delivery process for each message received, though this +can be varied by means of the -odq command line option and the queue_only, +queue_only_file, and queue_only_load options. The number of simultaneously +running delivery processes started in this way from SMTP input can be limited +by the smtp_accept_queue and smtp_accept_queue_per_connection options. When +either limit is reached, subsequently received messages are just put on the +input queue without starting a delivery process. + +The controls that involve counts of incoming SMTP calls (smtp_accept_max, +smtp_accept_queue, smtp_accept_reserve) are not available when Exim is started +up from the inetd daemon, because in that case each connection is handled by an +entirely independent Exim process. Control by load average is, however, +available with inetd. + +Exim can be configured to verify addresses in incoming SMTP commands as they +are received. See chapter 43 for details. It can also be configured to rewrite +addresses at this time - before any syntax checking is done. See section 31.9. + +Exim can also be configured to limit the rate at which a client host submits +MAIL and RCPT commands in a single SMTP session. See the smtp_ratelimit_hosts +option. + + +48.4 Unrecognized SMTP commands +------------------------------- + +If Exim receives more than smtp_max_unknown_commands unrecognized SMTP commands +during a single SMTP connection, it drops the connection after sending the +error response to the last command. The default value for +smtp_max_unknown_commands is 3. This is a defence against some kinds of abuse +that subvert web servers into making connections to SMTP ports; in these +circumstances, a number of non-SMTP lines are sent first. + + +48.5 Syntax and protocol errors in SMTP commands +------------------------------------------------ + +A syntax error is detected if an SMTP command is recognized, but there is +something syntactically wrong with its data, for example, a malformed email +address in a RCPT command. Protocol errors include invalid command sequencing +such as RCPT before MAIL. If Exim receives more than smtp_max_synprot_errors +such commands during a single SMTP connection, it drops the connection after +sending the error response to the last command. The default value for +smtp_max_synprot_errors is 3. This is a defence against broken clients that +loop sending bad commands (yes, it has been seen). + + +48.6 Use of non-mail SMTP commands +---------------------------------- + +The "non-mail" SMTP commands are those other than MAIL, RCPT, and DATA. Exim +counts such commands, and drops the connection if there are too many of them in +a single SMTP session. This action catches some denial-of-service attempts and +things like repeated failing AUTHs, or a mad client looping sending EHLO. The +global option smtp_accept_max_nonmail defines what "too many" means. Its +default value is 10. + +When a new message is expected, one occurrence of RSET is not counted. This +allows a client to send one RSET between messages (this is not necessary, but +some clients do it). Exim also allows one uncounted occurrence of HELO or EHLO, +and one occurrence of STARTTLS between messages. After starting up a TLS +session, another EHLO is expected, and so it too is not counted. + +The first occurrence of AUTH in a connection, or immediately following STARTTLS +is also not counted. Otherwise, all commands other than MAIL, RCPT, DATA, and +QUIT are counted. + +You can control which hosts are subject to the limit set by +smtp_accept_max_nonmail by setting smtp_accept_max_nonmail_hosts. The default +value is "*", which makes the limit apply to all hosts. This option means that +you can exclude any specific badly-behaved hosts that you have to live with. + + +48.7 The VRFY and EXPN commands +------------------------------- + +When Exim receives a VRFY or EXPN command on a TCP/IP connection, it runs the +ACL specified by acl_smtp_vrfy or acl_smtp_expn (as appropriate) in order to +decide whether the command should be accepted or not. + +When no ACL is defined for VRFY, or if it rejects without setting an explicit +response code, the command is accepted (with a 252 SMTP response code) in order +to support awkward clients that do a VRFY before every RCPT. When VRFY is +accepted, it runs exactly the same code as when Exim is called with the -bv +option, and returns 250/451/550 SMTP response codes. + +If no ACL for EXPN is defined, the command is rejected. When EXPN is accepted, +a single-level expansion of the address is done. EXPN is treated as an "address +test" (similar to the -bt option) rather than a verification (the -bv option). +If an unqualified local part is given as the argument to EXPN, it is qualified +with qualify_domain. Rejections of VRFY and EXPN commands are logged on the +main and reject logs, and VRFY verification failures are logged on the main log +for consistency with RCPT failures. + + +48.8 The ETRN command +--------------------- + +RFC 1985 describes an SMTP command called ETRN that is designed to overcome the +security problems of the TURN command (which has fallen into disuse). When Exim +receives an ETRN command on a TCP/IP connection, it runs the ACL specified by +acl_smtp_etrn in order to decide whether the command should be accepted or not. +If no ACL is defined, the command is rejected. + +The ETRN command is concerned with "releasing" messages that are awaiting +delivery to certain hosts. As Exim does not organize its message queue by host, +the only form of ETRN that is supported by default is the one where the text +starts with the "#" prefix, in which case the remainder of the text is specific +to the SMTP server. A valid ETRN command causes a run of Exim with the -R +option to happen, with the remainder of the ETRN text as its argument. For +example, + +ETRN #brigadoon + +runs the command + +exim -R brigadoon + +which causes a delivery attempt on all messages with undelivered addresses +containing the text "brigadoon". When smtp_etrn_serialize is set (the default), +Exim prevents the simultaneous execution of more than one queue run for the +same argument string as a result of an ETRN command. This stops a misbehaving +client from starting more than one queue runner at once. + +Exim implements the serialization by means of a hints database in which a +record is written whenever a process is started by ETRN, and deleted when the +process completes. However, Exim does not keep the SMTP session waiting for the +ETRN process to complete. Once ETRN is accepted, the client is sent a "success" +return code. Obviously there is scope for hints records to get left lying +around if there is a system or program crash. To guard against this, Exim +ignores any records that are more than six hours old. + +For more control over what ETRN does, the smtp_etrn_command option can used. +This specifies a command that is run whenever ETRN is received, whatever the +form of its argument. For example: + +smtp_etrn_command = /etc/etrn_command $domain \ + $sender_host_address + +The string is split up into arguments which are independently expanded. The +expansion variable $domain is set to the argument of the ETRN command, and no +syntax checking is done on the contents of this argument. Exim does not wait +for the command to complete, so its status code is not checked. Exim runs under +its own uid and gid when receiving incoming SMTP, so it is not possible for it +to change them before running the command. + + +48.9 Incoming local SMTP +------------------------ + +Some user agents use SMTP to pass messages to their local MTA using the +standard input and output, as opposed to passing the envelope on the command +line and writing the message to the standard input. This is supported by the +-bs option. This form of SMTP is handled in the same way as incoming messages +over TCP/IP (including the use of ACLs), except that the envelope sender given +in a MAIL command is ignored unless the caller is trusted. In an ACL you can +detect this form of SMTP input by testing for an empty host identification. It +is common to have this as the first line in the ACL that runs for RCPT +commands: + +accept hosts = : + +This accepts SMTP messages from local processes without doing any other tests. + + +48.10 Outgoing batched SMTP +--------------------------- + +Both the appendfile and pipe transports can be used for handling batched SMTP. +Each has an option called use_bsmtp which causes messages to be output in BSMTP +format. No SMTP responses are possible for this form of delivery. All it is +doing is using SMTP commands as a way of transmitting the envelope along with +the message. + +The message is written to the file or pipe preceded by the SMTP commands MAIL +and RCPT, and followed by a line containing a single dot. Lines in the message +that start with a dot have an extra dot added. The SMTP command HELO is not +normally used. If it is required, the message_prefix option can be used to +specify it. + +Because appendfile and pipe are both local transports, they accept only one +recipient address at a time by default. However, you can arrange for them to +handle several addresses at once by setting the batch_max option. When this is +done for BSMTP, messages may contain multiple RCPT commands. See chapter 25 for +more details. + +When one or more addresses are routed to a BSMTP transport by a router that +sets up a host list, the name of the first host on the list is available to the +transport in the variable $host. Here is an example of such a transport and +router: + +begin routers +route_append: + driver = manualroute + transport = smtp_appendfile + route_list = domain.example batch.host.example + +begin transports +smtp_appendfile: + driver = appendfile + directory = /var/bsmtp/$host + batch_max = 1000 + use_bsmtp + user = exim + +This causes messages addressed to domain.example to be written in BSMTP format +to /var/bsmtp/batch.host.example, with only a single copy of each message +(unless there are more than 1000 recipients). + + +48.11 Incoming batched SMTP +--------------------------- + +The -bS command line option causes Exim to accept one or more messages by +reading SMTP on the standard input, but to generate no responses. If the caller +is trusted, the senders in the MAIL commands are believed; otherwise the sender +is always the caller of Exim. Unqualified senders and receivers are not +rejected (there seems little point) but instead just get qualified. HELO and +EHLO act as RSET; VRFY, EXPN, ETRN and HELP, act as NOOP; QUIT quits. + +Minimal policy checking is done for BSMTP input. Only the non-SMTP ACL is run +in the same way as for non-SMTP local input. + +If an error is detected while reading a message, including a missing "." at the +end, Exim gives up immediately. It writes details of the error to the standard +output in a stylized way that the calling program should be able to make some +use of automatically, for example: + +554 Unexpected end of file +Transaction started in line 10 +Error detected in line 14 + +It writes a more verbose version, for human consumption, to the standard error +file, for example: + +An error was detected while processing a file of BSMTP input. +The error message was: + +501 '>' missing at end of address + +The SMTP transaction started in line 10. +The error was detected in line 12. +The SMTP command at fault was: + +rcpt to:<malformed@in.com.plete + +1 previous message was successfully processed. +The rest of the batch was abandoned. + +The return code from Exim is zero only if there were no errors. It is 1 if some +messages were accepted before an error was detected, and 2 if no messages were +accepted. + + + +=============================================================================== +49. CUSTOMIZING BOUNCE AND WARNING MESSAGES + +When a message fails to be delivered, or remains in the queue for more than a +configured amount of time, Exim sends a message to the original sender, or to +an alternative configured address. The text of these messages is built into the +code of Exim, but it is possible to change it, either by adding a single +string, or by replacing each of the paragraphs by text supplied in a file. + +The From: and To: header lines are automatically generated; you can cause a +Reply-To: line to be added by setting the errors_reply_to option. Exim also +adds the line + +Auto-Submitted: auto-generated + +to all warning and bounce messages, + + +49.1 Customizing bounce messages +-------------------------------- + +If bounce_message_text is set, its contents are included in the default message +immediately after "This message was created automatically by mail delivery +software." The string is not expanded. It is not used if bounce_message_file is +set. + +When bounce_message_file is set, it must point to a template file for +constructing error messages. The file consists of a series of text items, +separated by lines consisting of exactly four asterisks. If the file cannot be +opened, default text is used and a message is written to the main and panic +logs. If any text item in the file is empty, default text is used for that +item. + +Each item of text that is read from the file is expanded, and there are two +expansion variables which can be of use here: $bounce_recipient is set to the +recipient of an error message while it is being created, and +$bounce_return_size_limit contains the value of the return_size_limit option, +rounded to a whole number. + +The items must appear in the file in the following order: + + * The first item is included in the headers, and should include at least a + Subject: header. Exim does not check the syntax of these headers. + + * The second item forms the start of the error message. After it, Exim lists + the failing addresses with their error messages. + + * The third item is used to introduce any text from pipe transports that is + to be returned to the sender. It is omitted if there is no such text. + + * The fourth, fifth and sixth items will be ignored and may be empty. The + fields exist for back-compatibility + +The default state (bounce_message_file unset) is equivalent to the following +file, in which the sixth item is empty. The Subject: and some other lines have +been split in order to fit them on the page: + +Subject: Mail delivery failed + ${if eq{$sender_address}{$bounce_recipient} + {: returning message to sender}} +**** +This message was created automatically by mail delivery software. + +A message ${if eq{$sender_address}{$bounce_recipient} + {that you sent }{sent by + +<$sender_address> + +}}could not be delivered to all of its recipients. +This is a permanent error. The following address(es) failed: +**** +The following text was generated during the delivery attempt(s): +**** +------ This is a copy of the message, including all the headers. + ------ +**** +------ The body of the message is $message_size characters long; + only the first +------ $bounce_return_size_limit or so are included here. +**** + + +49.2 Customizing warning messages +--------------------------------- + +The option warn_message_file can be pointed at a template file for use when +warnings about message delays are created. In this case there are only three +text sections: + + * The first item is included in the headers, and should include at least a + Subject: header. Exim does not check the syntax of these headers. + + * The second item forms the start of the warning message. After it, Exim + lists the delayed addresses. + + * The third item then ends the message. + +The default state is equivalent to the following file, except that some lines +have been split here, in order to fit them on the page: + +Subject: Warning: message $message_exim_id delayed + $warn_message_delay +**** +This message was created automatically by mail delivery software. + +A message ${if eq{$sender_address}{$warn_message_recipients} +{that you sent }{sent by + +<$sender_address> + +}}has not been delivered to all of its recipients after +more than $warn_message_delay in the queue on $primary_hostname. + +The message identifier is: $message_exim_id +The subject of the message is: $h_subject +The date of the message is: $h_date + +The following address(es) have not yet been delivered: +**** +No action is required on your part. Delivery attempts will +continue for some time, and this warning may be repeated at +intervals if the message remains undelivered. Eventually the +mail delivery software will give up, and when that happens, +the message will be returned to you. + +However, in the default state the subject and date lines are omitted if no +appropriate headers exist. During the expansion of this file, +$warn_message_delay is set to the delay time in one of the forms "<n> minutes" +or "<n> hours", and $warn_message_recipients contains a list of recipients for +the warning message. There may be more than one if there are multiple addresses +with different errors_to settings on the routers that handled them. + + + +=============================================================================== +50. SOME COMMON CONFIGURATION SETTINGS + +This chapter discusses some configuration settings that seem to be fairly +common. More examples and discussion can be found in the Exim book. + + +50.1 Sending mail to a smart host +--------------------------------- + +If you want to send all mail for non-local domains to a "smart host", you +should replace the default dnslookup router with a router which does the +routing explicitly: + +send_to_smart_host: + driver = manualroute + route_list = !+local_domains smart.host.name + transport = remote_smtp + +You can use the smart host's IP address instead of the name if you wish. If you +are using Exim only to submit messages to a smart host, and not for receiving +incoming messages, you can arrange for it to do the submission synchronously by +setting the mua_wrapper option (see chapter 51). + + +50.2 Using Exim to handle mailing lists +--------------------------------------- + +Exim can be used to run simple mailing lists, but for large and/or complicated +requirements, the use of additional specialized mailing list software such as +Majordomo or Mailman is recommended. + +The redirect router can be used to handle mailing lists where each list is +maintained in a separate file, which can therefore be managed by an independent +manager. The domains router option can be used to run these lists in a separate +domain from normal mail. For example: + +lists: + driver = redirect + domains = lists.example + file = /usr/lists/$local_part + forbid_pipe + forbid_file + errors_to = $local_part-request@lists.example + no_more + +This router is skipped for domains other than lists.example. For addresses in +that domain, it looks for a file that matches the local part. If there is no +such file, the router declines, but because no_more is set, no subsequent +routers are tried, and so the whole delivery fails. + +The forbid_pipe and forbid_file options prevent a local part from being +expanded into a filename or a pipe delivery, which is usually inappropriate in +a mailing list. + +The errors_to option specifies that any delivery errors caused by addresses +taken from a mailing list are to be sent to the given address rather than the +original sender of the message. However, before acting on this, Exim verifies +the error address, and ignores it if verification fails. + +For example, using the configuration above, mail sent to dicts@lists.example is +passed on to those addresses contained in /usr/lists/dicts, with error reports +directed to dicts-request@lists.example, provided that this address can be +verified. There could be a file called /usr/lists/dicts-request containing the +address(es) of this particular list's manager(s), but other approaches, such as +setting up an earlier router (possibly using the local_part_prefix or +local_part_suffix options) to handle addresses of the form owner-xxx or xxx- +request, are also possible. + + +50.3 Syntax errors in mailing lists +----------------------------------- + +If an entry in redirection data contains a syntax error, Exim normally defers +delivery of the original address. That means that a syntax error in a mailing +list holds up all deliveries to the list. This may not be appropriate when a +list is being maintained automatically from data supplied by users, and the +addresses are not rigorously checked. + +If the skip_syntax_errors option is set, the redirect router just skips entries +that fail to parse, noting the incident in the log. If in addition +syntax_errors_to is set to a verifiable address, a message is sent to it +whenever a broken address is skipped. It is usually appropriate to set +syntax_errors_to to the same address as errors_to. + + +50.4 Re-expansion of mailing lists +---------------------------------- + +Exim remembers every individual address to which a message has been delivered, +in order to avoid duplication, but it normally stores only the original +recipient addresses with a message. If all the deliveries to a mailing list +cannot be done at the first attempt, the mailing list is re-expanded when the +delivery is next tried. This means that alterations to the list are taken into +account at each delivery attempt, so addresses that have been added to the list +since the message arrived will therefore receive a copy of the message, even +though it pre-dates their subscription. + +If this behaviour is felt to be undesirable, the one_time option can be set on +the redirect router. If this is done, any addresses generated by the router +that fail to deliver at the first attempt are added to the message as "top +level" addresses, and the parent address that generated them is marked +"delivered". Thus, expansion of the mailing list does not happen again at the +subsequent delivery attempts. The disadvantage of this is that if any of the +failing addresses are incorrect, correcting them in the file has no effect on +pre-existing messages. + +The original top-level address is remembered with each of the generated +addresses, and is output in any log messages. However, any intermediate parent +addresses are not recorded. This makes a difference to the log only if the +all_parents selector is set, but for mailing lists there is normally only one +level of expansion anyway. + + +50.5 Closed mailing lists +------------------------- + +The examples so far have assumed open mailing lists, to which anybody may send +mail. It is also possible to set up closed lists, where mail is accepted from +specified senders only. This is done by making use of the generic senders +option to restrict the router that handles the list. + +The following example uses the same file as a list of recipients and as a list +of permitted senders. It requires three routers: + +lists_request: + driver = redirect + domains = lists.example + local_part_suffix = -request + file = /usr/lists/$local_part$local_part_suffix + no_more + +lists_post: + driver = redirect + domains = lists.example + senders = ${if exists {/usr/lists/$local_part}\ + {lsearch;/usr/lists/$local_part}{*}} + file = /usr/lists/$local_part + forbid_pipe + forbid_file + errors_to = $local_part-request@lists.example + no_more + +lists_closed: + driver = redirect + domains = lists.example + allow_fail + data = :fail: $local_part@lists.example is a closed mailing list + +All three routers have the same domains setting, so for any other domains, they +are all skipped. The first router runs only if the local part ends in -request. +It handles messages to the list manager(s) by means of an open mailing list. + +The second router runs only if the senders precondition is satisfied. It checks +for the existence of a list that corresponds to the local part, and then checks +that the sender is on the list by means of a linear search. It is necessary to +check for the existence of the file before trying to search it, because +otherwise Exim thinks there is a configuration error. If the file does not +exist, the expansion of senders is *, which matches all senders. This means +that the router runs, but because there is no list, declines, and no_more +ensures that no further routers are run. The address fails with an "unrouteable +address" error. + +The third router runs only if the second router is skipped, which happens when +a mailing list exists, but the sender is not on it. This router forcibly fails +the address, giving a suitable error message. + + +50.6 Variable Envelope Return Paths (VERP) +------------------------------------------ + +Variable Envelope Return Paths - see https://cr.yp.to/proto/verp.txt - are a +way of helping mailing list administrators discover which subscription address +is the cause of a particular delivery failure. The idea is to encode the +original recipient address in the outgoing envelope sender address, so that if +the message is forwarded by another host and then subsequently bounces, the +original recipient can be extracted from the recipient address of the bounce. + +Envelope sender addresses can be modified by Exim using two different +facilities: the errors_to option on a router (as shown in previous mailing list +examples), or the return_path option on a transport. The second of these is +effective only if the message is successfully delivered to another host; it is +not used for errors detected on the local host (see the description of +return_path in chapter 24). Here is an example of the use of return_path to +implement VERP on an smtp transport: + +verp_smtp: + driver = smtp + max_rcpt = 1 + return_path = \ + ${if match {$return_path}{^(.+?)-request@your.dom.example\$}\ + {$1-request+$local_part=$domain@your.dom.example}fail} + +This has the effect of rewriting the return path (envelope sender) on outgoing +SMTP messages, if the local part of the original return path ends in +"-request", and the domain is your.dom.example. The rewriting inserts the local +part and domain of the recipient into the return path. Suppose, for example, +that a message whose return path has been set to +somelist-request@your.dom.example is sent to subscriber@other.dom.example. In +the transport, the return path is rewritten as + +somelist-request+subscriber=other.dom.example@your.dom.example + +For this to work, you must tell Exim to send multiple copies of messages that +have more than one recipient, so that each copy has just one recipient. This is +achieved by setting max_rcpt to 1. Without this, a single copy of a message +might be sent to several different recipients in the same domain, in which case +$local_part is not available in the transport, because it is not unique. + +Unless your host is doing nothing but mailing list deliveries, you should +probably use a separate transport for the VERP deliveries, so as not to use +extra resources in making one-per-recipient copies for other deliveries. This +can easily be done by expanding the transport option in the router: + +dnslookup: + driver = dnslookup + domains = ! +local_domains + transport = \ + ${if match {$return_path}{^(.+?)-request@your.dom.example\$}\ + {verp_smtp}{remote_smtp}} + no_more + +If you want to change the return path using errors_to in a router instead of +using return_path in the transport, you need to set errors_to on all routers +that handle mailing list addresses. This will ensure that all delivery errors, +including those detected on the local host, are sent to the VERP address. + +On a host that does no local deliveries and has no manual routing, only the +dnslookup router needs to be changed. A special transport is not needed for +SMTP deliveries. Every mailing list recipient has its own return path value, +and so Exim must hand them to the transport one at a time. Here is an example +of a dnslookup router that implements VERP: + +verp_dnslookup: + driver = dnslookup + domains = ! +local_domains + transport = remote_smtp + errors_to = \ + ${if match {$return_path}{^(.+?)-request@your.dom.example\$}} + {$1-request+$local_part=$domain@your.dom.example}fail} + no_more + +Before you start sending out messages with VERPed return paths, you must also +configure Exim to accept the bounce messages that come back to those paths. +Typically this is done by setting a local_part_suffix option for a router, and +using this to route the messages to wherever you want to handle them. + +The overhead incurred in using VERP depends very much on the size of the +message, the number of recipient addresses that resolve to the same remote +host, and the speed of the connection over which the message is being sent. If +a lot of addresses resolve to the same host and the connection is slow, sending +a separate copy of the message for each address may take substantially longer +than sending a single copy with many recipients (for which VERP cannot be +used). + + +50.7 Virtual domains +-------------------- + +The phrase virtual domain is unfortunately used with two rather different +meanings: + + * A domain for which there are no real mailboxes; all valid local parts are + aliases for other email addresses. Common examples are organizational + top-level domains and "vanity" domains. + + * One of a number of independent domains that are all handled by the same + host, with mailboxes on that host, but where the mailbox owners do not + necessarily have login accounts on that host. + +The first usage is probably more common, and does seem more "virtual" than the +second. This kind of domain can be handled in Exim with a straightforward +aliasing router. One approach is to create a separate alias file for each +virtual domain. Exim can test for the existence of the alias file to determine +whether the domain exists. The dsearch lookup type is useful here, leading to a +router of this form: + +virtual: + driver = redirect + domains = dsearch;/etc/mail/virtual + data = ${lookup{$local_part}lsearch{/etc/mail/virtual/$domain}} + no_more + +The domains option specifies that the router is to be skipped, unless there is +a file in the /etc/mail/virtual directory whose name is the same as the domain +that is being processed. When the router runs, it looks up the local part in +the file to find a new address (or list of addresses). The no_more setting +ensures that if the lookup fails (leading to data being an empty string), Exim +gives up on the address without trying any subsequent routers. + +This one router can handle all the virtual domains because the alias filenames +follow a fixed pattern. Permissions can be arranged so that appropriate people +can edit the different alias files. A successful aliasing operation results in +a new envelope recipient address, which is then routed from scratch. + +The other kind of "virtual" domain can also be handled in a straightforward +way. One approach is to create a file for each domain containing a list of +valid local parts, and use it in a router like this: + +my_domains: + driver = accept + domains = dsearch;/etc/mail/domains + local_parts = lsearch;/etc/mail/domains/$domain + transport = my_mailboxes + +The address is accepted if there is a file for the domain, and the local part +can be found in the file. The domains option is used to check for the file's +existence because domains is tested before the local_parts option (see section +3.12). You cannot use require_files, because that option is tested after +local_parts. The transport is as follows: + +my_mailboxes: + driver = appendfile + file = /var/mail/$domain/$local_part + user = mail + +This uses a directory of mailboxes for each domain. The user setting is +required, to specify which uid is to be used for writing to the mailboxes. + +The configuration shown here is just one example of how you might support this +requirement. There are many other ways this kind of configuration can be set +up, for example, by using a database instead of separate files to hold all the +information about the domains. + + +50.8 Multiple user mailboxes +---------------------------- + +Heavy email users often want to operate with multiple mailboxes, into which +incoming mail is automatically sorted. A popular way of handling this is to +allow users to use multiple sender addresses, so that replies can easily be +identified. Users are permitted to add prefixes or suffixes to their local +parts for this purpose. The wildcard facility of the generic router options +local_part_prefix and local_part_suffix can be used for this. For example, +consider this router: + +userforward: + driver = redirect + check_local_user + file = $home/.forward + local_part_suffix = -* + local_part_suffix_optional + allow_filter + +It runs a user's .forward file for all local parts of the form username-*. +Within the filter file the user can distinguish different cases by testing the +variable $local_part_suffix. For example: + +if $local_part_suffix contains -special then +save /home/$local_part/Mail/special +endif + +If the filter file does not exist, or does not deal with such addresses, they +fall through to subsequent routers, and, assuming no subsequent use of the +local_part_suffix option is made, they presumably fail. Thus, users have +control over which suffixes are valid. + +Alternatively, a suffix can be used to trigger the use of a different .forward +file - which is the way a similar facility is implemented in another MTA: + +userforward: + driver = redirect + check_local_user + file = $home/.forward$local_part_suffix + local_part_suffix = -* + local_part_suffix_optional + allow_filter + +If there is no suffix, .forward is used; if the suffix is -special, for +example, .forward-special is used. Once again, if the appropriate file does not +exist, or does not deal with the address, it is passed on to subsequent +routers, which could, if required, look for an unqualified .forward file to use +as a default. + + +50.9 Simplified vacation processing +----------------------------------- + +The traditional way of running the vacation program is for a user to set up a +pipe command in a .forward file (see section 22.6 for syntax details). This is +prone to error by inexperienced users. There are two features of Exim that can +be used to make this process simpler for users: + + * A local part prefix such as "vacation-" can be specified on a router which + can cause the message to be delivered directly to the vacation program, or + alternatively can use Exim's autoreply transport. The contents of a user's + .forward file are then much simpler. For example: + + spqr, vacation-spqr + + * The require_files generic router option can be used to trigger a vacation + delivery by checking for the existence of a certain file in the user's home + directory. The unseen generic option should also be used, to ensure that + the original delivery also proceeds. In this case, all the user has to do + is to create a file called, say, .vacation, containing a vacation message. + +Another advantage of both these methods is that they both work even when the +use of arbitrary pipes by users is locked out. + + +50.10 Taking copies of mail +--------------------------- + +Some installations have policies that require archive copies of all messages to +be made. A single copy of each message can easily be taken by an appropriate +command in a system filter, which could, for example, use a different file for +each day's messages. + +There is also a shadow transport mechanism that can be used to take copies of +messages that are successfully delivered by local transports, one copy per +delivery. This could be used, inter alia, to implement automatic notification +of delivery by sites that insist on doing such things. + + +50.11 Intermittently connected hosts +------------------------------------ + +It has become quite common (because it is cheaper) for hosts to connect to the +Internet periodically rather than remain connected all the time. The normal +arrangement is that mail for such hosts accumulates on a system that is +permanently connected. + +Exim was designed for use on permanently connected hosts, and so it is not +particularly well-suited to use in an intermittently connected environment. +Nevertheless there are some features that can be used. + + +50.12 Exim on the upstream server host +-------------------------------------- + +It is tempting to arrange for incoming mail for the intermittently connected +host to remain in Exim's queue until the client connects. However, this +approach does not scale very well. Two different kinds of waiting message are +being mixed up in the same queue - those that cannot be delivered because of +some temporary problem, and those that are waiting for their destination host +to connect. This makes it hard to manage the queue, as well as wasting +resources, because each queue runner scans the entire queue. + +A better approach is to separate off those messages that are waiting for an +intermittently connected host. This can be done by delivering these messages +into local files in batch SMTP, "mailstore", or other envelope-preserving +format, from where they are transmitted by other software when their +destination connects. This makes it easy to collect all the mail for one host +in a single directory, and to apply local timeout rules on a per-message basis +if required. + +On a very small scale, leaving the mail on Exim's queue can be made to work. If +you are doing this, you should configure Exim with a long retry period for the +intermittent host. For example: + +cheshire.wonderland.fict.example * F,5d,24h + +This stops a lot of failed delivery attempts from occurring, but Exim remembers +which messages it has queued up for that host. Once the intermittent host comes +online, forcing delivery of one message (either by using the -M or -R options, +or by using the ETRN SMTP command (see section 48.8) causes all the queued up +messages to be delivered, often down a single SMTP connection. While the host +remains connected, any new messages get delivered immediately. + +If the connecting hosts do not have fixed IP addresses, that is, if a host is +issued with a different IP address each time it connects, Exim's retry +mechanisms on the holding host get confused, because the IP address is normally +used as part of the key string for holding retry information. This can be +avoided by unsetting retry_include_ip_address on the smtp transport. Since this +has disadvantages for permanently connected hosts, it is best to arrange a +separate transport for the intermittently connected ones. + + +50.13 Exim on the intermittently connected client host +------------------------------------------------------ + +The value of smtp_accept_queue_per_connection should probably be increased, or +even set to zero (that is, disabled) on the intermittently connected host, so +that all incoming messages down a single connection get delivered immediately. + +Mail waiting to be sent from an intermittently connected host will probably not +have been routed, because without a connection DNS lookups are not possible. +This means that if a normal queue run is done at connection time, each message +is likely to be sent in a separate SMTP session. This can be avoided by +starting the queue run with a command line option beginning with -qq instead of +-q. In this case, the queue is scanned twice. In the first pass, routing is +done but no deliveries take place. The second pass is a normal queue run; since +all the messages have been previously routed, those destined for the same host +are likely to get sent as multiple deliveries in a single SMTP connection. + + + +=============================================================================== +51. USING EXIM AS A NON-QUEUEING CLIENT + +On a personal computer, it is a common requirement for all email to be sent to +a "smart host". There are plenty of MUAs that can be configured to operate that +way, for all the popular operating systems. However, there are some MUAs for +Unix-like systems that cannot be so configured: they submit messages using the +command line interface of /usr/sbin/sendmail. Furthermore, utility programs +such as cron submit messages this way. + +If the personal computer runs continuously, there is no problem, because it can +run a conventional MTA that handles delivery to the smart host, and deal with +any delays via its queueing mechanism. However, if the computer does not run +continuously or runs different operating systems at different times, queueing +email is not desirable. + +There is therefore a requirement for something that can provide the /usr/sbin/ +sendmail interface but deliver messages to a smart host without any queueing or +retrying facilities. Furthermore, the delivery to the smart host should be +synchronous, so that if it fails, the sending MUA is immediately informed. In +other words, we want something that extends an MUA that submits to a local MTA +via the command line so that it behaves like one that submits to a remote smart +host using TCP/SMTP. + +There are a number of applications (for example, there is one called ssmtp) +that do this job. However, people have found them to be lacking in various +ways. For instance, you might want to allow aliasing and forwarding to be done +before sending a message to the smart host. + +Exim already had the necessary infrastructure for doing this job. Just a few +tweaks were needed to make it behave as required, though it is somewhat of an +overkill to use a fully-featured MTA for this purpose. + +There is a Boolean global option called mua_wrapper, defaulting false. Setting +mua_wrapper true causes Exim to run in a special mode where it assumes that it +is being used to "wrap" a command-line MUA in the manner just described. As +well as setting mua_wrapper, you also need to provide a compatible router and +transport configuration. Typically there will be just one router and one +transport, sending everything to a smart host. + +When run in MUA wrapping mode, the behaviour of Exim changes in the following +ways: + + * A daemon cannot be run, nor will Exim accept incoming messages from inetd. + In other words, the only way to submit messages is via the command line. + + * Each message is synchronously delivered as soon as it is received (-odi is + assumed). All queueing options (queue_only, queue_smtp_domains, control in + an ACL, etc.) are quietly ignored. The Exim reception process does not + finish until the delivery attempt is complete. If the delivery is + successful, a zero return code is given. + + * Address redirection is permitted, but the final routing for all addresses + must be to the same remote transport, and to the same list of hosts. + Furthermore, the return address (envelope sender) must be the same for all + recipients, as must any added or deleted header lines. In other words, it + must be possible to deliver the message in a single SMTP transaction, + however many recipients there are. + + * If these conditions are not met, or if routing any address results in a + failure or defer status, or if Exim is unable to deliver all the recipients + successfully to one of the smart hosts, delivery of the entire message + fails. + + * Because no queueing is allowed, all failures are treated as permanent; + there is no distinction between 4xx and 5xx SMTP response codes from the + smart host. Furthermore, because only a single yes/no response can be given + to the caller, it is not possible to deliver to some recipients and not + others. If there is an error (temporary or permanent) for any recipient, + all are failed. + + * If more than one smart host is listed, Exim will try another host after a + connection failure or a timeout, in the normal way. However, if this kind + of failure happens for all the hosts, the delivery fails. + + * When delivery fails, an error message is written to the standard error + stream (as well as to Exim's log), and Exim exits to the caller with a + return code value 1. The message is expunged from Exim's spool files. No + bounce messages are ever generated. + + * No retry data is maintained, and any retry rules are ignored. + + * A number of Exim options are overridden: deliver_drop_privilege is forced + true, max_rcpt in the smtp transport is forced to "unlimited", + remote_max_parallel is forced to one, and fallback hosts are ignored. + +The overall effect is that Exim makes a single synchronous attempt to deliver +the message, failing if there is any kind of problem. Because no local +deliveries are done and no daemon can be run, Exim does not need root +privilege. It should be possible to run it setuid to exim instead of setuid to +root. See section 55.3 for a general discussion about the advantages and +disadvantages of running without root privilege. + + + +=============================================================================== +52. LOG FILES + +Exim writes three different logs, referred to as the main log, the reject log, +and the panic log: + + * The main log records the arrival of each message and each delivery in a + single line in each case. The format is as compact as possible, in an + attempt to keep down the size of log files. Two-character flag sequences + make it easy to pick out these lines. A number of other events are recorded + in the main log. Some of them are optional, in which case the log_selector + option controls whether they are included or not. A Perl script called + eximstats, which does simple analysis of main log files, is provided in the + Exim distribution (see section 53.7). + + * The reject log records information from messages that are rejected as a + result of a configuration option (that is, for policy reasons). The first + line of each rejection is a copy of the line that is also written to the + main log. Then, if the message's header has been read at the time the log + is written, its contents are written to this log. Only the original header + lines are available; header lines added by ACLs are not logged. You can use + the reject log to check that your policy controls are working correctly; on + a busy host this may be easier than scanning the main log for rejection + messages. You can suppress the writing of the reject log by setting + write_rejectlog false. + + * When certain serious errors occur, Exim writes entries to its panic log. If + the error is sufficiently disastrous, Exim bombs out afterwards. Panic log + entries are usually written to the main log as well, but can get lost amid + the mass of other entries. The panic log should be empty under normal + circumstances. It is therefore a good idea to check it (or to have a cron + script check it) regularly, in order to become aware of any problems. When + Exim cannot open its panic log, it tries as a last resort to write to the + system log (syslog). This is opened with LOG_PID+LOG_CONS and the facility + code of LOG_MAIL. The message itself is written at priority LOG_CRIT. + +Every log line starts with a timestamp, in the format shown in the following +example. Note that many of the examples shown in this chapter are line-wrapped. +In the log file, this would be all on one line: + +2001-09-16 16:09:47 SMTP connection from [127.0.0.1] closed + by QUIT + +By default, the timestamps are in the local timezone. There are two ways of +changing this: + + * You can set the timezone option to a different time zone; in particular, if + you set + + timezone = UTC + + the timestamps will be in UTC (aka GMT). + + * If you set log_timezone true, the time zone is added to the timestamp, for + example: + + 2003-04-25 11:17:07 +0100 Start queue run: pid=12762 + +Exim does not include its process id in log lines by default, but you can +request that it does so by specifying the "pid" log selector (see section 52.15 +). When this is set, the process id is output, in square brackets, immediately +after the time and date. + + +52.1 Where the logs are written +------------------------------- + +The logs may be written to local files, or to syslog, or both. However, it +should be noted that many syslog implementations use UDP as a transport, and +are therefore unreliable in the sense that messages are not guaranteed to +arrive at the loghost, nor is the ordering of messages necessarily maintained. +It has also been reported that on large log files (tens of megabytes) you may +need to tweak syslog to prevent it syncing the file with each write - on Linux +this has been seen to make syslog take 90% plus of CPU time. + +The destination for Exim's logs is configured by setting LOG_FILE_PATH in Local +/Makefile or by setting log_file_path in the runtime configuration. This latter +string is expanded, so it can contain, for example, references to the host +name: + +log_file_path = /var/log/$primary_hostname/exim_%slog + +It is generally advisable, however, to set the string in Local/Makefile rather +than at runtime, because then the setting is available right from the start of +Exim's execution. Otherwise, if there's something it wants to log before it has +read the configuration file (for example, an error in the configuration file) +it will not use the path you want, and may not be able to log at all. + +The value of LOG_FILE_PATH or log_file_path is a colon-separated list, +currently limited to at most two items. This is one option where the facility +for changing a list separator may not be used. The list must always be +colon-separated. If an item in the list is "syslog" then syslog is used; +otherwise the item must either be an absolute path, containing "%s" at the +point where "main", "reject", or "panic" is to be inserted, or be empty, +implying the use of a default path. + +When Exim encounters an empty item in the list, it searches the list defined by +LOG_FILE_PATH, and uses the first item it finds that is neither empty nor +"syslog". This means that an empty item in log_file_path can be used to mean +"use the path specified at build time". It no such item exists, log files are +written in the log subdirectory of the spool directory. This is equivalent to +the setting: + +log_file_path = $spool_directory/log/%slog + +If you do not specify anything at build time or runtime, or if you unset the +option at runtime (i.e. "log_file_path = "), that is where the logs are +written. + +A log file path may also contain "%D" or "%M" if datestamped log filenames are +in use - see section 52.3 below. + +Here are some examples of possible settings: + +LOG_FILE_PATH=syslog syslog only +LOG_FILE_PATH=:syslog syslog and default path +LOG_FILE_PATH=syslog : /usr/log/exim_%s syslog and specified path +LOG_FILE_PATH=/usr/log/exim_%s specified path only + +If there are more than two paths in the list, the first is used and a panic +error is logged. + + +52.2 Logging to local files that are periodically "cycled" +---------------------------------------------------------- + +Some operating systems provide centralized and standardized methods for cycling +log files. For those that do not, a utility script called exicyclog is provided +(see section 53.6). This renames and compresses the main and reject logs each +time it is called. The maximum number of old logs to keep can be set. It is +suggested this script is run as a daily cron job. + +An Exim delivery process opens the main log when it first needs to write to it, +and it keeps the file open in case subsequent entries are required - for +example, if a number of different deliveries are being done for the same +message. However, remote SMTP deliveries can take a long time, and this means +that the file may be kept open long after it is renamed if exicyclog or +something similar is being used to rename log files on a regular basis. To +ensure that a switch of log files is noticed as soon as possible, Exim calls +stat() on the main log's name before reusing an open file, and if the file does +not exist, or its inode has changed, the old file is closed and Exim tries to +open the main log from scratch. Thus, an old log file may remain open for quite +some time, but no Exim processes should write to it once it has been renamed. + + +52.3 Datestamped log files +-------------------------- + +Instead of cycling the main and reject log files by renaming them periodically, +some sites like to use files whose names contain a datestamp, for example, +mainlog-20031225. The datestamp is in the form yyyymmdd or yyyymm. Exim has +support for this way of working. It is enabled by setting the log_file_path +option to a path that includes "%D" or "%M" at the point where the datestamp is +required. For example: + +log_file_path = /var/spool/exim/log/%slog-%D +log_file_path = /var/log/exim-%s-%D.log +log_file_path = /var/spool/exim/log/%D-%slog +log_file_path = /var/log/exim/%s.%M + +As before, "%s" is replaced by "main" or "reject"; the following are examples +of names generated by the above examples: + +/var/spool/exim/log/mainlog-20021225 +/var/log/exim-reject-20021225.log +/var/spool/exim/log/20021225-mainlog +/var/log/exim/main.200212 + +When this form of log file is specified, Exim automatically switches to new +files at midnight. It does not make any attempt to compress old logs; you will +need to write your own script if you require this. You should not run exicyclog +with this form of logging. + +The location of the panic log is also determined by log_file_path, but it is +not datestamped, because rotation of the panic log does not make sense. When +generating the name of the panic log, "%D" or "%M" are removed from the string. +In addition, if it immediately follows a slash, a following non-alphanumeric +character is removed; otherwise a preceding non-alphanumeric character is +removed. Thus, the four examples above would give these panic log names: + +/var/spool/exim/log/paniclog +/var/log/exim-panic.log +/var/spool/exim/log/paniclog +/var/log/exim/panic + + +52.4 Logging to syslog +---------------------- + +The use of syslog does not change what Exim logs or the format of its messages, +except in one respect. If syslog_timestamp is set false, the timestamps on +Exim's log lines are omitted when these lines are sent to syslog. Apart from +that, the same strings are written to syslog as to log files. The syslog +"facility" is set to LOG_MAIL, and the program name to "exim" by default, but +you can change these by setting the syslog_facility and syslog_processname +options, respectively. If Exim was compiled with SYSLOG_LOG_PID set in Local/ +Makefile (this is the default in src/EDITME), then, on systems that permit it +(all except ULTRIX), the LOG_PID flag is set so that the syslog() call adds the +pid as well as the time and host name to each line. The three log streams are +mapped onto syslog priorities as follows: + + * mainlog is mapped to LOG_INFO + + * rejectlog is mapped to LOG_NOTICE + + * paniclog is mapped to LOG_ALERT + +Many log lines are written to both mainlog and rejectlog, and some are written +to both mainlog and paniclog, so there will be duplicates if these are routed +by syslog to the same place. You can suppress this duplication by setting +syslog_duplication false. + +Exim's log lines can sometimes be very long, and some of its rejectlog entries +contain multiple lines when headers are included. To cope with both these +cases, entries written to syslog are split into separate syslog() calls at each +internal newline, and also after a maximum of 870 data characters. (This allows +for a total syslog line length of 1024, when additions such as timestamps are +added.) If you are running a syslog replacement that can handle lines longer +than the 1024 characters allowed by RFC 3164, you should set + +SYSLOG_LONG_LINES=yes + +in Local/Makefile before building Exim. That stops Exim from splitting long +lines, but it still splits at internal newlines in reject log entries. + +To make it easy to re-assemble split lines later, each component of a split +entry starts with a string of the form [<n>/<m>] or [<n>\<m>] where <n> is the +component number and <m> is the total number of components in the entry. The / +delimiter is used when the line was split because it was too long; if it was +split because of an internal newline, the \ delimiter is used. For example, +supposing the length limit to be 50 instead of 870, the following would be the +result of a typical rejection message to mainlog (LOG_INFO), each line in +addition being preceded by the time, host name, and pid as added by syslog: + +[1/5] 2002-09-16 16:09:43 16RdAL-0006pc-00 rejected from +[2/5] [127.0.0.1] (ph10): syntax error in 'From' header +[3/5] when scanning for sender: missing or malformed lo +[4/5] cal part in "<>" (envelope sender is <ph10@cam.exa +[5/5] mple>) + +The same error might cause the following lines to be written to "rejectlog" +(LOG_NOTICE): + +[1/18] 2002-09-16 16:09:43 16RdAL-0006pc-00 rejected fro +[2/18] m [127.0.0.1] (ph10): syntax error in 'From' head +[3/18] er when scanning for sender: missing or malformed +[4/18] local part in "<>" (envelope sender is <ph10@cam +[5\18] .example>) +[6\18] Recipients: ph10@some.domain.cam.example +[7\18] P Received: from [127.0.0.1] (ident=ph10) +[8\18] by xxxxx.cam.example with smtp (Exim 4.00) +[9\18] id 16RdAL-0006pc-00 +[10/18] for ph10@cam.example; Mon, 16 Sep 2002 16: +[11\18] 09:43 +0100 +[12\18] F From: <> +[13\18] Subject: this is a test header +[18\18] X-something: this is another header +[15/18] I Message-Id: <E16RdAL-0006pc-00@xxxxx.cam.examp +[16\18] le> +[17\18] B Bcc: +[18/18] Date: Mon, 16 Sep 2002 16:09:43 +0100 + +Log lines that are neither too long nor contain newlines are written to syslog +without modification. + +If only syslog is being used, the Exim monitor is unable to provide a log tail +display, unless syslog is routing mainlog to a file on the local host and the +environment variable EXIMON_LOG_FILE_PATH is set to tell the monitor where it +is. + + +52.5 Log line flags +------------------- + +One line is written to the main log for each message received, and for each +successful, unsuccessful, and delayed delivery. These lines can readily be +picked out by the distinctive two-character flags that immediately follow the +timestamp. The flags are: + +<= message arrival +(= message fakereject +=> normal message delivery +-> additional address in same delivery +>> cutthrough message delivery +*> delivery suppressed by -N +** delivery failed; address bounced +== delivery deferred; temporary problem + + +52.6 Logging message reception +------------------------------ + +The format of the single-line entry in the main log that is written for every +message received is shown in the basic example below, which is split over +several lines in order to fit it on the page: + +2002-10-31 08:57:53 16ZCW1-0005MB-00 <= kryten@dwarf.fict.example + H=mailer.fict.example [192.168.123.123] U=exim + P=smtp S=5678 id=<incoming message id> + +The address immediately following "<=" is the envelope sender address. A bounce +message is shown with the sender address "<>", and if it is locally generated, +this is followed by an item of the form + +R=<message id> + +which is a reference to the message that caused the bounce to be sent. + +For messages from other hosts, the H and U fields identify the remote host and +record the RFC 1413 identity of the user that sent the message, if one was +received. The number given in square brackets is the IP address of the sending +host. If there is a single, unparenthesized host name in the H field, as above, +it has been verified to correspond to the IP address (see the host_lookup +option). If the name is in parentheses, it was the name quoted by the remote +host in the SMTP HELO or EHLO command, and has not been verified. If +verification yields a different name to that given for HELO or EHLO, the +verified name appears first, followed by the HELO or EHLO name in parentheses. + +Misconfigured hosts (and mail forgers) sometimes put an IP address, with or +without brackets, in the HELO or EHLO command, leading to entries in the log +containing text like these examples: + +H=(10.21.32.43) [192.168.8.34] +H=([10.21.32.43]) [192.168.8.34] + +This can be confusing. Only the final address in square brackets can be relied +on. + +For locally generated messages (that is, messages not received over TCP/IP), +the H field is omitted, and the U field contains the login name of the caller +of Exim. + +For all messages, the P field specifies the protocol used to receive the +message. This is the value that is stored in $received_protocol. In the case of +incoming SMTP messages, the value indicates whether or not any SMTP extensions +(ESMTP), encryption, or authentication were used. If the SMTP session was +encrypted, there is an additional X field that records the cipher suite that +was used. + +The protocol is set to "esmtpsa" or "esmtpa" for messages received from hosts +that have authenticated themselves using the SMTP AUTH command. The first value +is used when the SMTP connection was encrypted ("secure"). In this case there +is an additional item A= followed by the name of the authenticator that was +used. If an authenticated identification was set up by the authenticator's +server_set_id option, this is logged too, separated by a colon from the +authenticator name. + +The id field records the existing message id, if present. The size of the +received message is given by the S field. When the message is delivered, +headers may be removed or added, so that the size of delivered copies of the +message may not correspond with this value (and indeed may be different to each +other). + +The log_selector option can be used to request the logging of additional data +when a message is received. See section 52.15 below. + + +52.7 Logging deliveries +----------------------- + +The format of the single-line entry in the main log that is written for every +delivery is shown in one of the examples below, for local and remote +deliveries, respectively. Each example has been split into multiple lines in +order to fit it on the page: + +2002-10-31 08:59:13 16ZCW1-0005MB-00 => marv + <marv@hitch.fict.example> R=localuser T=local_delivery +2002-10-31 09:00:10 16ZCW1-0005MB-00 => + monk@holistic.fict.example R=dnslookup T=remote_smtp + H=holistic.fict.example [192.168.234.234] + +For ordinary local deliveries, the original address is given in angle brackets +after the final delivery address, which might be a pipe or a file. If +intermediate address(es) exist between the original and the final address, the +last of these is given in parentheses after the final address. The R and T +fields record the router and transport that were used to process the address. + +If SMTP AUTH was used for the delivery there is an additional item A= followed +by the name of the authenticator that was used. If an authenticated +identification was set up by the authenticator's client_set_id option, this is +logged too, separated by a colon from the authenticator name. + +If a shadow transport was run after a successful local delivery, the log line +for the successful delivery has an item added on the end, of the form + +ST=<shadow transport name> + +If the shadow transport did not succeed, the error message is put in +parentheses afterwards. + +When more than one address is included in a single delivery (for example, two +SMTP RCPT commands in one transaction) the second and subsequent addresses are +flagged with "->" instead of "=>". When two or more messages are delivered down +a single SMTP connection, an asterisk follows the IP address in the log lines +for the second and subsequent messages. When two or more messages are delivered +down a single TLS connection, the DNS and some TLS-related information logged +for the first message delivered will not be present in the log lines for the +second and subsequent messages. TLS cipher information is still available. + +When delivery is done in cutthrough mode it is flagged with ">>" and the log +line precedes the reception line, since cutthrough waits for a possible +rejection from the destination in case it can reject the sourced item. + +The generation of a reply message by a filter file gets logged as a "delivery" +to the addressee, preceded by ">". + +The log_selector option can be used to request the logging of additional data +when a message is delivered. See section 52.15 below. + + +52.8 Discarded deliveries +------------------------- + +When a message is discarded as a result of the command "seen finish" being +obeyed in a filter file which generates no deliveries, a log entry of the form + +2002-12-10 00:50:49 16auJc-0001UB-00 => discarded + <low.club@bridge.example> R=userforward + +is written, to record why no deliveries are logged. When a message is discarded +because it is aliased to ":blackhole:" the log line is like this: + +1999-03-02 09:44:33 10HmaX-0005vi-00 => :blackhole: + <hole@nowhere.example> R=blackhole_router + + +52.9 Deferred deliveries +------------------------ + +When a delivery is deferred, a line of the following form is logged: + +2002-12-19 16:20:23 16aiQz-0002Q5-00 == marvin@endrest.example + R=dnslookup T=smtp defer (146): Connection refused + +In the case of remote deliveries, the error is the one that was given for the +last IP address that was tried. Details of individual SMTP failures are also +written to the log, so the above line would be preceded by something like + +2002-12-19 16:20:23 16aiQz-0002Q5-00 Failed to connect to + mail1.endrest.example [192.168.239.239]: Connection refused + +When a deferred address is skipped because its retry time has not been reached, +a message is written to the log, but this can be suppressed by setting an +appropriate value in log_selector. + + +52.10 Delivery failures +----------------------- + +If a delivery fails because an address cannot be routed, a line of the +following form is logged: + +1995-12-19 16:20:23 0tRiQz-0002Q5-00 ** jim@trek99.example + <jim@trek99.example>: unknown mail domain + +If a delivery fails at transport time, the router and transport are shown, and +the response from the remote host is included, as in this example: + +2002-07-11 07:14:17 17SXDU-000189-00 ** ace400@pb.example + R=dnslookup T=remote_smtp: SMTP error from remote mailer + after pipelined RCPT TO:<ace400@pb.example>: host + pbmail3.py.example [192.168.63.111]: 553 5.3.0 + <ace400@pb.example>...Addressee unknown + +The word "pipelined" indicates that the SMTP PIPELINING extension was being +used. See hosts_avoid_esmtp in the smtp transport for a way of disabling +PIPELINING. The log lines for all forms of delivery failure are flagged with +"**". + + +52.11 Fake deliveries +--------------------- + +If a delivery does not actually take place because the -N option has been used +to suppress it, a normal delivery line is written to the log, except that "=>" +is replaced by "*>". + + +52.12 Completion +---------------- + +A line of the form + +2002-10-31 09:00:11 16ZCW1-0005MB-00 Completed + +is written to the main log when a message is about to be removed from the spool +at the end of its processing. + + +52.13 Summary of Fields in Log Lines +------------------------------------ + +A summary of the field identifiers that are used in log lines is shown in the +following table: + +A authenticator name (and optional id and sender) +C SMTP confirmation on delivery + command list for "no mail in SMTP session" +CV certificate verification status +D duration of "no mail in SMTP session" +DKIM domain verified in incoming message +DN distinguished name from peer certificate +DS DNSSEC secured lookups +DT on => lines: time taken for a delivery +F sender address (on delivery lines) +H host name and IP address +I local interface used +id message id for incoming message +K CHUNKING extension used +L on <= and => lines: PIPELINING extension used +M8S 8BITMIME status for incoming message +P on <= lines: protocol used + on => and ** lines: return path +PRDR PRDR extension used +PRX on <= and => lines: proxy address +Q alternate queue name +QT on => lines: time spent on queue so far + on "Completed" lines: time spent on queue +R on <= lines: reference for local bounce + on => >> ** and == lines: router name +RT on <= lines: time taken for reception +S size of message in bytes +SNI server name indication from TLS client hello +ST shadow transport name +T on <= lines: message subject (topic) +TFO connection took advantage of TCP Fast Open + on => ** and == lines: transport name +U local user or RFC 1413 identity +X TLS cipher suite + + +52.14 Other log entries +----------------------- + +Various other types of log entry are written from time to time. Most should be +self-explanatory. Among the more common are: + + * retry time not reached An address previously suffered a temporary error + during routing or local delivery, and the time to retry has not yet + arrived. This message is not written to an individual message log file + unless it happens during the first delivery attempt. + + * retry time not reached for any host An address previously suffered + temporary errors during remote delivery, and the retry time has not yet + arrived for any of the hosts to which it is routed. + + * spool file locked An attempt to deliver a message cannot proceed because + some other Exim process is already working on the message. This can be + quite common if queue running processes are started at frequent intervals. + The exiwhat utility script can be used to find out what Exim processes are + doing. + + * error ignored There are several circumstances that give rise to this + message: + + 1. Exim failed to deliver a bounce message whose age was greater than + ignore_bounce_errors_after. The bounce was discarded. + + 2. A filter file set up a delivery using the "noerror" option, and the + delivery failed. The delivery was discarded. + + 3. A delivery set up by a router configured with + + errors_to = <> + + failed. The delivery was discarded. + + * DKIM: d= Verbose results of a DKIM verification attempt, if enabled for + logging and the message has a DKIM signature header. + + +52.15 Reducing or increasing what is logged +------------------------------------------- + +By setting the log_selector global option, you can disable some of Exim's +default logging, or you can request additional logging. The value of +log_selector is made up of names preceded by plus or minus characters. For +example: + +log_selector = +arguments -retry_defer + +The list of optional log items is in the following table, with the default +selection marked by asterisks: + + 8bitmime received 8BITMIME status +*acl_warn_skipped skipped warn statement in ACL + address_rewrite address rewriting + all_parents all parents in => lines + arguments command line arguments +*connection_reject connection rejections +*delay_delivery immediate delivery delayed + deliver_time time taken to perform delivery + delivery_size add S=nnn to => lines +*dkim DKIM verified domain on <= lines + dkim_verbose separate full DKIM verification result line, per signature +*dnslist_defer defers of DNS list (aka RBL) lookups + dnssec DNSSEC secured lookups +*etrn ETRN commands +*host_lookup_failed as it says + ident_timeout timeout for ident connection + incoming_interface local interface on <= and => lines + incoming_port remote port on <= lines +*lost_incoming_connection as it says (includes timeouts) + millisec millisecond timestamps and RT,QT,DT,D times + outgoing_interface local interface on => lines + outgoing_port add remote port to => lines +*queue_run start and end queue runs + queue_time time on queue for one recipient + queue_time_overall time on queue for whole message + pid Exim process id + pipelining PIPELINING use, on <= and => lines + proxy proxy address on <= and => lines + receive_time time taken to receive message + received_recipients recipients on <= lines + received_sender sender on <= lines +*rejected_header header contents on reject log +*retry_defer "retry time not reached" + return_path_on_delivery put return path on => and ** lines + sender_on_delivery add sender to => lines +*sender_verify_fail sender verification failures +*size_reject rejection because too big +*skip_delivery delivery skipped in a queue run +*smtp_confirmation SMTP confirmation on => lines + smtp_connection incoming SMTP connections + smtp_incomplete_transaction incomplete SMTP transactions + smtp_mailauth AUTH argument to MAIL commands + smtp_no_mail session with no MAIL commands + smtp_protocol_error SMTP protocol errors + smtp_syntax_error SMTP syntax errors + subject contents of Subject: on <= lines +*tls_certificate_verified certificate verification status +*tls_cipher TLS cipher suite on <= and => lines + tls_peerdn TLS peer DN on <= and => lines + tls_sni TLS SNI on <= lines + unknown_in_list DNS lookup failed in list match + + all all of the above + +See also the slow_lookup_log main configuration option, section 14.4 + +More details on each of these items follows: + + * 8bitmime: This causes Exim to log any 8BITMIME status of received messages, + which may help in tracking down interoperability issues with ancient MTAs + that are not 8bit clean. This is added to the "<=" line, tagged with "M8S=" + and a value of "0", "7" or "8", corresponding to "not given", "7BIT" and + "8BITMIME" respectively. + + * acl_warn_skipped: When an ACL warn statement is skipped because one of its + conditions cannot be evaluated, a log line to this effect is written if + this log selector is set. + + * address_rewrite: This applies both to global rewrites and per-transport + rewrites, but not to rewrites in filters run as an unprivileged user + (because such users cannot access the log). + + * all_parents: Normally only the original and final addresses are logged on + delivery lines; with this selector, intermediate parents are given in + parentheses between them. + + * arguments: This causes Exim to write the arguments with which it was called + to the main log, preceded by the current working directory. This is a + debugging feature, added to make it easier to find out how certain MUAs + call /usr/sbin/sendmail. The logging does not happen if Exim has given up + root privilege because it was called with the -C or -D options. Arguments + that are empty or that contain white space are quoted. Non-printing + characters are shown as escape sequences. This facility cannot log + unrecognized arguments, because the arguments are checked before the + configuration file is read. The only way to log such cases is to interpose + a script such as util/logargs.sh between the caller and Exim. + + * connection_reject: A log entry is written whenever an incoming SMTP + connection is rejected, for whatever reason. + + * delay_delivery: A log entry is written whenever a delivery process is not + started for an incoming message because the load is too high or too many + messages were received on one connection. Logging does not occur if no + delivery process is started because queue_only is set or -odq was used. + + * deliver_time: For each delivery, the amount of real time it has taken to + perform the actual delivery is logged as DT=<time>, for example, "DT=1s". + If millisecond logging is enabled, short times will be shown with greater + precision, eg. "DT=0.304s". + + * delivery_size: For each delivery, the size of message delivered is added to + the "=>" line, tagged with S=. + + * dkim: For message acceptance log lines, when an DKIM signature in the + header verifies successfully a tag of DKIM is added, with one of the + verified domains. + + * dkim_verbose: A log entry is written for each attempted DKIM verification. + + * dnslist_defer: A log entry is written if an attempt to look up a host in a + DNS black list suffers a temporary error. + + * dnssec: For message acceptance and (attempted) delivery log lines, when dns + lookups gave secure results a tag of DS is added. For acceptance this + covers the reverse and forward lookups for host name verification. It does + not cover helo-name verification. For delivery this covers the SRV, MX, A + and/or AAAA lookups. + + * etrn: Every valid ETRN command that is received is logged, before the ACL + is run to determine whether or not it is actually accepted. An invalid ETRN + command, or one received within a message transaction is not logged by this + selector (see smtp_syntax_error and smtp_protocol_error). + + * host_lookup_failed: When a lookup of a host's IP addresses fails to find + any addresses, or when a lookup of an IP address fails to find a host name, + a log line is written. This logging does not apply to direct DNS lookups + when routing email addresses, but it does apply to "byname" lookups. + + * ident_timeout: A log line is written whenever an attempt to connect to a + client's ident port times out. + + * incoming_interface: The interface on which a message was received is added + to the "<=" line as an IP address in square brackets, tagged by I= and + followed by a colon and the port number. The local interface and port are + also added to other SMTP log lines, for example, "SMTP connection from", to + rejection lines, and (despite the name) to outgoing "=>" and "->" lines. + The latter can be disabled by turning off the outgoing_interface option. + + * proxy: The internal (closest to the system running Exim) IP address of the + proxy, tagged by PRX=, on the "<=" line for a message accepted on a proxied + connection or the "=>" line for a message delivered on a proxied + connection. See 58.1 for more information. + + * incoming_port: The remote port number from which a message was received is + added to log entries and Received: header lines, following the IP address + in square brackets, and separated from it by a colon. This is implemented + by changing the value that is put in the $sender_fullhost and + $sender_rcvhost variables. Recording the remote port number has become more + important with the widening use of NAT (see RFC 2505). + + * lost_incoming_connection: A log line is written when an incoming SMTP + connection is unexpectedly dropped. + + * millisec: Timestamps have a period and three decimal places of finer + granularity appended to the seconds value. + + * outgoing_interface: If incoming_interface is turned on, then the interface + on which a message was sent is added to delivery lines as an I= tag + followed by IP address in square brackets. You can disable this by turning + off the outgoing_interface option. + + * outgoing_port: The remote port number is added to delivery log lines (those + containing => tags) following the IP address. The local port is also added + if incoming_interface and outgoing_interface are both enabled. This option + is not included in the default setting, because for most ordinary + configurations, the remote port number is always 25 (the SMTP port), and + the local port is a random ephemeral port. + + * pid: The current process id is added to every log line, in square brackets, + immediately after the time and date. + + * pipelining: A field is added to delivery and accept log lines when the + ESMTP PIPELINING extension was used. The field is a single "L". + + On accept lines, where PIPELINING was offered but not used by the client, + the field has a minus appended. + + * queue_run: The start and end of every queue run are logged. + + * queue_time: The amount of time the message has been in the queue on the + local host is logged as QT=<time> on delivery ("=>") lines, for example, + "QT=3m45s". The clock starts when Exim starts to receive the message, so it + includes reception time as well as the delivery time for the current + address. This means that it may be longer than the difference between the + arrival and delivery log line times, because the arrival log line is not + written until the message has been successfully received. If millisecond + logging is enabled, short times will be shown with greater precision, eg. + "QT=1.578s". + + * queue_time_overall: The amount of time the message has been in the queue on + the local host is logged as QT=<time> on "Completed" lines, for example, + "QT=3m45s". The clock starts when Exim starts to receive the message, so it + includes reception time as well as the total delivery time. + + * receive_time: For each message, the amount of real time it has taken to + perform the reception is logged as RT=<time>, for example, "RT=1s". If + millisecond logging is enabled, short times will be shown with greater + precision, eg. "RT=0.204s". + + * received_recipients: The recipients of a message are listed in the main log + as soon as the message is received. The list appears at the end of the log + line that is written when a message is received, preceded by the word + "for". The addresses are listed after they have been qualified, but before + any rewriting has taken place. Recipients that were discarded by an ACL for + MAIL or RCPT do not appear in the list. + + * received_sender: The unrewritten original sender of a message is added to + the end of the log line that records the message's arrival, after the word + "from" (before the recipients if received_recipients is also set). + + * rejected_header: If a message's header has been received at the time a + rejection is written to the reject log, the complete header is added to the + log. Header logging can be turned off individually for messages that are + rejected by the local_scan() function (see section 45.2). + + * retry_defer: A log line is written if a delivery is deferred because a + retry time has not yet been reached. However, this "retry time not reached" + message is always omitted from individual message logs after the first + delivery attempt. + + * return_path_on_delivery: The return path that is being transmitted with the + message is included in delivery and bounce lines, using the tag P=. This is + omitted if no delivery actually happens, for example, if routing fails, or + if delivery is to /dev/null or to ":blackhole:". + + * sender_on_delivery: The message's sender address is added to every delivery + and bounce line, tagged by F= (for "from"). This is the original sender + that was received with the message; it is not necessarily the same as the + outgoing return path. + + * sender_verify_fail: If this selector is unset, the separate log line that + gives details of a sender verification failure is not written. Log lines + for the rejection of SMTP commands contain just "sender verify failed", so + some detail is lost. + + * size_reject: A log line is written whenever a message is rejected because + it is too big. + + * skip_delivery: A log line is written whenever a message is skipped during a + queue run because it is frozen or because another process is already + delivering it. The message that is written is "spool file is locked". + + * smtp_confirmation: The response to the final "." in the SMTP or LMTP + dialogue for outgoing messages is added to delivery log lines in the form + "C="<text>. A number of MTAs (including Exim) return an identifying string + in this response. + + * smtp_connection: A log line is written whenever an incoming SMTP connection + is established or closed, unless the connection is from a host that matches + hosts_connection_nolog. (In contrast, lost_incoming_connection applies only + when the closure is unexpected.) This applies to connections from local + processes that use -bs as well as to TCP/IP connections. If a connection is + dropped in the middle of a message, a log line is always written, whether + or not this selector is set, but otherwise nothing is written at the start + and end of connections unless this selector is enabled. + + For TCP/IP connections to an Exim daemon, the current number of connections + is included in the log message for each new connection, but note that the + count is reset if the daemon is restarted. Also, because connections are + closed (and the closure is logged) in subprocesses, the count may not + include connections that have been closed but whose termination the daemon + has not yet noticed. Thus, while it is possible to match up the opening and + closing of connections in the log, the value of the logged counts may not + be entirely accurate. + + * smtp_incomplete_transaction: When a mail transaction is aborted by RSET, + QUIT, loss of connection, or otherwise, the incident is logged, and the + message sender plus any accepted recipients are included in the log line. + This can provide evidence of dictionary attacks. + + * smtp_no_mail: A line is written to the main log whenever an accepted SMTP + connection terminates without having issued a MAIL command. This includes + both the case when the connection is dropped, and the case when QUIT is + used. It does not include cases where the connection is rejected right at + the start (by an ACL, or because there are too many connections, or + whatever). These cases already have their own log lines. + + The log line that is written contains the identity of the client in the + usual way, followed by D= and a time, which records the duration of the + connection. If the connection was authenticated, this fact is logged + exactly as it is for an incoming message, with an A= item. If the + connection was encrypted, CV=, DN=, and X= items may appear as they do for + an incoming message, controlled by the same logging options. + + Finally, if any SMTP commands were issued during the connection, a C= item + is added to the line, listing the commands that were used. For example, + + C=EHLO,QUIT + + shows that the client issued QUIT straight after EHLO. If there were fewer + than 20 commands, they are all listed. If there were more than 20 commands, + the last 20 are listed, preceded by "...". However, with the default + setting of 10 for smtp_accept_max_nonmail, the connection will in any case + have been aborted before 20 non-mail commands are processed. + + * smtp_mailauth: A third subfield with the authenticated sender, + colon-separated, is appended to the A= item for a message arrival or + delivery log line, if an AUTH argument to the SMTP MAIL command (see 33.2) + was accepted or used. + + * smtp_protocol_error: A log line is written for every SMTP protocol error + encountered. Exim does not have perfect detection of all protocol errors + because of transmission delays and the use of pipelining. If PIPELINING has + been advertised to a client, an Exim server assumes that the client will + use it, and therefore it does not count "expected" errors (for example, + RCPT received after rejecting MAIL) as protocol errors. + + * smtp_syntax_error: A log line is written for every SMTP syntax error + encountered. An unrecognized command is treated as a syntax error. For an + external connection, the host identity is given; for an internal connection + using -bs the sender identification (normally the calling user) is given. + + * subject: The subject of the message is added to the arrival log line, + preceded by "T=" (T for "topic", since S is already used for "size"). Any + MIME "words" in the subject are decoded. The print_topbitchars option + specifies whether characters with values greater than 127 should be logged + unchanged, or whether they should be rendered as escape sequences. + + * tls_certificate_verified: An extra item is added to <= and => log lines + when TLS is in use. The item is "CV=yes" if the peer's certificate was + verified using a CA trust anchor, "CA=dane" if using a DNS trust anchor, + and "CV=no" if not. + + * tls_cipher: When a message is sent or received over an encrypted + connection, the cipher suite used is added to the log line, preceded by X=. + + * tls_peerdn: When a message is sent or received over an encrypted + connection, and a certificate is supplied by the remote host, the peer DN + is added to the log line, preceded by DN=. + + * tls_sni: When a message is received over an encrypted connection, and the + remote host provided the Server Name Indication extension, the SNI is added + to the log line, preceded by SNI=. + + * unknown_in_list: This setting causes a log entry to be written when the + result of a list match is failure because a DNS lookup failed. + + +52.16 Message log +----------------- + +In addition to the general log files, Exim writes a log file for each message +that it handles. The names of these per-message logs are the message ids, and +they are kept in the msglog sub-directory of the spool directory. Each message +log contains copies of the log lines that apply to the message. This makes it +easier to inspect the status of an individual message without having to search +the main log. A message log is deleted when processing of the message is +complete, unless preserve_message_logs is set, but this should be used only +with great care because they can fill up your disk very quickly. + +On a heavily loaded system, it may be desirable to disable the use of +per-message logs, in order to reduce disk I/O. This can be done by setting the +message_logs option false. + + + +=============================================================================== +53. EXIM UTILITIES + +A number of utility scripts and programs are supplied with Exim and are +described in this chapter. There is also the Exim Monitor, which is covered in +the next chapter. The utilities described here are: + + 53.1 exiwhat list what Exim processes are doing + 53.2 exiqgrep grep the queue + 53.3 exiqsumm summarize the queue + 53.4 exigrep search the main log + 53.5 exipick select messages on various criteria + 53.6 exicyclog cycle (rotate) log files + 53.7 eximstats extract statistics from the log + 53.8 exim_checkaccess check address acceptance from given IP + 53.9 exim_dbmbuild build a DBM file + 53.10 exinext extract retry information + 53.11 exim_dumpdb dump a hints database + 53.11 exim_tidydb clean up a hints database + 53.11 exim_fixdb patch a hints database + 53.15 exim_lock lock a mailbox file + +Another utility that might be of use to sites with many MTAs is Tom Kistner's +exilog. It provides log visualizations across multiple Exim servers. See https: +//duncanthrax.net/exilog/ for details. + + +53.1 Finding out what Exim processes are doing (exiwhat) +-------------------------------------------------------- + +On operating systems that can restart a system call after receiving a signal +(most modern OS), an Exim process responds to the SIGUSR1 signal by writing a +line describing what it is doing to the file exim-process.info in the Exim +spool directory. The exiwhat script sends the signal to all Exim processes it +can find, having first emptied the file. It then waits for one second to allow +the Exim processes to react before displaying the results. In order to run +exiwhat successfully you have to have sufficient privilege to send the signal +to the Exim processes, so it is normally run as root. + +Warning: This is not an efficient process. It is intended for occasional use by +system administrators. It is not sensible, for example, to set up a script that +sends SIGUSR1 signals to Exim processes at short intervals. + +Unfortunately, the ps command that exiwhat uses to find Exim processes varies +in different operating systems. Not only are different options used, but the +format of the output is different. For this reason, there are some system +configuration options that configure exactly how exiwhat works. If it doesn't +seem to be working for you, check the following compile-time options: + +EXIWHAT_PS_CMD the command for running ps +EXIWHAT_PS_ARG the argument for ps +EXIWHAT_EGREP_ARG the argument for egrep to select from ps output +EXIWHAT_KILL_ARG the argument for the kill command + +An example of typical output from exiwhat is + +164 daemon: -q1h, listening on port 25 +10483 running queue: waiting for 0tAycK-0002ij-00 (10492) +10492 delivering 0tAycK-0002ij-00 to mail.ref.example + [10.19.42.42] (editor@ref.example) +10592 handling incoming call from [192.168.243.242] +10628 accepting a local non-SMTP message + +The first number in the output line is the process number. The third line has +been split here, in order to fit it on the page. + + +53.2 Selective queue listing (exiqgrep) +--------------------------------------- + +This utility is a Perl script contributed by Matt Hubbard. It runs + +exim -bpu + +or (in case -a switch is specified) + +exim -bp + +The -C option is used to specify an alternate exim.conf which might contain +alternate exim configuration the queue management might be using. + +to obtain a queue listing, and then greps the output to select messages that +match given criteria. The following selection options are available: + +-f <regex> + + Match the sender address using a case-insensitive search. The field that is + tested is enclosed in angle brackets, so you can test for bounce messages + with + + exiqgrep -f '^<>$' + +-r <regex> + + Match a recipient address using a case-insensitive search. The field that + is tested is not enclosed in angle brackets. + +-s <regex> + + Match against the size field. + +-y <seconds> + + Match messages that are younger than the given time. + +-o <seconds> + + Match messages that are older than the given time. + +-z + + Match only frozen messages. + +-x + + Match only non-frozen messages. + +The following options control the format of the output: + +-c + + Display only the count of matching messages. + +-l + + Long format - display the full message information as output by Exim. This + is the default. + +-i + + Display message ids only. + +-b + + Brief format - one line per message. + +-R + + Display messages in reverse order. + +-a + + Include delivered recipients in queue listing. + +There is one more option, -h, which outputs a list of options. + + +53.3 Summarizing the queue (exiqsumm) +------------------------------------- + +The exiqsumm utility is a Perl script which reads the output of "exim -bp" and +produces a summary of the messages in the queue. Thus, you use it by running a +command such as + +exim -bp | exiqsumm + +The output consists of one line for each domain that has messages waiting for +it, as in the following example: + +3 2322 74m 66m msn.com.example + +Each line lists the number of pending deliveries for a domain, their total +volume, and the length of time that the oldest and the newest messages have +been waiting. Note that the number of pending deliveries is greater than the +number of messages when messages have more than one recipient. + +A summary line is output at the end. By default the output is sorted on the +domain name, but exiqsumm has the options -a and -c, which cause the output to +be sorted by oldest message and by count of messages, respectively. There are +also three options that split the messages for each domain into two or more +subcounts: -b separates bounce messages, -f separates frozen messages, and -s +separates messages according to their sender. + +The output of exim -bp contains the original addresses in the message, so this +also applies to the output from exiqsumm. No domains from addresses generated +by aliasing or forwarding are included (unless the one_time option of the +redirect router has been used to convert them into "top level" addresses). + + +53.4 Extracting specific information from the log (exigrep) +----------------------------------------------------------- + +The exigrep utility is a Perl script that searches one or more main log files +for entries that match a given pattern. When it finds a match, it extracts all +the log entries for the relevant message, not just those that match the +pattern. Thus, exigrep can extract complete log entries for a given message, or +all mail for a given user, or for a given host, for example. The input files +can be in Exim log format or syslog format. If a matching log line is not +associated with a specific message, it is included in exigrep's output without +any additional lines. The usage is: + +exigrep [-t<n>] [-I] [-l] [-M] [-v] <pattern> [<log file>] ... + +If no log filenames are given on the command line, the standard input is read. + +The -t argument specifies a number of seconds. It adds an additional condition +for message selection. Messages that are complete are shown only if they spent +more than <n> seconds in the queue. + +By default, exigrep does case-insensitive matching. The -I option makes it +case-sensitive. This may give a performance improvement when searching large +log files. Without -I, the Perl pattern matches use Perl's "/i" option; with -I +they do not. In both cases it is possible to change the case sensitivity within +the pattern by using "(?i)" or "(?-i)". + +The -l option means "literal", that is, treat all characters in the pattern as +standing for themselves. Otherwise the pattern must be a Perl regular +expression. + +The -v option inverts the matching condition. That is, a line is selected if it +does not match the pattern. + +The -M options means "related messages". exigrep will show messages that are +generated as a result/response to a message that exigrep matched normally. + +Example of -M: user_a sends a message to user_b, which generates a bounce back +to user_b. If exigrep is used to search for "user_a", only the first message +will be displayed. But if exigrep is used to search for "user_b", the first and +the second (bounce) message will be displayed. Using -M with exigrep when +searching for "user_a" will show both messages since the bounce is "related" to +or a "result" of the first message that was found by the search term. + +If the location of a zcat command is known from the definition of ZCAT_COMMAND +in Local/Makefile, exigrep automatically passes any file whose name ends in +COMPRESS_SUFFIX through zcat as it searches it. If the ZCAT_COMMAND is not +executable, exigrep tries to use autodetection of some well known compression +extensions. + + +53.5 Selecting messages by various criteria (exipick) +----------------------------------------------------- + +John Jetmore's exipick utility is included in the Exim distribution. It lists +messages from the queue according to a variety of criteria. For details of +exipick's facilities, run exipick with the --help option. + + +53.6 Cycling log files (exicyclog) +---------------------------------- + +The exicyclog script can be used to cycle (rotate) mainlog and rejectlog files. +This is not necessary if only syslog is being used, or if you are using log +files with datestamps in their names (see section 52.3). Some operating systems +have their own standard mechanisms for log cycling, and these can be used +instead of exicyclog if preferred. There are two command line options for +exicyclog: + + * -k <count> specifies the number of log files to keep, overriding the + default that is set when Exim is built. The default default is 10. + + * -l <path> specifies the log file path, in the same format as Exim's + log_file_path option (for example, "/var/log/exim_%slog"), again overriding + the script's default, which is to find the setting from Exim's + configuration. + +Each time exicyclog is run the filenames get "shuffled down" by one. If the +main log filename is mainlog (the default) then when exicyclog is run mainlog +becomes mainlog.01, the previous mainlog.01 becomes mainlog.02 and so on, up to +the limit that is set in the script or by the -k option. Log files whose +numbers exceed the limit are discarded. Reject logs are handled similarly. + +If the limit is greater than 99, the script uses 3-digit numbers such as +mainlog.001, mainlog.002, etc. If you change from a number less than 99 to one +that is greater, or vice versa, you will have to fix the names of any existing +log files. + +If no mainlog file exists, the script does nothing. Files that "drop off" the +end are deleted. All files with numbers greater than 01 are compressed, using a +compression command which is configured by the COMPRESS_COMMAND setting in +Local/Makefile. It is usual to run exicyclog daily from a root crontab entry of +the form + +1 0 * * * su exim -c /usr/exim/bin/exicyclog + +assuming you have used the name "exim" for the Exim user. You can run exicyclog +as root if you wish, but there is no need. + + +53.7 Mail statistics (eximstats) +-------------------------------- + +A Perl script called eximstats is provided for extracting statistical +information from log files. The output is either plain text, or HTML. + +The eximstats script has been hacked about quite a bit over time. The latest +version is the result of some extensive revision by Steve Campbell. A lot of +information is given by default, but there are options for suppressing various +parts of it. Following any options, the arguments to the script are a list of +files, which should be main log files. For example: + +eximstats -nr /var/spool/exim/log/mainlog.01 + +By default, eximstats extracts information about the number and volume of +messages received from or delivered to various hosts. The information is sorted +both by message count and by volume, and the top fifty hosts in each category +are listed on the standard output. Similar information, based on email +addresses or domains instead of hosts can be requested by means of various +options. For messages delivered and received locally, similar statistics are +also produced per user. + +The output also includes total counts and statistics about delivery errors, and +histograms showing the number of messages received and deliveries made in each +hour of the day. A delivery with more than one address in its envelope (for +example, an SMTP transaction with more than one RCPT command) is counted as a +single delivery by eximstats. + +Though normally more deliveries than receipts are reported (as messages may +have multiple recipients), it is possible for eximstats to report more messages +received than delivered, even though the queue is empty at the start and end of +the period in question. If an incoming message contains no valid recipients, no +deliveries are recorded for it. A bounce message is handled as an entirely +separate message. + +eximstats always outputs a grand total summary giving the volume and number of +messages received and deliveries made, and the number of hosts involved in each +case. It also outputs the number of messages that were delayed (that is, not +completely delivered at the first attempt), and the number that had at least +one address that failed. + +The remainder of the output is in sections that can be independently disabled +or modified by various options. It consists of a summary of deliveries by +transport, histograms of messages received and delivered per time interval +(default per hour), information about the time messages spent in the queue, a +list of relayed messages, lists of the top fifty sending hosts, local senders, +destination hosts, and destination local users by count and by volume, and a +list of delivery errors that occurred. + +The relay information lists messages that were actually relayed, that is, they +came from a remote host and were directly delivered to some other remote host, +without being processed (for example, for aliasing or forwarding) locally. + +There are quite a few options for eximstats to control exactly what it outputs. +These are documented in the Perl script itself, and can be extracted by running +the command perldoc on the script. For example: + +perldoc /usr/exim/bin/eximstats + + +53.8 Checking access policy (exim_checkaccess) +---------------------------------------------- + +The -bh command line argument allows you to run a fake SMTP session with +debugging output, in order to check what Exim is doing when it is applying +policy controls to incoming SMTP mail. However, not everybody is sufficiently +familiar with the SMTP protocol to be able to make full use of -bh, and +sometimes you just want to answer the question "Does this address have access?" +without bothering with any further details. + +The exim_checkaccess utility is a "packaged" version of -bh. It takes two +arguments, an IP address and an email address: + +exim_checkaccess 10.9.8.7 A.User@a.domain.example + +The utility runs a call to Exim with the -bh option, to test whether the given +email address would be accepted in a RCPT command in a TCP/IP connection from +the host with the given IP address. The output of the utility is either the +word "accepted", or the SMTP error response, for example: + +Rejected: +550 Relay not permitted + +When running this test, the utility uses "<>" as the envelope sender address +for the MAIL command, but you can change this by providing additional options. +These are passed directly to the Exim command. For example, to specify that the +test is to be run with the sender address himself@there.example you can use: + +exim_checkaccess 10.9.8.7 A.User@a.domain.example \ + -f himself@there.example + +Note that these additional Exim command line items must be given after the two +mandatory arguments. + +Because the exim_checkaccess uses -bh, it does not perform callouts while +running its checks. You can run checks that include callouts by using -bhc, but +this is not yet available in a "packaged" form. + + +53.9 Making DBM files (exim_dbmbuild) +------------------------------------- + +The exim_dbmbuild program reads an input file containing keys and data in the +format used by the lsearch lookup (see section 9.3). It writes a DBM file using +the lower-cased alias names as keys and the remainder of the information as +data. The lower-casing can be prevented by calling the program with the -nolc +option. + +A terminating zero is included as part of the key string. This is expected by +the dbm lookup type. However, if the option -nozero is given, exim_dbmbuild +creates files without terminating zeroes in either the key strings or the data +strings. The dbmnz lookup type can be used with such files. + +The program requires two arguments: the name of the input file (which can be a +single hyphen to indicate the standard input), and the name of the output file. +It creates the output under a temporary name, and then renames it if all went +well. + +If the native DB interface is in use (USE_DB is set in a compile-time +configuration file - this is common in free versions of Unix) the two filenames +must be different, because in this mode the Berkeley DB functions create a +single output file using exactly the name given. For example, + +exim_dbmbuild /etc/aliases /etc/aliases.db + +reads the system alias file and creates a DBM version of it in /etc/aliases.db. + +In systems that use the ndbm routines (mostly proprietary versions of Unix), +two files are used, with the suffixes .dir and .pag. In this environment, the +suffixes are added to the second argument of exim_dbmbuild, so it can be the +same as the first. This is also the case when the Berkeley functions are used +in compatibility mode (though this is not recommended), because in that case it +adds a .db suffix to the filename. + +If a duplicate key is encountered, the program outputs a warning, and when it +finishes, its return code is 1 rather than zero, unless the -noduperr option is +used. By default, only the first of a set of duplicates is used - this makes it +compatible with lsearch lookups. There is an option -lastdup which causes it to +use the data for the last duplicate instead. There is also an option -nowarn, +which stops it listing duplicate keys to stderr. For other errors, where it +doesn't actually make a new file, the return code is 2. + + +53.10 Finding individual retry times (exinext) +---------------------------------------------- + +A utility called exinext (mostly a Perl script) provides the ability to fish +specific information out of the retry database. Given a mail domain (or a +complete address), it looks up the hosts for that domain, and outputs any retry +information for the hosts or for the domain. At present, the retry information +is obtained by running exim_dumpdb (see below) and post-processing the output. +For example: + +$ exinext piglet@milne.fict.example +kanga.milne.example:192.168.8.1 error 146: Connection refused + first failed: 21-Feb-1996 14:57:34 + last tried: 21-Feb-1996 14:57:34 + next try at: 21-Feb-1996 15:02:34 +roo.milne.example:192.168.8.3 error 146: Connection refused + first failed: 20-Jan-1996 13:12:08 + last tried: 21-Feb-1996 11:42:03 + next try at: 21-Feb-1996 19:42:03 + past final cutoff time + +You can also give exinext a local part, without a domain, and it will give any +retry information for that local part in your default domain. A message id can +be used to obtain retry information pertaining to a specific message. This +exists only when an attempt to deliver a message to a remote host suffers a +message-specific error (see section 48.2). exinext is not particularly +efficient, but then it is not expected to be run very often. + +The exinext utility calls Exim to find out information such as the location of +the spool directory. The utility has -C and -D options, which are passed on to +the exim commands. The first specifies an alternate Exim configuration file, +and the second sets macros for use within the configuration file. These +features are mainly to help in testing, but might also be useful in +environments where more than one configuration file is in use. + + +53.11 Hints database maintenance +-------------------------------- + +Three utility programs are provided for maintaining the DBM files that Exim +uses to contain its delivery hint information. Each program requires two +arguments. The first specifies the name of Exim's spool directory, and the +second is the name of the database it is to operate on. These are as follows: + + * retry: the database of retry information + + * wait-<transport name>: databases of information about messages waiting for + remote hosts + + * callout: the callout cache + + * ratelimit: the data for implementing the ratelimit ACL condition + + * misc: other hints data + +The misc database is used for + + * Serializing ETRN runs (when smtp_etrn_serialize is set) + + * Serializing delivery to a specific host (when serialize_hosts is set in an + smtp transport) + + * Limiting the concurrency of specific transports (when max_parallel is set + in a transport) + + +53.12 exim_dumpdb +----------------- + +The entire contents of a database are written to the standard output by the +exim_dumpdb program, which has no options or arguments other than the spool and +database names. For example, to dump the retry database: + +exim_dumpdb /var/spool/exim retry + +Two lines of output are produced for each entry: + +T:mail.ref.example:192.168.242.242 146 77 Connection refused +31-Oct-1995 12:00:12 02-Nov-1995 12:21:39 02-Nov-1995 20:21:39 * + +The first item on the first line is the key of the record. It starts with one +of the letters R, or T, depending on whether it refers to a routing or +transport retry. For a local delivery, the next part is the local address; for +a remote delivery it is the name of the remote host, followed by its failing IP +address (unless retry_include_ip_address is set false on the smtp transport). +If the remote port is not the standard one (port 25), it is added to the IP +address. Then there follows an error code, an additional error code, and a +textual description of the error. + +The three times on the second line are the time of first failure, the time of +the last delivery attempt, and the computed time for the next attempt. The line +ends with an asterisk if the cutoff time for the last retry rule has been +exceeded. + +Each output line from exim_dumpdb for the wait-xxx databases consists of a host +name followed by a list of ids for messages that are or were waiting to be +delivered to that host. If there are a very large number for any one host, +continuation records, with a sequence number added to the host name, may be +seen. The data in these records is often out of date, because a message may be +routed to several alternative hosts, and Exim makes no effort to keep +cross-references. + + +53.13 exim_tidydb +----------------- + +The exim_tidydb utility program is used to tidy up the contents of a hints +database. If run with no options, it removes all records that are more than 30 +days old. The age is calculated from the date and time that the record was last +updated. Note that, in the case of the retry database, it is not the time since +the first delivery failure. Information about a host that has been down for +more than 30 days will remain in the database, provided that the record is +updated sufficiently often. + +The cutoff date can be altered by means of the -t option, which must be +followed by a time. For example, to remove all records older than a week from +the retry database: + +exim_tidydb -t 7d /var/spool/exim retry + +Both the wait-xxx and retry databases contain items that involve message ids. +In the former these appear as data in records keyed by host - they were +messages that were waiting for that host - and in the latter they are the keys +for retry information for messages that have suffered certain types of error. +When exim_tidydb is run, a check is made to ensure that message ids in database +records are those of messages that are still on the queue. Message ids for +messages that no longer exist are removed from wait-xxx records, and if this +leaves any records empty, they are deleted. For the retry database, records +whose keys are non-existent message ids are removed. The exim_tidydb utility +outputs comments on the standard output whenever it removes information from +the database. + +Certain records are automatically removed by Exim when they are no longer +needed, but others are not. For example, if all the MX hosts for a domain are +down, a retry record is created for each one. If the primary MX host comes back +first, its record is removed when Exim successfully delivers to it, but the +records for the others remain because Exim has not tried to use those hosts. + +It is important, therefore, to run exim_tidydb periodically on all the hints +databases. You should do this at a quiet time of day, because it requires a +database to be locked (and therefore inaccessible to Exim) while it does its +work. Removing records from a DBM file does not normally make the file smaller, +but all the common DBM libraries are able to re-use the space that is released. +After an initial phase of increasing in size, the databases normally reach a +point at which they no longer get any bigger, as long as they are regularly +tidied. + +Warning: If you never run exim_tidydb, the space used by the hints databases is +likely to keep on increasing. + + +53.14 exim_fixdb +---------------- + +The exim_fixdb program is a utility for interactively modifying databases. Its +main use is for testing Exim, but it might also be occasionally useful for +getting round problems in a live system. It has no options, and its interface +is somewhat crude. On entry, it prompts for input with a right angle-bracket. A +key of a database record can then be entered, and the data for that record is +displayed. + +If "d" is typed at the next prompt, the entire record is deleted. For all +except the retry database, that is the only operation that can be carried out. +For the retry database, each field is output preceded by a number, and data for +individual fields can be changed by typing the field number followed by new +data, for example: + +> 4 951102:1000 + +resets the time of the next delivery attempt. Time values are given as a +sequence of digit pairs for year, month, day, hour, and minute. Colons can be +used as optional separators. + + +53.15 Mailbox maintenance (exim_lock) +------------------------------------- + +The exim_lock utility locks a mailbox file using the same algorithm as Exim. +For a discussion of locking issues, see section 26.3. Exim_lock can be used to +prevent any modification of a mailbox by Exim or a user agent while +investigating a problem. The utility requires the name of the file as its first +argument. If the locking is successful, the second argument is run as a command +(using C's system() function); if there is no second argument, the value of the +SHELL environment variable is used; if this is unset or empty, /bin/sh is run. +When the command finishes, the mailbox is unlocked and the utility ends. The +following options are available: + +-fcntl + + Use fcntl() locking on the open mailbox. + +-flock + + Use flock() locking on the open mailbox, provided the operating system + supports it. + +-interval + + This must be followed by a number, which is a number of seconds; it sets + the interval to sleep between retries (default 3). + +-lockfile + + Create a lock file before opening the mailbox. + +-mbx + + Lock the mailbox using MBX rules. + +-q + + Suppress verification output. + +-retries + + This must be followed by a number; it sets the number of times to try to + get the lock (default 10). + +-restore_time + + This option causes exim_lock to restore the modified and read times to the + locked file before exiting. This allows you to access a locked mailbox (for + example, to take a backup copy) without disturbing the times that the user + subsequently sees. + +-timeout + + This must be followed by a number, which is a number of seconds; it sets a + timeout to be used with a blocking fcntl() lock. If it is not set (the + default), a non-blocking call is used. + +-v + + Generate verbose output. + +If none of -fcntl, -flock, -lockfile or -mbx are given, the default is to +create a lock file and also to use fcntl() locking on the mailbox, which is the +same as Exim's default. The use of -flock or -fcntl requires that the file be +writeable; the use of -lockfile requires that the directory containing the file +be writeable. Locking by lock file does not last forever; Exim assumes that a +lock file is expired if it is more than 30 minutes old. + +The -mbx option can be used with either or both of -fcntl or -flock. It assumes +-fcntl by default. MBX locking causes a shared lock to be taken out on the open +mailbox, and an exclusive lock on the file /tmp/.n.m where n and m are the +device number and inode number of the mailbox file. When the locking is +released, if an exclusive lock can be obtained for the mailbox, the file in / +tmp is deleted. + +The default output contains verification of the locking that takes place. The +-v option causes some additional information to be given. The -q option +suppresses all output except error messages. + +A command such as + +exim_lock /var/spool/mail/spqr + +runs an interactive shell while the file is locked, whereas + +exim_lock -q /var/spool/mail/spqr <<End +<some commands> +End + +runs a specific non-interactive sequence of commands while the file is locked, +suppressing all verification output. A single command can be run by a command +such as + +exim_lock -q /var/spool/mail/spqr \ + "cp /var/spool/mail/spqr /some/where" + +Note that if a command is supplied, it must be entirely contained within the +second argument - hence the quotes. + + + +=============================================================================== +54. THE EXIM MONITOR + +The Exim monitor is an application which displays in an X window information +about the state of Exim's queue and what Exim is doing. An admin user can +perform certain operations on messages from this GUI interface; however all +such facilities are also available from the command line, and indeed, the +monitor itself makes use of the command line to perform any actions requested. + + +54.1 Running the monitor +------------------------ + +The monitor is started by running the script called eximon. This is a shell +script that sets up a number of environment variables, and then runs the binary +called eximon.bin. The default appearance of the monitor window can be changed +by editing the Local/eximon.conf file created by editing exim_monitor/EDITME. +Comments in that file describe what the various parameters are for. + +The parameters that get built into the eximon script can be overridden for a +particular invocation by setting up environment variables of the same names, +preceded by "EXIMON_". For example, a shell command such as + +EXIMON_LOG_DEPTH=400 eximon + +(in a Bourne-compatible shell) runs eximon with an overriding setting of the +LOG_DEPTH parameter. If EXIMON_LOG_FILE_PATH is set in the environment, it +overrides the Exim log file configuration. This makes it possible to have +eximon tailing log data that is written to syslog, provided that MAIL.INFO +syslog messages are routed to a file on the local host. + +X resources can be used to change the appearance of the window in the normal +way. For example, a resource setting of the form + +Eximon*background: gray94 + +changes the colour of the background to light grey rather than white. The +stripcharts are drawn with both the data lines and the reference lines in +black. This means that the reference lines are not visible when on top of the +data. However, their colour can be changed by setting a resource called +"highlight" (an odd name, but that's what the Athena stripchart widget uses). +For example, if your X server is running Unix, you could set up lighter +reference lines in the stripcharts by obeying + +xrdb -merge <<End +Eximon*highlight: gray +End + +In order to see the contents of messages in the queue, and to operate on them, +eximon must either be run as root or by an admin user. + +The command-line parameters of eximon are passed to eximon.bin and may contain +X11 resource parameters interpreted by the X11 library. In addition, if the +first parameter starts with the string "gdb" then it is removed and the binary +is invoked under gdb (the parameter is used as the gdb command-name, so +versioned variants of gdb can be invoked). + +The monitor's window is divided into three parts. The first contains one or +more stripcharts and two action buttons, the second contains a "tail" of the +main log file, and the third is a display of the queue of messages awaiting +delivery, with two more action buttons. The following sections describe these +different parts of the display. + + +54.2 The stripcharts +-------------------- + +The first stripchart is always a count of messages in the queue. Its name can +be configured by setting QUEUE_STRIPCHART_NAME in the Local/eximon.conf file. +The remaining stripcharts are defined in the configuration script by regular +expression matches on log file entries, making it possible to display, for +example, counts of messages delivered to certain hosts or using certain +transports. The supplied defaults display counts of received and delivered +messages, and of local and SMTP deliveries. The default period between +stripchart updates is one minute; this can be adjusted by a parameter in the +Local/eximon.conf file. + +The stripchart displays rescale themselves automatically as the value they are +displaying changes. There are always 10 horizontal lines in each chart; the +title string indicates the value of each division when it is greater than one. +For example, "x2" means that each division represents a value of 2. + +It is also possible to have a stripchart which shows the percentage fullness of +a particular disk partition, which is useful when local deliveries are confined +to a single partition. + +This relies on the availability of the statvfs() function or equivalent in the +operating system. Most, but not all versions of Unix that support Exim have +this. For this particular stripchart, the top of the chart always represents +100%, and the scale is given as "x10%". This chart is configured by setting +SIZE_STRIPCHART and (optionally) SIZE_STRIPCHART_NAME in the Local/eximon.conf +file. + + +54.3 Main action buttons +------------------------ + +Below the stripcharts there is an action button for quitting the monitor. Next +to this is another button marked "Size". They are placed here so that shrinking +the window to its default minimum size leaves just the queue count stripchart +and these two buttons visible. Pressing the "Size" button causes the window to +expand to its maximum size, unless it is already at the maximum, in which case +it is reduced to its minimum. + +When expanding to the maximum, if the window cannot be fully seen where it +currently is, it is moved back to where it was the last time it was at full +size. When it is expanding from its minimum size, the old position is +remembered, and next time it is reduced to the minimum it is moved back there. + +The idea is that you can keep a reduced window just showing one or two +stripcharts at a convenient place on your screen, easily expand it to show the +full window when required, and just as easily put it back to what it was. The +idea is copied from what the twm window manager does for its f.fullzoom action. +The minimum size of the window can be changed by setting the MIN_HEIGHT and +MIN_WIDTH values in Local/eximon.conf. + +Normally, the monitor starts up with the window at its full size, but it can be +built so that it starts up with the window at its smallest size, by setting +START_SMALL=yes in Local/eximon.conf. + + +54.4 The log display +-------------------- + +The second section of the window is an area in which a display of the tail of +the main log is maintained. To save space on the screen, the timestamp on each +log line is shortened by removing the date and, if log_timezone is set, the +timezone. The log tail is not available when the only destination for logging +data is syslog, unless the syslog lines are routed to a local file whose name +is passed to eximon via the EXIMON_LOG_FILE_PATH environment variable. + +The log sub-window has a scroll bar at its lefthand side which can be used to +move back to look at earlier text, and the up and down arrow keys also have a +scrolling effect. The amount of log that is kept depends on the setting of +LOG_BUFFER in Local/eximon.conf, which specifies the amount of memory to use. +When this is full, the earlier 50% of data is discarded - this is much more +efficient than throwing it away line by line. The sub-window also has a +horizontal scroll bar for accessing the ends of long log lines. This is the +only means of horizontal scrolling; the right and left arrow keys are not +available. Text can be cut from this part of the window using the mouse in the +normal way. The size of this subwindow is controlled by parameters in the +configuration file Local/eximon.conf. + +Searches of the text in the log window can be carried out by means of the ^R +and ^S keystrokes, which default to a reverse and a forward search, +respectively. The search covers only the text that is displayed in the window. +It cannot go further back up the log. + +The point from which the search starts is indicated by a caret marker. This is +normally at the end of the text in the window, but can be positioned explicitly +by pointing and clicking with the left mouse button, and is moved automatically +by a successful search. If new text arrives in the window when it is scrolled +back, the caret remains where it is, but if the window is not scrolled back, +the caret is moved to the end of the new text. + +Pressing ^R or ^S pops up a window into which the search text can be typed. +There are buttons for selecting forward or reverse searching, for carrying out +the search, and for cancelling. If the "Search" button is pressed, the search +happens and the window remains so that further searches can be done. If the +"Return" key is pressed, a single search is done and the window is closed. If ^ +C is typed the search is cancelled. + +The searching facility is implemented using the facilities of the Athena text +widget. By default this pops up a window containing both "search" and "replace" +options. In order to suppress the unwanted "replace" portion for eximon, a +modified version of the TextPop widget is distributed with Exim. However, the +linkers in BSDI and HP-UX seem unable to handle an externally provided version +of TextPop when the remaining parts of the text widget come from the standard +libraries. The compile-time option EXIMON_TEXTPOP can be unset to cut out the +modified TextPop, making it possible to build Eximon on these systems, at the +expense of having unwanted items in the search popup window. + + +54.5 The queue display +---------------------- + +The bottom section of the monitor window contains a list of all messages that +are in the queue, which includes those currently being received or delivered, +as well as those awaiting delivery. The size of this subwindow is controlled by +parameters in the configuration file Local/eximon.conf, and the frequency at +which it is updated is controlled by another parameter in the same file - the +default is 5 minutes, since queue scans can be quite expensive. However, there +is an "Update" action button just above the display which can be used to force +an update of the queue display at any time. + +When a host is down for some time, a lot of pending mail can build up for it, +and this can make it hard to deal with other messages in the queue. To help +with this situation there is a button next to "Update" called "Hide". If +pressed, a dialogue box called "Hide addresses ending with" is put up. If you +type anything in here and press "Return", the text is added to a chain of such +texts, and if every undelivered address in a message matches at least one of +the texts, the message is not displayed. + +If there is an address that does not match any of the texts, all the addresses +are displayed as normal. The matching happens on the ends of addresses so, for +example, cam.ac.uk specifies all addresses in Cambridge, while +xxx@foo.com.example specifies just one specific address. When any hiding has +been set up, a button called "Unhide" is displayed. If pressed, it cancels all +hiding. Also, to ensure that hidden messages do not get forgotten, a hide +request is automatically cancelled after one hour. + +While the dialogue box is displayed, you can't press any buttons or do anything +else to the monitor window. For this reason, if you want to cut text from the +queue display to use in the dialogue box, you have to do the cutting before +pressing the "Hide" button. + +The queue display contains, for each unhidden queued message, the length of +time it has been in the queue, the size of the message, the message id, the +message sender, and the first undelivered recipient, all on one line. If it is +a bounce message, the sender is shown as "<>". If there is more than one +recipient to which the message has not yet been delivered, subsequent ones are +listed on additional lines, up to a maximum configured number, following which +an ellipsis is displayed. Recipients that have already received the message are +not shown. + +If a message is frozen, an asterisk is displayed at the left-hand side. + +The queue display has a vertical scroll bar, and can also be scrolled by means +of the arrow keys. Text can be cut from it using the mouse in the normal way. +The text searching facilities, as described above for the log window, are also +available, but the caret is always moved to the end of the text when the queue +display is updated. + + +54.6 The queue menu +------------------- + +If the shift key is held down and the left button is clicked when the mouse +pointer is over the text for any message, an action menu pops up, and the first +line of the queue display for the message is highlighted. This does not affect +any selected text. + +If you want to use some other event for popping up the menu, you can set the +MENU_EVENT parameter in Local/eximon.conf to change the default, or set +EXIMON_MENU_EVENT in the environment before starting the monitor. The value set +in this parameter is a standard X event description. For example, to run eximon +using ctrl rather than shift you could use + +EXIMON_MENU_EVENT='Ctrl<Btn1Down>' eximon + +The title of the menu is the message id, and it contains entries which act as +follows: + + * message log: The contents of the message log for the message are displayed + in a new text window. + + * headers: Information from the spool file that contains the envelope + information and headers is displayed in a new text window. See chapter 56 + for a description of the format of spool files. + + * body: The contents of the spool file containing the body of the message are + displayed in a new text window. There is a default limit of 20,000 bytes to + the amount of data displayed. This can be changed by setting the BODY_MAX + option at compile time, or the EXIMON_BODY_MAX option at runtime. + + * deliver message: A call to Exim is made using the -M option to request + delivery of the message. This causes an automatic thaw if the message is + frozen. The -v option is also set, and the output from Exim is displayed in + a new text window. The delivery is run in a separate process, to avoid + holding up the monitor while the delivery proceeds. + + * freeze message: A call to Exim is made using the -Mf option to request that + the message be frozen. + + * thaw message: A call to Exim is made using the -Mt option to request that + the message be thawed. + + * give up on msg: A call to Exim is made using the -Mg option to request that + Exim gives up trying to deliver the message. A bounce message is generated + for any remaining undelivered addresses. + + * remove message: A call to Exim is made using the -Mrm option to request + that the message be deleted from the system without generating a bounce + message. + + * add recipient: A dialog box is displayed into which a recipient address can + be typed. If the address is not qualified and the QUALIFY_DOMAIN parameter + is set in Local/eximon.conf, the address is qualified with that domain. + Otherwise it must be entered as a fully qualified address. Pressing RETURN + causes a call to Exim to be made using the -Mar option to request that an + additional recipient be added to the message, unless the entry box is + empty, in which case no action is taken. + + * mark delivered: A dialog box is displayed into which a recipient address + can be typed. If the address is not qualified and the QUALIFY_DOMAIN + parameter is set in Local/eximon.conf, the address is qualified with that + domain. Otherwise it must be entered as a fully qualified address. Pressing + RETURN causes a call to Exim to be made using the -Mmd option to mark the + given recipient address as already delivered, unless the entry box is + empty, in which case no action is taken. + + * mark all delivered: A call to Exim is made using the -Mmad option to mark + all recipient addresses as already delivered. + + * edit sender: A dialog box is displayed initialized with the current + sender's address. Pressing RETURN causes a call to Exim to be made using + the -Mes option to replace the sender address, unless the entry box is + empty, in which case no action is taken. If you want to set an empty sender + (as in bounce messages), you must specify it as "<>". Otherwise, if the + address is not qualified and the QUALIFY_DOMAIN parameter is set in Local/ + eximon.conf, the address is qualified with that domain. + +When a delivery is forced, a window showing the -v output is displayed. In +other cases when a call to Exim is made, if there is any output from Exim (in +particular, if the command fails) a window containing the command and the +output is displayed. Otherwise, the results of the action are normally apparent +from the log and queue displays. However, if you set ACTION_OUTPUT=yes in Local +/eximon.conf, a window showing the Exim command is always opened, even if no +output is generated. + +The queue display is automatically updated for actions such as freezing and +thawing, unless ACTION_QUEUE_UPDATE=no has been set in Local/eximon.conf. In +this case the "Update" button has to be used to force an update of the display +after one of these actions. + +In any text window that is displayed as result of a menu action, the normal +cut-and-paste facility is available, and searching can be carried out using ^R +and ^S, as described above for the log tail window. + + + +=============================================================================== +55. SECURITY CONSIDERATIONS + +This chapter discusses a number of issues concerned with security, some of +which are also covered in other parts of this manual. + +For reasons that this author does not understand, some people have promoted +Exim as a "particularly secure" mailer. Perhaps it is because of the existence +of this chapter in the documentation. However, the intent of the chapter is +simply to describe the way Exim works in relation to certain security concerns, +not to make any specific claims about the effectiveness of its security as +compared with other MTAs. + +What follows is a description of the way Exim is supposed to be. Best efforts +have been made to try to ensure that the code agrees with the theory, but an +absence of bugs can never be guaranteed. Any that are reported will get fixed +as soon as possible. + + +55.1 Building a more "hardened" Exim +------------------------------------ + +There are a number of build-time options that can be set in Local/Makefile to +create Exim binaries that are "harder" to attack, in particular by a rogue Exim +administrator who does not have the root password, or by someone who has +penetrated the Exim (but not the root) account. These options are as follows: + + * ALT_CONFIG_PREFIX can be set to a string that is required to match the + start of any filenames used with the -C option. When it is set, these + filenames are also not allowed to contain the sequence "/../". (However, if + the value of the -C option is identical to the value of CONFIGURE_FILE in + Local/Makefile, Exim ignores -C and proceeds as usual.) There is no default + setting for ALT_CONFIG_PREFIX. + + If the permitted configuration files are confined to a directory to which + only root has access, this guards against someone who has broken into the + Exim account from running a privileged Exim with an arbitrary configuration + file, and using it to break into other accounts. + + * If a non-trusted configuration file (i.e. not the default configuration + file or one which is trusted by virtue of being listed in the + TRUSTED_CONFIG_LIST file) is specified with -C, or if macros are given with + -D (but see the next item), then root privilege is retained only if the + caller of Exim is root. This locks out the possibility of testing a + configuration using -C right through message reception and delivery, even + if the caller is root. The reception works, but by that time, Exim is + running as the Exim user, so when it re-execs to regain privilege for the + delivery, the use of -C causes privilege to be lost. However, root can test + reception and delivery using two separate commands. + + * The WHITELIST_D_MACROS build option declares some macros to be safe to + override with -D if the real uid is one of root, the Exim run-time user or + the CONFIGURE_OWNER, if defined. The potential impact of this option is + limited by requiring the run-time value supplied to -D to match a regex + that errs on the restrictive side. Requiring build-time selection of safe + macros is onerous but this option is intended solely as a transition + mechanism to permit previously-working configurations to continue to work + after release 4.73. + + * If DISABLE_D_OPTION is defined, the use of the -D command line option is + disabled. + + * FIXED_NEVER_USERS can be set to a colon-separated list of users that are + never to be used for any deliveries. This is like the never_users runtime + option, but it cannot be overridden; the runtime option adds additional + users to the list. The default setting is "root"; this prevents a non-root + user who is permitted to modify the runtime file from using Exim as a way + to get root. + + +55.2 Root privilege +------------------- + +The Exim binary is normally setuid to root, which means that it gains root +privilege (runs as root) when it starts execution. In some special cases (for +example, when the daemon is not in use and there are no local deliveries), it +may be possible to run Exim setuid to some user other than root. This is +discussed in the next section. However, in most installations, root privilege +is required for two things: + + * To set up a socket connected to the standard SMTP port (25) when + initialising the listening daemon. If Exim is run from inetd, this + privileged action is not required. + + * To be able to change uid and gid in order to read users' .forward files and + perform local deliveries as the receiving user or as specified in the + configuration. + +It is not necessary to be root to do any of the other things Exim does, such as +receiving messages and delivering them externally over SMTP, and it is +obviously more secure if Exim does not run as root except when necessary. For +this reason, a user and group for Exim to use must be defined in Local/Makefile +. These are known as "the Exim user" and "the Exim group". Their values can be +changed by the runtime configuration, though this is not recommended. Often a +user called exim is used, but some sites use mail or another user name +altogether. + +Exim uses setuid() whenever it gives up root privilege. This is a permanent +abdication; the process cannot regain root afterwards. Prior to release 4.00, +seteuid() was used in some circumstances, but this is no longer the case. + +After a new Exim process has interpreted its command line options, it changes +uid and gid in the following cases: + + * If the -C option is used to specify an alternate configuration file, or if + the -D option is used to define macro values for the configuration, and the + calling process is not running as root, the uid and gid are changed to + those of the calling process. However, if DISABLE_D_OPTION is defined in + Local/Makefile, the -D option may not be used at all. If WHITELIST_D_MACROS + is defined in Local/Makefile, then some macro values can be supplied if the + calling process is running as root, the Exim run-time user or + CONFIGURE_OWNER, if defined. + + * If the expansion test option (-be) or one of the filter testing options ( + -bf or -bF) are used, the uid and gid are changed to those of the calling + process. + + * If the process is not a daemon process or a queue runner process or a + delivery process or a process for testing address routing (started with -bt + ), the uid and gid are changed to the Exim user and group. This means that + Exim always runs under its own uid and gid when receiving messages. This + also applies when testing address verification (the -bv option) and testing + incoming message policy controls (the -bh option). + + * For a daemon, queue runner, delivery, or address testing process, the uid + remains as root at this stage, but the gid is changed to the Exim group. + +The processes that initially retain root privilege behave as follows: + + * A daemon process changes the gid to the Exim group and the uid to the Exim + user after setting up one or more listening sockets. The initgroups() + function is called, so that if the Exim user is in any additional groups, + they will be used during message reception. + + * A queue runner process retains root privilege throughout its execution. Its + job is to fork a controlled sequence of delivery processes. + + * A delivery process retains root privilege throughout most of its execution, + but any actual deliveries (that is, the transports themselves) are run in + subprocesses which always change to a non-root uid and gid. For local + deliveries this is typically the uid and gid of the owner of the mailbox; + for remote deliveries, the Exim uid and gid are used. Once all the delivery + subprocesses have been run, a delivery process changes to the Exim uid and + gid while doing post-delivery tidying up such as updating the retry + database and generating bounce and warning messages. + + While the recipient addresses in a message are being routed, the delivery + process runs as root. However, if a user's filter file has to be processed, + this is done in a subprocess that runs under the individual user's uid and + gid. A system filter is run as root unless system_filter_user is set. + + * A process that is testing addresses (the -bt option) runs as root so that + the routing is done in the same environment as a message delivery. + + +55.3 Running Exim without privilege +----------------------------------- + +Some installations like to run Exim in an unprivileged state for more of its +operation, for added security. Support for this mode of operation is provided +by the global option deliver_drop_privilege. When this is set, the uid and gid +are changed to the Exim user and group at the start of a delivery process (and +also queue runner and address testing processes). This means that address +routing is no longer run as root, and the deliveries themselves cannot change +to any other uid. + +Leaving the binary setuid to root, but setting deliver_drop_privilege means +that the daemon can still be started in the usual way, and it can respond +correctly to SIGHUP because the re-invocation regains root privilege. + +An alternative approach is to make Exim setuid to the Exim user and also setgid +to the Exim group. If you do this, the daemon must be started from a root +process. (Calling Exim from a root process makes it behave in the way it does +when it is setuid root.) However, the daemon cannot restart itself after a +SIGHUP signal because it cannot regain privilege. + +It is still useful to set deliver_drop_privilege in this case, because it stops +Exim from trying to re-invoke itself to do a delivery after a message has been +received. Such a re-invocation is a waste of resources because it has no +effect. + +If restarting the daemon is not an issue (for example, if mua_wrapper is set, +or inetd is being used instead of a daemon), having the binary setuid to the +Exim user seems a clean approach, but there is one complication: + +In this style of operation, Exim is running with the real uid and gid set to +those of the calling process, and the effective uid/gid set to Exim's values. +Ideally, any association with the calling process' uid/gid should be dropped, +that is, the real uid/gid should be reset to the effective values so as to +discard any privileges that the caller may have. While some operating systems +have a function that permits this action for a non-root effective uid, quite a +number of them do not. Because of this lack of standardization, Exim does not +address this problem at this time. + +For this reason, the recommended approach for "mostly unprivileged" running is +to keep the Exim binary setuid to root, and to set deliver_drop_privilege. This +also has the advantage of allowing a daemon to be used in the most +straightforward way. + +If you configure Exim not to run delivery processes as root, there are a number +of restrictions on what you can do: + + * You can deliver only as the Exim user/group. You should explicitly use the + user and group options to override routers or local transports that + normally deliver as the recipient. This makes sure that configurations that + work in this mode function the same way in normal mode. Any implicit or + explicit specification of another user causes an error. + + * Use of .forward files is severely restricted, such that it is usually not + worthwhile to include them in the configuration. + + * Users who wish to use .forward would have to make their home directory and + the file itself accessible to the Exim user. Pipe and append-to-file + entries, and their equivalents in Exim filters, cannot be used. While they + could be enabled in the Exim user's name, that would be insecure and not + very useful. + + * Unless the local user mailboxes are all owned by the Exim user (possible in + some POP3 or IMAP-only environments): + + 1. They must be owned by the Exim group and be writeable by that group. + This implies you must set mode in the appendfile configuration, as well + as the mode of the mailbox files themselves. + + 2. You must set no_check_owner, since most or all of the files will not be + owned by the Exim user. + + 3. You must set file_must_exist, because Exim cannot set the owner + correctly on a newly created mailbox when unprivileged. This also + implies that new mailboxes need to be created manually. + +These restrictions severely restrict what can be done in local deliveries. +However, there are no restrictions on remote deliveries. If you are running a +gateway host that does no local deliveries, setting deliver_drop_privilege +gives more security at essentially no cost. + +If you are using the mua_wrapper facility (see chapter 51), +deliver_drop_privilege is forced to be true. + + +55.4 Delivering to local files +------------------------------ + +Full details of the checks applied by appendfile before it writes to a file are +given in chapter 26. + + +55.5 Running local commands +--------------------------- + +There are a number of ways in which an administrator can configure Exim to run +commands based upon received, untrustworthy, data. Further, in some +configurations a user who can control a .forward file can also arrange to run +commands. Configuration to check includes, but is not limited to: + + * Use of use_shell in the pipe transport: various forms of shell command + injection may be possible with this option present. It is dangerous and + should be used only with considerable caution. Consider constraints which + whitelist allowed characters in a variable which is to be used in a pipe + transport that has use_shell enabled. + + * A number of options such as forbid_filter_run, forbid_filter_perl, + forbid_filter_dlfunc and so forth which restrict facilities available to + .forward files in a redirect router. If Exim is running on a central mail + hub to which ordinary users do not have shell access, but home directories + are NFS mounted (for instance) then administrators should review the list + of these forbid options available, and should bear in mind that the options + that may need forbidding can change as new features are added between + releases. + + * The ${run...} expansion item does not use a shell by default, but + administrators can configure use of /bin/sh as part of the command. Such + invocations should be viewed with prejudicial suspicion. + + * Administrators who use embedded Perl are advised to explore how Perl's + taint checking might apply to their usage. + + * Use of ${expand...} is somewhat analogous to shell's eval builtin and + administrators are well advised to view its use with suspicion, in case + (for instance) it allows a local-part to contain embedded Exim directives. + + * Use of ${match_local_part...} and friends becomes more dangerous if Exim + was built with EXPAND_LISTMATCH_RHS defined: the second string in each can + reference arbitrary lists and files, rather than just being a list of + opaque strings. The EXPAND_LISTMATCH_RHS option was added and set false by + default because of real-world security vulnerabilities caused by its use + with untrustworthy data injected in, for SQL injection attacks. Consider + the use of the inlisti expansion condition instead. + + +55.6 Trust in configuration data +-------------------------------- + +If configuration data for Exim can come from untrustworthy sources, there are +some issues to be aware of: + + * Use of ${expand...} may provide a path for shell injection attacks. + + * Letting untrusted data provide a regular expression is unwise. + + * Using ${match...} to apply a fixed regular expression against untrusted + data may result in pathological behaviour within PCRE. Be aware of what + "backtracking" means and consider options for being more strict with a + regular expression. Avenues to explore include limiting what can match + (avoiding "." when "[a-z0-9]" or other character class will do), use of + atomic grouping and possessive quantifiers or just not using regular + expressions against untrusted data. + + * It can be important to correctly use ${quote:...}, ${quote_local_part:...} + and ${quote_<lookup-type>:...} expansion items to ensure that data is + correctly constructed. + + * Some lookups might return multiple results, even though normal usage is + only expected to yield one result. + + +55.7 IPv4 source routing +------------------------ + +Many operating systems suppress IP source-routed packets in the kernel, but +some cannot be made to do this, so Exim does its own check. It logs incoming +IPv4 source-routed TCP calls, and then drops them. Things are all different in +IPv6. No special checking is currently done. + + +55.8 The VRFY, EXPN, and ETRN commands in SMTP +---------------------------------------------- + +Support for these SMTP commands is disabled by default. If required, they can +be enabled by defining suitable ACLs. + + +55.9 Privileged users +--------------------- + +Exim recognizes two sets of users with special privileges. Trusted users are +able to submit new messages to Exim locally, but supply their own sender +addresses and information about a sending host. For other users submitting +local messages, Exim sets up the sender address from the uid, and doesn't +permit a remote host to be specified. + +However, an untrusted user is permitted to use the -f command line option in +the special form -f <> to indicate that a delivery failure for the message +should not cause an error report. This affects the message's envelope, but it +does not affect the Sender: header. Untrusted users may also be permitted to +use specific forms of address with the -f option by setting the +untrusted_set_sender option. + +Trusted users are used to run processes that receive mail messages from some +other mail domain and pass them on to Exim for delivery either locally, or over +the Internet. Exim trusts a caller that is running as root, as the Exim user, +as any user listed in the trusted_users configuration option, or under any +group listed in the trusted_groups option. + +Admin users are permitted to do things to the messages on Exim's queue. They +can freeze or thaw messages, cause them to be returned to their senders, remove +them entirely, or modify them in various ways. In addition, admin users can run +the Exim monitor and see all the information it is capable of providing, which +includes the contents of files on the spool. + +By default, the use of the -M and -q options to cause Exim to attempt delivery +of messages on its queue is restricted to admin users. This restriction can be +relaxed by setting the no_prod_requires_admin option. Similarly, the use of -bp +(and its variants) to list the contents of the queue is also restricted to +admin users. This restriction can be relaxed by setting +no_queue_list_requires_admin. + +Exim recognizes an admin user if the calling process is running as root or as +the Exim user or if any of the groups associated with the calling process is +the Exim group. It is not necessary actually to be running under the Exim +group. However, if admin users who are not root or the Exim user are to access +the contents of files on the spool via the Exim monitor (which runs +unprivileged), Exim must be built to allow group read access to its spool +files. + +By default, regular users are trusted to perform basic testing and +introspection commands, as themselves. This setting can be tightened by setting +the commandline_checks_require_admin option. This affects most of the checking +options, such as -be and anything else -b*. + + +55.10 Spool files +----------------- + +Exim's spool directory and everything it contains is owned by the Exim user and +set to the Exim group. The mode for spool files is defined in the Local/ +Makefile configuration file, and defaults to 0640. This means that any user who +is a member of the Exim group can access these files. + + +55.11 Use of argv[0] +-------------------- + +Exim examines the last component of argv[0], and if it matches one of a set of +specific strings, Exim assumes certain options. For example, calling Exim with +the last component of argv[0] set to "rsmtp" is exactly equivalent to calling +it with the option -bS. There are no security implications in this. + + +55.12 Use of %f formatting +-------------------------- + +The only use made of "%f" by Exim is in formatting load average values. These +are actually stored in integer variables as 1000 times the load average. +Consequently, their range is limited and so therefore is the length of the +converted output. + + +55.13 Embedded Exim path +------------------------ + +Exim uses its own path name, which is embedded in the code, only when it needs +to re-exec in order to regain root privilege. Therefore, it is not root when it +does so. If some bug allowed the path to get overwritten, it would lead to an +arbitrary program's being run as exim, not as root. + + +55.14 Dynamic module directory +------------------------------ + +Any dynamically loadable modules must be installed into the directory defined +in "LOOKUP_MODULE_DIR" in Local/Makefile for Exim to permit loading it. + + +55.15 Use of sprintf() +---------------------- + +A large number of occurrences of "sprintf" in the code are actually calls to +string_sprintf(), a function that returns the result in malloc'd store. The +intermediate formatting is done into a large fixed buffer by a function that +runs through the format string itself, and checks the length of each conversion +before performing it, thus preventing buffer overruns. + +The remaining uses of sprintf() happen in controlled circumstances where the +output buffer is known to be sufficiently long to contain the converted string. + + +55.16 Use of debug_printf() and log_write() +------------------------------------------- + +Arbitrary strings are passed to both these functions, but they do their +formatting by calling the function string_vformat(), which runs through the +format string itself, and checks the length of each conversion. + + +55.17 Use of strcat() and strcpy() +---------------------------------- + +These are used only in cases where the output buffer is known to be large +enough to hold the result. + + + +=============================================================================== +56. FORMAT OF SPOOL FILES + +A message on Exim's queue consists of two files, whose names are the message id +followed by -D and -H, respectively. The data portion of the message is kept in +the -D file on its own. The message's envelope, status, and headers are all +kept in the -H file, whose format is described in this chapter. Each of these +two files contains the final component of its own name as its first line. This +is insurance against disk crashes where the directory is lost but the files +themselves are recoverable. + +The file formats may be changed, or new formats added, at any release. Spool +files are not intended as an interface to other programs and should not be used +as such. + +Some people are tempted into editing -D files in order to modify messages. You +need to be extremely careful if you do this; it is not recommended and you are +on your own if you do it. Here are some of the pitfalls: + + * You must ensure that Exim does not try to deliver the message while you are + fiddling with it. The safest way is to take out a write lock on the -D + file, which is what Exim itself does, using fcntl(). If you update the file + in place, the lock will be retained. If you write a new file and rename it, + the lock will be lost at the instant of rename. + + * If you change the number of lines in the file, the value of $body_linecount + , which is stored in the -H file, will be incorrect and can cause + incomplete transmission of messages or undeliverable messages. + + * If the message is in MIME format, you must take care not to break it. + + * If the message is cryptographically signed, any change will invalidate the + signature. + +All in all, modifying -D files is fraught with danger. + +Files whose names end with -J may also be seen in the input directory (or its +subdirectories when split_spool_directory is set). These are journal files, +used to record addresses to which the message has been delivered during the +course of a delivery attempt. If there are still undelivered recipients at the +end, the -H file is updated, and the -J file is deleted. If, however, there is +some kind of crash (for example, a power outage) before this happens, the -J +file remains in existence. When Exim next processes the message, it notices the +-J file and uses it to update the -H file before starting the next delivery +attempt. + +Files whose names end with -K or .eml may also be seen in the spool. These are +temporaries used for DKIM or malware processing, when that is used. They should +be tidied up by normal operations; any old ones are probably relics of crashes +and can be removed. + + +56.1 Format of the -H file +-------------------------- + +The second line of the -H file contains the login name for the uid of the +process that called Exim to read the message, followed by the numerical uid and +gid. For a locally generated message, this is normally the user who sent the +message. For a message received over TCP/IP via the daemon, it is normally the +Exim user. + +The third line of the file contains the address of the message's sender as +transmitted in the envelope, contained in angle brackets. The sender address is +empty for bounce messages. For incoming SMTP mail, the sender address is given +in the MAIL command. For locally generated mail, the sender address is created +by Exim from the login name of the current user and the configured +qualify_domain. However, this can be overridden by the -f option or a leading +"From " line if the caller is trusted, or if the supplied address is "<>" or an +address that matches untrusted_set_senders. + +The fourth line contains two numbers. The first is the time that the message +was received, in the conventional Unix form - the number of seconds since the +start of the epoch. The second number is a count of the number of messages +warning of delayed delivery that have been sent to the sender. + +There follow a number of lines starting with a hyphen. These can appear in any +order, and are omitted when not relevant: + +-acl <number> <length> + + This item is obsolete, and is not generated from Exim release 4.61 onwards; + -aclc and -aclm are used instead. However, -acl is still recognized, to + provide backward compatibility. In the old format, a line of this form is + present for every ACL variable that is not empty. The number identifies the + variable; the acl_cx variables are numbered 0-9 and the acl_mx variables + are numbered 10-19. The length is the length of the data string for the + variable. The string itself starts at the beginning of the next line, and + is followed by a newline character. It may contain internal newlines. + +-aclc <rest-of-name> <length> + + A line of this form is present for every ACL connection variable that is + defined. Note that there is a space between -aclc and the rest of the name. + The length is the length of the data string for the variable. The string + itself starts at the beginning of the next line, and is followed by a + newline character. It may contain internal newlines. + +-aclm <rest-of-name> <length> + + A line of this form is present for every ACL message variable that is + defined. Note that there is a space between -aclm and the rest of the name. + The length is the length of the data string for the variable. The string + itself starts at the beginning of the next line, and is followed by a + newline character. It may contain internal newlines. + +-active_hostname <hostname> + + This is present if, when the message was received over SMTP, the value of + $smtp_active_hostname was different to the value of $primary_hostname. + +-allow_unqualified_recipient + + This is present if unqualified recipient addresses are permitted in header + lines (to stop such addresses from being qualified if rewriting occurs at + transport time). Local messages that were input using -bnq and remote + messages from hosts that match recipient_unqualified_hosts set this flag. + +-allow_unqualified_sender + + This is present if unqualified sender addresses are permitted in header + lines (to stop such addresses from being qualified if rewriting occurs at + transport time). Local messages that were input using -bnq and remote + messages from hosts that match sender_unqualified_hosts set this flag. + +-auth_id <text> + + The id information for a message received on an authenticated SMTP + connection - the value of the $authenticated_id variable. + +-auth_sender <address> + + The address of an authenticated sender - the value of the + $authenticated_sender variable. + +-body_linecount <number> + + This records the number of lines in the body of the message, and is present + unless -spool_file_wireformat is. + +-body_zerocount <number> + + This records the number of binary zero bytes in the body of the message, + and is present if the number is greater than zero. + +-deliver_firsttime + + This is written when a new message is first added to the spool. When the + spool file is updated after a deferral, it is omitted. + +-frozen <time> + + The message is frozen, and the freezing happened at <time>. + +-helo_name <text> + + This records the host name as specified by a remote host in a HELO or EHLO + command. + +-host_address <address>.<port> + + This records the IP address of the host from which the message was received + and the remote port number that was used. It is omitted for locally + generated messages. + +-host_auth <text> + + If the message was received on an authenticated SMTP connection, this + records the name of the authenticator - the value of the + $sender_host_authenticated variable. + +-host_lookup_failed + + This is present if an attempt to look up the sending host's name from its + IP address failed. It corresponds to the $host_lookup_failed variable. + +-host_name <text> + + This records the name of the remote host from which the message was + received, if the host name was looked up from the IP address when the + message was being received. It is not present if no reverse lookup was + done. + +-ident <text> + + For locally submitted messages, this records the login of the originating + user, unless it was a trusted user and the -oMt option was used to specify + an ident value. For messages received over TCP/IP, this records the ident + string supplied by the remote host, if any. + +-interface_address <address>.<port> + + This records the IP address of the local interface and the port number + through which a message was received from a remote host. It is omitted for + locally generated messages. + +-local + + The message is from a local sender. + +-localerror + + The message is a locally-generated bounce message. + +-local_scan <string> + + This records the data string that was returned by the local_scan() function + when the message was received - the value of the $local_scan_data variable. + It is omitted if no data was returned. + +-manual_thaw + + The message was frozen but has been thawed manually, that is, by an + explicit Exim command rather than via the auto-thaw process. + +-N + + A testing delivery process was started using the -N option to suppress any + actual deliveries, but delivery was deferred. At any further delivery + attempts, -N is assumed. + +-received_protocol + + This records the value of the $received_protocol variable, which contains + the name of the protocol by which the message was received. + +-sender_set_untrusted + + The envelope sender of this message was set by an untrusted local caller + (used to ensure that the caller is displayed in queue listings). + +-spam_score_int <number> + + If a message was scanned by SpamAssassin, this is present. It records the + value of $spam_score_int. + +-spool_file_wireformat + + The -D file for this message is in wire-format (for ESMTP CHUNKING) rather + than Unix-format. The line-ending is CRLF rather than newline. There is + still, however, no leading-dot-stuffing. + +-tls_certificate_verified + + A TLS certificate was received from the client that sent this message, and + the certificate was verified by the server. + +-tls_cipher <cipher name> + + When the message was received over an encrypted connection, this records + the name of the cipher suite that was used. + +-tls_peerdn <peer DN> + + When the message was received over an encrypted connection, and a + certificate was received from the client, this records the Distinguished + Name from that certificate. + +Following the options there is a list of those addresses to which the message +is not to be delivered. This set of addresses is initialized from the command +line when the -t option is used and extract_addresses_remove_arguments is set; +otherwise it starts out empty. Whenever a successful delivery is made, the +address is added to this set. The addresses are kept internally as a balanced +binary tree, and it is a representation of that tree which is written to the +spool file. If an address is expanded via an alias or forward file, the +original address is added to the tree when deliveries to all its child +addresses are complete. + +If the tree is empty, there is a single line in the spool file containing just +the text "XX". Otherwise, each line consists of two letters, which are either Y +or N, followed by an address. The address is the value for the node of the +tree, and the letters indicate whether the node has a left branch and/or a +right branch attached to it, respectively. If branches exist, they immediately +follow. Here is an example of a three-node tree: + +YY darcy@austen.fict.example +NN alice@wonderland.fict.example +NN editor@thesaurus.ref.example + +After the non-recipients tree, there is a list of the message's recipients. +This is a simple list, preceded by a count. It includes all the original +recipients of the message, including those to whom the message has already been +delivered. In the simplest case, the list contains one address per line. For +example: + +4 +editor@thesaurus.ref.example +darcy@austen.fict.example +rdo@foundation +alice@wonderland.fict.example + +However, when a child address has been added to the top-level addresses as a +result of the use of the one_time option on a redirect router, each line is of +the following form: + +<top-level address> <errors_to address> <length>,<parent number>#<flag bits> + +The 01 flag bit indicates the presence of the three other fields that follow +the top-level address. Other bits may be used in future to support additional +fields. The <parent number> is the offset in the recipients list of the +original parent of the "one time" address. The first two fields are the +envelope sender that is associated with this address and its length. If the +length is zero, there is no special envelope sender (there are then two space +characters in the line). A non-empty field can arise from a redirect router +that has an errors_to setting. + +A blank line separates the envelope and status information from the headers +which follow. A header may occupy several lines of the file, and to save effort +when reading it in, each header is preceded by a number and an identifying +character. The number is the number of characters in the header, including any +embedded newlines and the terminating newline. The character is one of the +following: + +<blank> header in which Exim has no special interest +"B" Bcc: header +"C" Cc: header +"F" From: header +"I" Message-id: header +"P" Received: header - P for "postmark" +"R" Reply-To: header +"S" Sender: header +"T" To: header +"*" replaced or deleted header + +Deleted or replaced (rewritten) headers remain in the spool file for debugging +purposes. They are not transmitted when the message is delivered. Here is a +typical set of headers: + +111P Received: by hobbit.fict.example with local (Exim 4.00) +id 14y9EI-00026G-00; Fri, 11 May 2001 10:28:59 +0100 +049 Message-Id: <E14y9EI-00026G-00@hobbit.fict.example> +038* X-rewrote-sender: bb@hobbit.fict.example +042* From: Bilbo Baggins <bb@hobbit.fict.example> +049F From: Bilbo Baggins <B.Baggins@hobbit.fict.example> +099* To: alice@wonderland.fict.example, rdo@foundation, +darcy@austen.fict.example, editor@thesaurus.ref.example +104T To: alice@wonderland.fict.example, rdo@foundation.example, +darcy@austen.fict.example, editor@thesaurus.ref.example +038 Date: Fri, 11 May 2001 10:28:59 +0100 + +The asterisked headers indicate that the envelope sender, From: header, and To: +header have been rewritten, the last one because routing expanded the +unqualified domain foundation. + + +56.2 Format of the -D file +-------------------------- + +The data file is traditionally in Unix-standard format: lines are ended with an +ASCII newline character. However, when the spool_wireformat main option is used +some -D files can have an alternate format. This is flagged by a +-spool_file_wireformat line in the corresponding -H file. The -D file lines +(not including the first name-component line) are suitable for direct copying +to the wire when transmitting using the ESMTP CHUNKING option, meaning lower +processing overhead. Lines are terminated with an ASCII CRLF pair. There is no +dot-stuffing (and no dot-termination). + + + +=============================================================================== +57. DKIM AND SPF + + +57.1 DKIM (DomainKeys Identified Mail) +-------------------------------------- + +DKIM is a mechanism by which messages sent by some entity can be provably +linked to a domain which that entity controls. It permits reputation to be +tracked on a per-domain basis, rather than merely upon source IP address. DKIM +is documented in RFC 6376. + +As DKIM relies on the message being unchanged in transit, messages handled by a +mailing-list (which traditionally adds to the message) will not match any +original DKIM signature. + +DKIM support is compiled into Exim by default if TLS support is present. It can +be disabled by setting DISABLE_DKIM=yes in Local/Makefile. + +Exim's DKIM implementation allows for + + 1. Signing outgoing messages: This function is implemented in the SMTP + transport. It can co-exist with all other Exim features (including + transport filters) except cutthrough delivery. + + 2. Verifying signatures in incoming messages: This is implemented by an + additional ACL (acl_smtp_dkim), which can be called several times per + message, with different signature contexts. + +In typical Exim style, the verification implementation does not include any +default "policy". Instead it enables you to build your own policy using Exim's +standard controls. + +Please note that verification of DKIM signatures in incoming mail is turned on +by default for logging (in the <= line) purposes. + +Additional log detail can be enabled using the dkim_verbose log_selector. When +set, for each signature in incoming email, exim will log a line displaying the +most important signature details, and the signature status. Here is an example +(with line-breaks added for clarity): + +2009-09-09 10:22:28 1MlIRf-0003LU-U3 DKIM: + d=facebookmail.com s=q1-2009b + c=relaxed/relaxed a=rsa-sha1 + i=@facebookmail.com t=1252484542 [verification succeeded] + +You might want to turn off DKIM verification processing entirely for internal +or relay mail sources. To do that, set the dkim_disable_verify ACL control +modifier. This should typically be done in the RCPT ACL, at points where you +accept mail from relay sources (internal hosts or authenticated senders). + + +57.2 Signing outgoing messages +------------------------------ + +For signing to be usable you must have published a DKIM record in DNS. Note +that RFC 8301 says: + +rsa-sha1 MUST NOT be used for signing or verifying. + +Signers MUST use RSA keys of at least 1024 bits for all keys. +Signers SHOULD use RSA keys of at least 2048 bits. + +Note also that the key content (the 'p=' field) in the DNS record is different +between RSA and EC keys; for the former it is the base64 of the ASN.1 for the +RSA public key (equivalent to the private-key .pem with the header/trailer +stripped) but for EC keys it is the base64 of the pure key; no ASN.1 wrapping. + +Signing is enabled by setting private options on the SMTP transport. These +options take (expandable) strings as arguments. + ++-------------------------------------------------+ +|dkim_domain|Use: smtp|Type: string|Default: list*| ++-------------------------------------------------+ + +The domain(s) you want to sign with. After expansion, this can be a list. Each +element in turn is put into the $dkim_domain expansion variable while expanding +the remaining signing options. If it is empty after expansion, DKIM signing is +not done, and no error will result even if dkim_strict is set. + ++---------------------------------------------------+ +|dkim_selector|Use: smtp|Type: string|Default: list*| ++---------------------------------------------------+ + +This sets the key selector string. After expansion, which can use $dkim_domain, +this can be a list. Each element in turn is put in the expansion variable +$dkim_selector which may be used in the dkim_private_key option along with +$dkim_domain. If the option is empty after expansion, DKIM signing is not done +for this domain, and no error will result even if dkim_strict is set. + ++-------------------------------------------------------+ +|dkim_private_key|Use: smtp|Type: string*|Default: unset| ++-------------------------------------------------------+ + +This sets the private key to use. You can use the $dkim_domain and +$dkim_selector expansion variables to determine the private key to use. The +result can either + + * be a valid RSA private key in ASCII armor (.pem file), including line + breaks + + * with GnuTLS 3.6.0 or OpenSSL 1.1.1 or later, be a valid Ed25519 private key + (same format as above) + + * start with a slash, in which case it is treated as a file that contains the + private key + + * be "0", "false" or the empty string, in which case the message will not be + signed. This case will not result in an error, even if dkim_strict is set. + +To generate keys under OpenSSL: + +openssl genrsa -out dkim_rsa.private 2048 +openssl rsa -in dkim_rsa.private -out /dev/stdout -pubout -outform PEM + +Take the base-64 lines from the output of the second command, concatenated, for +the DNS TXT record. See section 3.6 of RFC6376 for the record specification. + +Under GnuTLS: + +certtool --generate-privkey --rsa --bits=2048 --password='' -8 --outfile=dkim_rsa.private +certtool --load-privkey=dkim_rsa.private --pubkey-info + +Note that RFC 8301 says: + +Signers MUST use RSA keys of at least 1024 bits for all keys. +Signers SHOULD use RSA keys of at least 2048 bits. + +Support for EC keys is being developed under https://datatracker.ietf.org/doc/ +draft-ietf-dcrup-dkim-crypto/. They are considerably smaller than RSA keys for +equivalent protection. As they are a recent development, users should consider +dual-signing (by setting a list of selectors, and an expansion for this option) +for some transition period. The "_CRYPTO_SIGN_ED25519" macro will be defined if +support is present for EC keys. + +OpenSSL 1.1.1 and GnuTLS 3.6.0 can create Ed25519 private keys: + +openssl genpkey -algorithm ed25519 -out dkim_ed25519.private +certtool --generate-privkey --key-type=ed25519 --outfile=dkim_ed25519.private + +To produce the required public key value for a DNS record: + +openssl pkey -outform DER -pubout -in dkim_ed25519.private | tail -c +13 | base64 +certtool --load_privkey=dkim_ed25519.private --pubkey_info --outder | tail -c +13 | base64 + +Note that the format of Ed25519 keys in DNS has not yet been decided; this +release supports both of the leading candidates at this time, a future release +will probably drop support for whichever proposal loses. + ++-------------------------------------------------+ +|dkim_hash|Use: smtp|Type: string*|Default: sha256| ++-------------------------------------------------+ + +Can be set to any one of the supported hash methods, which are: + + * "sha1" - should not be used, is old and insecure + + * "sha256" - the default + + * "sha512" - possibly more secure but less well supported + +Note that RFC 8301 says: + +rsa-sha1 MUST NOT be used for signing or verifying. + ++----------------------------------------------------+ +|dkim_identity|Use: smtp|Type: string*|Default: unset| ++----------------------------------------------------+ + +If set after expansion, the value is used to set an "i=" tag in the signing +header. The DKIM standards restrict the permissible syntax of this optional tag +to a mail address, with possibly-empty local part, an @, and a domain identical +to or subdomain of the "d=" tag value. Note that Exim does not check the value. + ++-------------------------------------------------+ +|dkim_canon|Use: smtp|Type: string*|Default: unset| ++-------------------------------------------------+ + +This option sets the canonicalization method used when signing a message. The +DKIM RFC currently supports two methods: "simple" and "relaxed". The option +defaults to "relaxed" when unset. Note: the current implementation only +supports signing with the same canonicalization method for both headers and +body. + ++--------------------------------------------------+ +|dkim_strict|Use: smtp|Type: string*|Default: unset| ++--------------------------------------------------+ + +This option defines how Exim behaves when signing a message that should be +signed fails for some reason. When the expansion evaluates to either "1" or +"true", Exim will defer. Otherwise Exim will send the message unsigned. You can +use the $dkim_domain and $dkim_selector expansion variables here. + ++------------------------------------------------------------+ +|dkim_sign_headers|Use: smtp|Type: string*|Default: see below| ++------------------------------------------------------------+ + +If set, this option must expand to a colon-separated list of header names. +Headers with these names, or the absence or such a header, will be included in +the message signature. When unspecified, the header names listed in RFC4871 +will be used, whether or not each header is present in the message. The default +list is available for the expansion in the macro "_DKIM_SIGN_HEADERS". + +If a name is repeated, multiple headers by that name (or the absence thereof) +will be signed. The textually later headers in the headers part of the message +are signed first, if there are multiples. + +A name can be prefixed with either an '=' or a '+' character. If an '=' prefix +is used, all headers that are present with this name will be signed. If a '+' +prefix if used, all headers that are present with this name will be signed, and +one signature added for a missing header with the name will be appended. + ++-------------------------------------------------------+ +|dkim_timestamps|Use: smtp|Type: integer*|Default: unset| ++-------------------------------------------------------+ + +This option controls the inclusion of timestamp information in the signature. +If not set, no such information will be included. Otherwise, must be an +unsigned number giving an offset in seconds from the current time for the +expiry tag (eg. 1209600 for two weeks); both creation (t=) and expiry (x=) tags +will be included. + +RFC 6376 lists these tags as RECOMMENDED. + + +57.3 Verifying DKIM signatures in incoming mail +----------------------------------------------- + +Verification of DKIM signatures in SMTP incoming email is done for all messages +for which an ACL control dkim_disable_verify has not been set. Performing +verification sets up information used by the $authresults expansion item. + +The acl_smtp_dkim ACL, which can examine and modify them. By default, this ACL +is called once for each syntactically(!) correct signature in the incoming +message. A missing ACL definition defaults to accept. If any ACL call does not +accept, the message is not accepted. If a cutthrough delivery was in progress +for the message, that is summarily dropped (having wasted the transmission +effort). + +To evaluate the verification result in the ACL a large number of expansion +variables containing the signature status and its details are set up during the +runtime of the ACL. + +Calling the ACL only for existing signatures is not sufficient to build more +advanced policies. For that reason, the global option dkim_verify_signers, and +a global expansion variable $dkim_signers exist. + +The global option dkim_verify_signers can be set to a colon-separated list of +DKIM domains or identities for which the ACL acl_smtp_dkim is called. It is +expanded when the message has been received. At this point, the expansion +variable $dkim_signers already contains a colon-separated list of signer +domains and identities for the message. When dkim_verify_signers is not +specified in the main configuration, it defaults as: + +dkim_verify_signers = $dkim_signers + +This leads to the default behaviour of calling acl_smtp_dkim for each DKIM +signature in the message. Current DKIM verifiers may want to explicitly call +the ACL for known domains or identities. This would be achieved as follows: + +dkim_verify_signers = paypal.com:ebay.com:$dkim_signers + +This would result in acl_smtp_dkim always being called for "paypal.com" and +"ebay.com", plus all domains and identities that have signatures in the +message. You can also be more creative in constructing your policy. For +example: + +dkim_verify_signers = $sender_address_domain:$dkim_signers + +If a domain or identity is listed several times in the (expanded) value of +dkim_verify_signers, the ACL is only called once for that domain or identity. + +If multiple signatures match a domain (or identity), the ACL is called once for +each matching signature. + +Inside the acl_smtp_dkim, the following expansion variables are available (from +most to least important): + +$dkim_cur_signer + + The signer that is being evaluated in this ACL run. This can be a domain or + an identity. This is one of the list items from the expanded main option + dkim_verify_signers (see above). + +$dkim_verify_status + + Within the DKIM ACL, a string describing the general status of the + signature. One of + + + none: There is no signature in the message for the current domain or + identity (as reflected by $dkim_cur_signer). + + + invalid: The signature could not be verified due to a processing error. + More detail is available in $dkim_verify_reason. + + + fail: Verification of the signature failed. More detail is available in + $dkim_verify_reason. + + + pass: The signature passed verification. It is valid. + + This variable can be overwritten using an ACL 'set' modifier. This might, + for instance, be done to enforce a policy restriction on hash-method or + key-size: + + warn condition = ${if eq {$dkim_verify_status}{pass}} + condition = ${if eq {${length_3:$dkim_algo}}{rsa}} + condition = ${if or {{eq {$dkim_algo}{rsa-sha1}} \ + {< {$dkim_key_length}{1024}}}} + logwrite = NOTE: forcing DKIM verify fail (was pass) + set dkim_verify_status = fail + set dkim_verify_reason = hash too weak or key too short + + So long as a DKIM ACL is defined (it need do no more than accept), after + all the DKIM ACL runs have completed, the value becomes a colon-separated + list of the values after each run. This is maintained for the mime, prdr + and data ACLs. + +$dkim_verify_reason + + A string giving a little bit more detail when $dkim_verify_status is either + "fail" or "invalid". One of + + + pubkey_unavailable (when $dkim_verify_status="invalid"): The public key + for the domain could not be retrieved. This may be a temporary problem. + + + pubkey_syntax (when $dkim_verify_status="invalid"): The public key + record for the domain is syntactically invalid. + + + bodyhash_mismatch (when $dkim_verify_status="fail"): The calculated + body hash does not match the one specified in the signature header. + This means that the message body was modified in transit. + + + signature_incorrect (when $dkim_verify_status="fail"): The signature + could not be verified. This may mean that headers were modified, + re-written or otherwise changed in a way which is incompatible with + DKIM verification. It may of course also mean that the signature is + forged. + + This variable can be overwritten, with any value, using an ACL 'set' + modifier. + +$dkim_domain + + The signing domain. IMPORTANT: This variable is only populated if there is + an actual signature in the message for the current domain or identity (as + reflected by $dkim_cur_signer). + +$dkim_identity + + The signing identity, if present. IMPORTANT: This variable is only + populated if there is an actual signature in the message for the current + domain or identity (as reflected by $dkim_cur_signer). + +$dkim_selector + + The key record selector string. + +$dkim_algo + + The algorithm used. One of 'rsa-sha1' or 'rsa-sha256'. If running under + GnuTLS 3.6.0 or OpenSSL 1.1.1 or later, may also be 'ed25519-sha256'. The + "_CRYPTO_SIGN_ED25519" macro will be defined if support is present for EC + keys. + + Note that RFC 8301 says: + + rsa-sha1 MUST NOT be used for signing or verifying. + + DKIM signatures identified as having been signed with historic + algorithms (currently, rsa-sha1) have permanently failed evaluation + + To enforce this you must have a DKIM ACL which checks this variable and + overwrites the $dkim_verify_status variable as discussed above. + +$dkim_canon_body + + The body canonicalization method. One of 'relaxed' or 'simple'. + +$dkim_canon_headers + + The header canonicalization method. One of 'relaxed' or 'simple'. + +$dkim_copiedheaders + + A transcript of headers and their values which are included in the + signature (copied from the 'z=' tag of the signature). Note that RFC6376 + requires that verification fail if the From: header is not included in the + signature. Exim does not enforce this; sites wishing strict enforcement + should code the check explicitly. + +$dkim_bodylength + + The number of signed body bytes. If zero ("0"), the body is unsigned. If no + limit was set by the signer, "9999999999999" is returned. This makes sure + that this variable always expands to an integer value. + + Note: The presence of the signature tag specifying a signing body length is + one possible route to spoofing of valid DKIM signatures. A paranoid + implementation might wish to regard signature where this variable shows + less than the "no limit" return as being invalid. + +$dkim_created + + UNIX timestamp reflecting the date and time when the signature was created. + When this was not specified by the signer, "0" is returned. + +$dkim_expires + + UNIX timestamp reflecting the date and time when the signer wants the + signature to be treated as "expired". When this was not specified by the + signer, "9999999999999" is returned. This makes it possible to do useful + integer size comparisons against this value. Note that Exim does not check + this value. + +$dkim_headernames + + A colon-separated list of names of headers included in the signature. + +$dkim_key_testing + + "1" if the key record has the "testing" flag set, "0" if not. + +$dkim_key_nosubdomains + + "1" if the key record forbids subdomaining, "0" otherwise. + +$dkim_key_srvtype + + Service type (tag s=) from the key record. Defaults to "*" if not specified + in the key record. + +$dkim_key_granularity + + Key granularity (tag g=) from the key record. Defaults to "*" if not + specified in the key record. + +$dkim_key_notes + + Notes from the key record (tag n=). + +$dkim_key_length + + Number of bits in the key. + + Note that RFC 8301 says: + + Verifiers MUST NOT consider signatures using RSA keys of + less than 1024 bits as valid signatures. + + To enforce this you must have a DKIM ACL which checks this variable and + overwrites the $dkim_verify_status variable as discussed above. As EC keys + are much smaller, the check should only do this for RSA keys. + +In addition, two ACL conditions are provided: + +dkim_signers + + ACL condition that checks a colon-separated list of domains or identities + for a match against the domain or identity that the ACL is currently + verifying (reflected by $dkim_cur_signer). This is typically used to + restrict an ACL verb to a group of domains or identities. For example: + + # Warn when Mail purportedly from GMail has no gmail signature + warn log_message = GMail sender without gmail.com DKIM signature + sender_domains = gmail.com + dkim_signers = gmail.com + dkim_status = none + + Note that the above does not check for a total lack of DKIM signing; for + that check for empty $h_DKIM-Signature: in the data ACL. + +dkim_status + + ACL condition that checks a colon-separated list of possible DKIM + verification results against the actual result of verification. This is + typically used to restrict an ACL verb to a list of verification outcomes, + for example: + + deny message = Mail from Paypal with invalid/missing signature + sender_domains = paypal.com:paypal.de + dkim_signers = paypal.com:paypal.de + dkim_status = none:invalid:fail + + The possible status keywords are: 'none','invalid','fail' and 'pass'. + Please see the documentation of the $dkim_verify_status expansion variable + above for more information of what they mean. + + +57.4 SPF (Sender Policy Framework) +---------------------------------- + +SPF is a mechanism whereby a domain may assert which IP addresses may transmit +messages with its domain in the envelope from, documented by RFC 7208. For more +information on SPF see http://www.openspf.org. + +Messages sent by a system not authorised will fail checking of such assertions. +This includes retransmissions done by traditional forwarders. + +SPF verification support is built into Exim if SUPPORT_SPF=yes is set in Local/ +Makefile. The support uses the libspf2 library https://www.libspf2.org/. There +is no Exim involvement in the transmission of messages; publishing certain DNS +records is all that is required. + +For verification, an ACL condition and an expansion lookup are provided. +Performing verification sets up information used by the $authresults expansion +item. + +The ACL condition "spf" can be used at or after the MAIL ACL. It takes as an +argument a list of strings giving the outcome of the SPF check, and will +succeed for any matching outcome. Valid strings are: + +pass + + The SPF check passed, the sending host is positively verified by SPF. + +fail + + The SPF check failed, the sending host is NOT allowed to send mail for the + domain in the envelope-from address. + +softfail + + The SPF check failed, but the queried domain can't absolutely confirm that + this is a forgery. + +none + + The queried domain does not publish SPF records. + +neutral + + The SPF check returned a "neutral" state. This means the queried domain has + published a SPF record, but wants to allow outside servers to send mail + under its domain as well. This should be treated like "none". + +permerror + + This indicates a syntax error in the SPF record of the queried domain. You + may deny messages when this occurs. + +temperror + + This indicates a temporary error during all processing, including Exim's + SPF processing. You may defer messages when this occurs. + +You can prefix each string with an exclamation mark to invert its meaning, for +example "!fail" will match all results but "fail". The string list is evaluated +left-to-right, in a short-circuit fashion. + +Example: + +deny spf = fail + message = $sender_host_address is not allowed to send mail from \ + ${if def:sender_address_domain \ + {$sender_address_domain}{$sender_helo_name}}. \ + Please see http://www.openspf.org/Why?scope=\ + ${if def:sender_address_domain {mfrom}{helo}};\ + identity=${if def:sender_address_domain \ + {$sender_address}{$sender_helo_name}};\ + ip=$sender_host_address + +When the spf condition has run, it sets up several expansion variables: + +$spf_header_comment + + This contains a human-readable string describing the outcome of the SPF + check. You can add it to a custom header or use it for logging purposes. + +$spf_received + + This contains a complete Received-SPF: header that can be added to the + message. Please note that according to the SPF draft, this header must be + added at the top of the header list. Please see section 10 on how you can + do this. + + Note: in case of "Best-guess" (see below), the convention is to put this + string in a header called X-SPF-Guess: instead. + +$spf_result + + This contains the outcome of the SPF check in string form, one of pass, + fail, softfail, none, neutral, permerror or temperror. + +$spf_result_guessed + + This boolean is true only if a best-guess operation was used and required + in order to obtain a result. + +$spf_smtp_comment + + This contains a string that can be used in a SMTP response to the calling + party. Useful for "fail". + +In addition to SPF, you can also perform checks for so-called "Best-guess". +Strictly speaking, "Best-guess" is not standard SPF, but it is supported by the +same framework that enables SPF capability. Refer to http://www.openspf.org/FAQ +/Best_guess_record for a description of what it means. + +To access this feature, simply use the spf_guess condition in place of the spf +one. For example: + +deny spf_guess = fail + message = $sender_host_address doesn't look trustworthy to me + +In case you decide to reject messages based on this check, you should note that +although it uses the same framework, "Best-guess" is not SPF, and therefore you +should not mention SPF at all in your reject message. + +When the spf_guess condition has run, it sets up the same expansion variables +as when spf condition is run, described above. + +Additionally, since Best-guess is not standardized, you may redefine what +"Best-guess" means to you by redefining the main configuration spf_guess +option. For example, the following: + +spf_guess = v=spf1 a/16 mx/16 ptr ?all + +would relax host matching rules to a broader network range. + +A lookup expansion is also available. It takes an email address as the key and +an IP address as the database: + + ${lookup {username@domain} spf {ip.ip.ip.ip}} + +The lookup will return the same result strings as can appear in $spf_result +(pass,fail,softfail,neutral,none,err_perm,err_temp). Currently, only IPv4 +addresses are supported. + + + +=============================================================================== +58. PROXIES + +A proxy is an intermediate system through which communication is passed. +Proxies may provide a security, availability or load-distribution function. + + +58.1 Inbound proxies +-------------------- + +Exim has support for receiving inbound SMTP connections via a proxy that uses +"Proxy Protocol" to speak to it. To include this support, include +"SUPPORT_PROXY=yes" in Local/Makefile. + +It was built on the HAProxy specification, found at https://www.haproxy.org/ +download/1.8/doc/proxy-protocol.txt. + +The purpose of this facility is so that an application load balancer, such as +HAProxy, can sit in front of several Exim servers to distribute load. Exim uses +the local protocol communication with the proxy to obtain the remote SMTP +system IP address and port information. There is no logging if a host passes or +fails Proxy Protocol negotiation, but it can easily be determined and recorded +in an ACL (example is below). + +Use of a proxy is enabled by setting the hosts_proxy main configuration option +to a hostlist; connections from these hosts will use Proxy Protocol. Exim +supports both version 1 and version 2 of the Proxy Protocol and automatically +determines which version is in use. + +The Proxy Protocol header is the first data received on a TCP connection and is +inserted before any TLS-on-connect handshake from the client; Exim negotiates +TLS between Exim-as-server and the remote client, not between Exim and the +proxy server. + +The following expansion variables are usable ("internal" and "external" here +refer to the interfaces of the proxy): + +proxy_external_address + IP of host being proxied or IP of remote interface of proxy +proxy_external_port + Port of host being proxied or Port on remote interface of proxy +proxy_local_address + IP of proxy server inbound or IP of local interface of proxy +proxy_local_port + Port of proxy server inbound or Port on local interface of proxy +proxy_session boolean: SMTP connection via proxy + +If $proxy_session is set but $proxy_external_address is empty there was a +protocol error. + +Since the real connections are all coming from the proxy, and the per host +connection tracking is done before Proxy Protocol is evaluated, +smtp_accept_max_per_host must be set high enough to handle all of the parallel +volume you expect per inbound proxy. With the option set so high, you lose the +ability to protect your server from many connections from one IP. In order to +prevent your server from overload, you need to add a per connection ratelimit +to your connect ACL. A possible solution is: + + # Set max number of connections per host + LIMIT = 5 + # Or do some kind of IP lookup in a flat file or database + # LIMIT = ${lookup{$sender_host_address}iplsearch{/etc/exim/proxy_limits}} + + defer message = Too many connections from this IP right now + ratelimit = LIMIT / 5s / per_conn / strict + + +58.2 Outbound proxies +--------------------- + +Exim has support for sending outbound SMTP via a proxy using a protocol called +SOCKS5 (defined by RFC1928). The support can be optionally included by defining +SUPPORT_SOCKS=yes in Local/Makefile. + +Use of a proxy is enabled by setting the socks_proxy option on an smtp +transport. The option value is expanded and should then be a list +(colon-separated by default) of proxy specifiers. Each proxy specifier is a +list (space-separated by default) where the initial element is an IP address +and any subsequent elements are options. + +Options are a string <name>=<value>. The list of options is in the following +table: + +auth authentication method +name authentication username +pass authentication password +port tcp port +tmo connection timeout +pri priority +weight selection bias + +More details on each of these options follows: + + * auth: Either "none" (default) or "name". Using "name" selects username/ + password authentication per RFC 1929 for access to the proxy. Default is + "none". + + * name: sets the username for the "name" authentication method. Default is + empty. + + * pass: sets the password for the "name" authentication method. Default is + empty. + + * port: the TCP port number to use for the connection to the proxy. Default + is 1080. + + * tmo: sets a connection timeout in seconds for this proxy. Default is 5. + + * pri: specifies a priority for the proxy within the list, higher values + being tried first. The default priority is 1. + + * weight: specifies a selection bias. Within a priority set servers are + queried in a random fashion, weighted by this value. The default value for + selection bias is 1. + +Proxies from the list are tried according to their priority and weight settings +until one responds. The timeout for the overall connection applies to the set +of proxied attempts. + + +58.3 Logging +------------ + +To log the (local) IP of a proxy in the incoming or delivery logline, add +"+proxy" to the log_selector option. This will add a component tagged with "PRX +=" to the line. + + + +=============================================================================== +59. INTERNATIONALISATION + +Exim has support for Internationalised mail names. To include this it must be +built with SUPPORT_I18N and the libidn library. Standards supported are RFCs +2060, 5890, 6530 and 6533. + +If Exim is built with SUPPORT_I18N_2008 (in addition to SUPPORT_I18N, not +instead of it) then IDNA2008 is supported; this adds an extra library +requirement, upon libidn2. + + +59.1 MTA operations +------------------- + +The main configuration option smtputf8_advertise_hosts specifies a host list. +If this matches the sending host and accept_8bitmime is true (the default) then +the ESMTP option SMTPUTF8 will be advertised. + +If the sender specifies the SMTPUTF8 option on a MAIL command international +handling for the message is enabled and the expansion variable +$message_smtputf8 will have value TRUE. + +The option allow_utf8_domains is set to true for this message. All DNS lookups +are converted to a-label form whatever the setting of allow_utf8_domains when +Exim is built with SUPPORT_I18N. + +Both localparts and domain are maintained as the original UTF-8 form +internally; any comparison or regular-expression use will require appropriate +care. Filenames created, eg. by the appendfile transport, will have UTF-8 +names. + +HELO names sent by the smtp transport will have any UTF-8 components expanded +to a-label form, and any certificate name checks will be done using the a-label +form of the name. + +Log lines and Received-by: header lines will acquire a "utf8" prefix on the +protocol element, eg. utf8esmtp. + +The following expansion operators can be used: + +${utf8_domain_to_alabel:str} +${utf8_domain_from_alabel:str} +${utf8_localpart_to_alabel:str} +${utf8_localpart_from_alabel:str} + +The RCPT ACL may use the following modifier: + +control = utf8_downconvert +control = utf8_downconvert/<value> + +This sets a flag requiring that addresses are converted to a-label form before +smtp delivery, for use in a Message Submission Agent context. If a value is +appended it may be: + +1 (default) mandatory downconversion +0 no downconversion +-1 if SMTPUTF8 not supported by destination host + +If mua_wrapper is set, the utf8_downconvert control is initially set to -1. + +The smtp transport has an option utf8_downconvert. If set it must expand to one +of the three values described above, and it overrides any previously set value. + +There is no explicit support for VRFY and EXPN. Configurations supporting these +should inspect $smtp_command_argument for an SMTPUTF8 argument. + +There is no support for LMTP on Unix sockets. Using the "lmtp" protocol option +on an smtp transport, for LMTP over TCP, should work as expected. + +There is no support for DSN unitext handling, and no provision for converting +logging from or to UTF-8. + + +59.2 MDA operations +------------------- + +To aid in constructing names suitable for IMAP folders the following expansion +operator can be used: + +${imapfolder {<string>} {<sep>} {<specials>}} + +The string is converted from the charset specified by the "headers charset" +command (in a filter file) or headers_charset main configuration option +(otherwise), to the modified UTF-7 encoding specified by RFC 2060, with the +following exception: All occurrences of <sep> (which has to be a single +character) are replaced with periods ("."), and all periods and slashes that +are not <sep> and are not in the <specials> string are BASE64 encoded. + +The third argument can be omitted, defaulting to an empty string. The second +argument can be omitted, defaulting to "/". + +This is the encoding used by Courier for Maildir names on disk, and followed by +many other IMAP servers. + +Examples: + +${imapfolder {Foo/Bar}} yields Foo.Bar +${imapfolder {Foo/Bar}{.}{/}} yields Foo&AC8-Bar +${imapfolder {R?ksm?rg?s}} yields R&AOQ-ksm&APY-rg&AOU-s + +Note that the source charset setting is vital, and also that characters must be +representable in UTF-16. + + + +=============================================================================== +60. EVENTS + +The events mechanism in Exim can be used to intercept processing at a number of +points. It was originally invented to give a way to do customised logging +actions (for example, to a database) but can also be used to modify some +processing actions. + +Most installations will never need to use Events. The support can be left out +of a build by defining DISABLE_EVENT=yes in Local/Makefile. + +There are two major classes of events: main and transport. The main +configuration option event_action controls reception events; a transport option +event_action controls delivery events. + +Both options are a string which is expanded when the event fires. An example +might look like: + +event_action = ${if eq {msg:delivery}{$event_name} \ +{${lookup pgsql {SELECT * FROM record_Delivery( \ + '${quote_pgsql:$sender_address_domain}',\ + '${quote_pgsql:${lc:$sender_address_local_part}}', \ + '${quote_pgsql:$domain}', \ + '${quote_pgsql:${lc:$local_part}}', \ + '${quote_pgsql:$host_address}', \ + '${quote_pgsql:${lc:$host}}', \ + '${quote_pgsql:$message_exim_id}')}} \ +} {}} + +Events have names which correspond to the point in process at which they fire. +The name is placed in the variable $event_name and the event action expansion +must check this, as it will be called for every possible event type. + +The current list of events is: + +dane:fail after transport per connection +msg:complete after main per message +msg:delivery after transport per recipient +msg:rcpt:host:defer after transport per recipient per host +msg:rcpt:defer after transport per recipient +msg:host:defer after transport per attempt +msg:fail:delivery after transport per recipient +msg:fail:internal after main per recipient +tcp:connect before transport per connection +tcp:close after transport per connection +tls:cert before both per certificate in verification chain +smtp:connect after transport per connection + +New event types may be added in future. + +The event name is a colon-separated list, defining the type of event in a tree +of possibilities. It may be used as a list or just matched on as a whole. There +will be no spaces in the name. + +The second column in the table above describes whether the event fires before +or after the action is associates with. Those which fire before can be used to +affect that action (more on this below). + +The third column in the table above says what section of the configuration +should define the event action. + +An additional variable, $event_data, is filled with information varying with +the event type: + +dane:fail failure reason +msg:delivery smtp confirmation message +msg:fail:internal failure reason +msg:fail:delivery smtp error message +msg:rcpt:host:defer error string +msg:rcpt:defer error string +msg:host:defer error string +tls:cert verification chain depth +smtp:connect smtp banner + +The :defer events populate one extra variable: $event_defer_errno. + +For complex operations an ACL expansion can be used in event_action however due +to the multiple contexts that Exim operates in during the course of its +processing: + + * variables set in transport events will not be visible outside that + transport call + + * acl_m variables in a server context are lost on a new connection, and after + smtp helo/ehlo/mail/starttls/rset commands + +Using an ACL expansion with the logwrite modifier can be a useful way of +writing to the main log. + +The expansion of the event_action option should normally return an empty +string. Should it return anything else the following will be forced: + +tcp:connect do not connect +tls:cert refuse verification +smtp:connect close connection + +All other message types ignore the result string, and no other use is made of +it. + +For a tcp:connect event, if the connection is being made to a proxy then the +address and port variables will be that of the proxy and not the target system. + +For tls:cert events, if GnuTLS is in use this will trigger only per chain +element received on the connection. For OpenSSL it will trigger for every chain +element including those loaded locally. + + + +=============================================================================== +61. ADDING NEW DRIVERS OR LOOKUP TYPES + +The following actions have to be taken in order to add a new router, transport, +authenticator, or lookup type to Exim: + + 1. Choose a name for the driver or lookup type that does not conflict with any + existing name; I will use "newdriver" in what follows. + + 2. Add to src/EDITME the line: + + <type>_NEWDRIVER=yes + + where <type> is ROUTER, TRANSPORT, AUTH, or LOOKUP. If the code is not to + be included in the binary by default, comment this line out. You should + also add any relevant comments about the driver or lookup type. + + 3. Add to src/config.h.defaults the line: + + #define <type>_NEWDRIVER + + 4. Edit src/drtables.c, adding conditional code to pull in the private header + and create a table entry as is done for all the other drivers and lookup + types. + + 5. Edit scripts/lookups-Makefile if this is a new lookup; there is a for-loop + near the bottom, ranging the "name_mod" variable over a list of all + lookups. Add your "NEWDRIVER" to that list. As long as the dynamic module + would be named newdriver.so, you can use the simple form that most lookups + have. + + 6. Edit Makefile in the appropriate sub-directory (src/routers, src/transports + , src/auths, or src/lookups); add a line for the new driver or lookup type + and add it to the definition of OBJ. + + 7. Edit OS/Makefile-Base adding a .o file for the predefined-macros, to the + definition of OBJ_MACRO. Add a set of line to do the compile also. + + 8. Create newdriver.h and newdriver.c in the appropriate sub-directory of src. + + 9. Edit scripts/MakeLinks and add commands to link the .h and .c files as for + other drivers and lookups. + +Then all you need to do is write the code! A good way to start is to make a +proforma by copying an existing module of the same type, globally changing all +occurrences of the name, and cutting out most of the code. Note that any +options you create must be listed in alphabetical order, because the tables are +searched using a binary chop procedure. + +There is a README file in each of the sub-directories of src describing the +interface that is expected. + |