1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
4 <TITLE>EXIM OVERVIEW</TITLE>
5 <META NAME="generator" CONTENT="txt2html v1.21">
7 <BODY bgcolor="#ccccff">
12 Date: 29 November 1996
15 Exim is a mail transport agent (MTA) developed at the University of Cambridge
16 for use on Unix systems connected to the Internet. It is freely available
17 under the terms of the GNU General Public Licence. In style it is similar to
18 Smail 3, but its facilities are more extensive, and in particular it has some
19 defences against mail bombs and unsolicited junk mail, in the form of options
20 for refusing messages from particular hosts, networks, or senders.
23 Exim is in production use on a number of sites that move tens of thousands of
24 messages per day. This document contains an overview description of the way
25 Exim works, with a certain amount of simplification to keep it fairly short.
28 This document is copyright (c) University of Cambridge 1996, but copying
29 permission is granted to all.
34 "If I have seen further it is by standing on the shoulders of giants."
43 Exim owes a great deal to Smail 3 and its author, Ron Karr. Without the
44 experience of running and working on the Smail 3 code, I could never have
45 contemplated starting to write a new mailer. Many of the ideas and user
46 interfaces are taken from Smail 3, though the actual code of Exim is entirely
50 My intention was to write a mailer that had more functionality than Smail 3,
51 but which retained the simple lightweight approach, as this seemed to me to be
52 all that was needed for systems directly connected to the Internet, where most
53 messages are delivered almost immediately.
56 <A NAME="0"><H2>2. Availability</H2></A>
59 The current distribution of Exim is available from
62 ftp://ftp.cus.cam.ac.uk/pub/software/programs/exim/exim-n.nn.tar.gz
65 where n.nn is the version number. The distribution contains an ASCII copy of
66 the documentation; other formats are available from
69 ftp://ftp.cus.cam.ac.uk/pub/software/programs/exim/exim-postscript-n.nn.tar.gz
70 ftp://ftp.cus.cam.ac.uk/pub/software/programs/exim/exim-texinfo-n.nn.tar.gz
73 The following operating systems are currently supported: AIX, BSDI, FreeBSD,
74 HP-UX, IRIX, Linux, NetBSD, DEC OSF1 (aka Digital UNIX), SCO, SunOS4, SunOS5,
78 <A NAME="1"><H2>3. Limitations</H2></A>
81 For the benefit of those reading this overview to see whether Exim is of
82 interest to them, its limitations are listed first.
85 <LI> Exim is written in ANSI C. This should not be much of a limitation these
86 days. However, to help with systems that lack a true ANSI C library, Exim
87 avoids making any use of the value returned by the sprintf() function,
88 which is one of the main incompatibilities. It has its own version of
89 strerror() for use with SunOS4 and any other system that lacks this
90 function, and a macro can be defined to turn memmove() into bcopy() if
93 <LI> Exim uses file names that are longer than 14 characters.
95 <LI> Exim is intended for use as an Internet mailer, and therefore handles
96 addresses in RFC 822 domain format only. It cannot handle 'bang paths',
97 though simple two-component bang paths can be converted by a straightforward
98 rewriting configuration.
100 <LI> Exim insists that every address it handles has a domain attached. For
101 incoming local messages, domainless addresses are automatically qualified
102 with a configured domain value. Configuration options specify from which
103 remote systems unqualified addresses are acceptable.
105 <LI> The only external transport currently implemented is an SMTP transport
106 over a TCP/IP network (using sockets), suitable for machines on the
107 Internet. However, a pipe transport is available, and there are facilities
108 for writing messages to files in 'batched SMTP' format; this can be
109 used to send messages to some other transport mechanism. Batched SMTP
110 input is also catered for.
114 <A NAME="2"><H2>4. Main features</H2></A>
117 Exim follows the same general approach of decentralised control that Smail 3
118 does. There is no central process doing overall management of mail delivery.
119 However, unlike Smail, the independent delivery processes share data in the
120 form of 'hints', which makes delivery more efficient in some cases. The hints
121 are kept in a number of DBM files. If any of these files are lost, the only
122 effect is to change the pattern of delivery attempts and retries.
125 Here is a summary of Exim's main features. More details are given in the
126 sections which follow.
129 <LI> Many configuration options can be given as expansion strings, and as
130 these can include file lookups, much of Exim's operation can be made
131 table-driven if desired. For example, it is possible to do local delivery
132 on a machine on which the users do not have accounts.
134 <LI> Regular expressions are available in a number of configuration
137 <LI> Domain lists can include file lookups, making it possible to support a
138 large number of local domains.
140 <LI> Exim has flexible retry algorithms, applicable to mail routing as well as
143 <LI> Exim contains header and envelope rewriting facilities.
145 <LI> Unqualified addresses are accepted only from specified hosts or networks.
147 <LI> Exim can perform multiple deliveries down the same SMTP channel after
148 deliveries to a host have been delayed.
150 <LI> Exim can be configured to do local deliveries immediately but to leave
151 remote deliveries until the message is picked up by a queue-runner
152 process. This increases the likelihood of multiple messages being sent
153 down a single SMTP connection.
155 <LI> When copies of a message have to be delivered to more than one remote
156 host, up to a configured maximum number of remote deliveries can be done
159 <LI> Exim supports optional checking of incoming return path (sender) and
160 receiver addresses as they are received by SMTP.
162 <LI> SMTP calls from specific machines, optionally from specific idents, can
163 be locked out, and incoming SMTP messages from specific senders can also
166 <LI> It is possible to control which hosts may use the Exim host as a relay
167 for onward transmission of mail; the control can be made to depend on the
170 <LI> Messages on the queue can be 'frozen' and 'thawed' by the administrator.
172 <LI> The maximum size of message can be specified.
174 <LI> Exim can handle a number of independent local domains on the same
175 machine; each domain can have its own alias files, etc. These are
176 commonly called "virtual domains".
178 <LI> Exim stats a user's home directory before looking for a .forward file, in
179 order to detect the case of a missing NFS mount.
181 <LI> Exim contains an optional built-in mail filtering facility. This enables
182 users to set up their own mail filtering in a straightforward manner
183 without the need to run an external program. There can also be a system
184 filter file that applies to all messages.
186 <LI> There is support for multiple user mailboxes controlled by prefixes or
187 suffixes on the user name, either via the filter mechanism or through
188 multiple .forward files.
190 <LI> Periodic warnings are automatically sent to messages' senders when
191 delivery is delayed - the time between warnings is configurable.
193 <LI> A queue run can be manually started to deliver just a particular portion
194 of the queue, or those messages with a recipient whose address contains a
197 <LI> Exim can be configured to run as root all the time, except when
198 performing local deliveries, which it always does in a separate process
199 under an appropriate uid and gid. Alternatively, it can be configured to
200 run as root only when needed; in particular, it need not run as root when
201 receiving incoming messages or when sending out messages over SMTP.
203 <LI> I have tried to make the wording of delivery failure messages clearer and
204 simpler, for the benefit of those less-experienced people who are now
207 <LI> The Exim Monitor is an optional extra; it displays information about
208 Exim's processing in an X window, and an administrator can perform a
209 number of control actions from the window interface.
213 <A NAME="3"><H2>5. Performance</H2></A>
216 Although I did not specifically set out to write a high-performance MTA, Exim
217 does seem to be fairly efficient. The busiest site I know of is an ISP that
218 handles over 40,000 messages a day on a Sun Ultra box. Our central mail
219 service machine in Cambridge (a SPARCstation-20) handles over 30,000 messages
220 on a typical day, the volume being around 130 megabytes on the day I looked.
221 The largest number of messages delivered in any one hour was 2753.
224 A system of a different character is sunsite.doc.ic.ac.uk, a SPARCserver 1000
225 system with 8 cpus, which is unusual in that virtually all mail deliveries are
226 remote and relatively large, because it is a data archive that can deliver
227 copies of its holdings via an email interface. On a fairly busy day 14,014
228 messages were received from 231 different hosts and 12,534 deliveries were
229 made to 468 different hosts. The total amount of outgoing mail was 431
230 megabytes. The largest number of deliveries in any one hour was 787.
233 <A NAME="4"><H2>6. Interface</H2></A>
236 Like many MTAs, Exim has adopted the Sendmail interface so that it can be a
237 straight replacement for /usr/lib/sendmail. All the relevant Sendmail options
238 are implemented. There are also some additional options that are compatible
239 with Smail 3, and some further options that are new to Exim.
242 The runtime configuration interface is a single file which is divided into a
243 number of sections. The entries in this file consist of keywords and values,
244 in the style of Smail 3 configuration files.
247 Control of messages on the queue can be done via certain privileged command
248 line options. There is also an optional monitor program called eximon, which
249 displays current information in an X window and contains interfaces to the
250 command line options.
253 <A NAME="5"><H2>7. Method of operation</H2></A>
256 When Exim receives a message, it writes two files in its spool directory. The
257 first contains the envelope information, the current status of the message,
258 and the headers, while the second contains the body of the message. The status
259 of the message includes a complete list of recipients and a list of those that
260 have already received the message. The header file gets updated during the
261 course of delivery if necessary.
264 A message remains in the spool directory until it is completely delivered to
265 its recipients or to an error address, or until it is deleted by an
266 administrator or by the user who originally created it. In cases when delivery
267 cannot proceed - for example, when a message can neither be delivered to its
268 recipients nor returned to its sender, the message is marked 'frozen' on the
269 spool, and no more deliveries are attempted. The administrator can thaw such
270 messages when the problem has been corrected, and can also freeze individual
271 messages by hand if necessary.
274 As delivery proceeds, Exim writes timestamped information about each address
275 to a per-message log file; this includes any delivery error messages. This log
276 is solely for the benefit of the administrator. All the information Exim
277 itself needs for delivery is kept in the header spool file. The message log
278 file is deleted with the spool files. If a message is delayed for more than a
279 configured time, a warning message is sent to the sender. This is repeated
280 whenever the same time elapses again without delivery being complete.
283 The main delivery processing elements of Exim are called directors, routers,
284 and transports. Code for a number of these is provided, and compile-time
285 options specify which ones are actually included in the binary. Directors
286 handle addresses that include one of the local domains, routers handle remote
287 addresses, and transports do actual deliveries.
290 When a message is to be delivered, the sequence of events is roughly as
294 <LI> If there is a system filter file, it is obeyed. This can check on the
295 contents of the message and its headers, and cause delivery to be
296 abandoned or directed to alternative or additional addresses.
298 <LI> Each address is parsed and a check is made to see if it is local or not,
299 by comparing the domain with the list of local domains, which can be
300 wildcarded, or even held in a file if there are a large number of them.
302 <LI> If an address is local, it is passed to each configured director in turn
303 until one is able to handle it. If none can, the address is failed.
304 Directors can be targeted at particular local domains, so several local
305 domains can be processed independently of each other.
307 <LI> A director that accepts an address may set up a local or a remote
308 transport for it, or it may generate one or more new addresses (typically
309 from alias or forward files). New addresses are fed back into this
310 process from the top, but in order to avoid loops, a director will ignore
311 any address which has an identically-named ancestor that was processed by
314 <LI> If an address is not local, it is passed to each router in turn until one
315 is able to handle it. If none can, the address is failed.
317 <LI> A router that accepts an address may set up a transport for it, or may
318 pass an altered address to subsequent routers, or it may discover that
319 the address is a local address after all. This typically happens when an
320 partial domain name is used and (for example) the DNS lookup is
321 configured to try to extend such names. In this case, the address is
322 passed back to the directors.
324 <LI> Routers normally set up remote transports for messages that are to be
325 delivered to other machines. However, a router can pass a message to a
326 local transport, and by this means messages can be routed to other
327 transport mechanisms.
329 <LI> When all the directing and routing is done, addresses that have been
330 successfully handled are passed to their assigned transports. Local
331 transports handle only one address at a time, but remote ones can handle
332 more than one. Each local transport runs in a separate process under a
335 <LI> If there were any errors, a message is returned to an appropriate address
336 (the sender in the common case).
338 <LI> If one or more addresses suffered a temporary failure, the message is
339 left on the queue, to be tried again later. Otherwise the spool files and
340 message log are deleted.
344 <A NAME="6"><H2>8. Mail filtering</H2></A>
347 Exim can be configured to allow users to set up filter files as an alternative
348 to the traditional .forward files. A filter file can test various characteristics
349 of a message, including the contents of the headers and the start of
350 the body, and direct delivery to specified addresses, files, or pipes
351 according to what it finds. The system-wide filter file uses the same control
355 <A NAME="7"><H2>9. Directors</H2></A>
358 The existing directors are listed below. I use the RFC 822 term local-part to
359 mean that portion of an address that comes before the @ character.
362 <LI> aliasfile: This director handles local-part expansion via a traditional
363 alias file. The name of the file is obtained by string expansion, and may
364 therefore depend on the local-part or the domain. Generated pipe and file
365 addresses can be (independently) locked out.
369 The aliasfile director can also be used to test a list of local parts and
370 direct any messages for them to a specific transport. In this case the
371 data associated with the local part in the file is not used for address
372 expansion, but is available for other purposes. For example, files
373 containing records of the form
376 foo: uid=1234 gid=5678 mailbox=/home_1/foo/inbox
379 could be used on a system that did local deliveries without consulting
380 its passwd file. The aliasfile director could use the file to verify that
381 the local part was valid, and then the appendfile transport could use it
382 to get a uid, gid, and mailbox for the delivery.
385 <LI> forwardfile: This director handles local-part expansion via a traditional
386 forward file or, if so configured, by a user's filter file. The name of
387 the file is obtained by string expansion, and may therefore depend on the
388 local-part or the domain, though if it is not an absolute path it is
389 automatically assumed to be in the home directory of the user whose login
390 name is the local-part. Mailing lists can be handled by file names of the
395 /some/list/directory/${local_part}
398 and it is possible to specify an error address for each list that depends
399 on the list name. Generated pipe and file addresses can be (independently)
403 <LI> localuser: This director matches the local-part of an address to a user
404 of the machine. It can also be configured to do a pattern match on the
405 user's home directory name. This makes it possible to partition the set
406 of local users according to their home directories.
408 <LI> smartuser: This director matches any local-part. It can be used to pass
409 messages for unknown users to a script that generates a helpful error
410 message, or it can be used to send such messages to another host,
411 optionally changing the envelope address in the process.
415 The configuration file determines which directors are actually used, and in
416 which order. It is possible to use the same director more than once, with
420 The addresses a director handles can be constrained in the following ways:
423 <LI> A specific set of local domains may be specified, in which case the
424 director is called only for addresses that contain one of those domains.
426 <LI> A specific set of local parts may be specified, in which case the
427 director is called only for addresses that contain one of those local
428 parts. This could be used, for example, to handle 'postmaster' independently
429 of the particular local domain.
431 <LI> A director may be configured to handle local-parts that start with a
432 certain prefix and/or end with a certain suffix. For example, a director
433 can be set up to handle local-parts of the form xxxx-request only.
435 <LI> A flag controls whether a director is called when an address is being
436 verified, as opposed to being directed for delivery.
440 In addition, certain files can be required to exist or not exist for a given
444 <A NAME="8"><H2>10. Routers</H2></A>
447 The existing routers are:
450 <LI> domainlist: This director searches a list of domains for the one it is
451 trying to route. The list may either be a string in the configuration
452 file, possibly including wild cards or regular expressions, or it may be
453 in a file, or both may be provided. In the case of a file, keys of the
454 form *.foo.bar.com can be used for simple wildcarding.
458 If the domain is found, its entry can either specify a single replacement
459 domain name that is passed on to subsequent routers, or it can specify a
460 list of domain names that are looked up by this router. The lookup can be
461 done by the gethostbyname function, or by DNS lookup, and in the latter
462 case it is configurable whether MX or A records or both are used. As well
463 as providing explicit routing for certain domains, the domainlist router
464 can be used to set up gateways for partial domains (e.g. for *.uucp) and
465 it can also be used as a 'smarthost' router by using the all-inclusive
469 <LI> lookuphost: This router looks up domain names either by calling the
470 gethostbyname function, or by using the DNS. In the latter case, it can
471 be configured to use the DNS resolver options for qualifying singlecomponent
472 names and for searching parent domains. It is also possible to
473 specify explicit text strings for widening domains that are not found
474 initially. It is possible to insist on the presence of MX records for
475 certain sets of domains. A configuration option controls whether the
476 message's headers are rewritten when a domain name is changed.
478 <LI> queryprogram: This router passes the address to a script that runs in a
479 separate process under an unprivileged uid and gid. The script returns a
480 line of text specifying whether it matched the domain or not. If it did
481 match, it may specify a transport name, or it may specify that the
482 transport specified for the router is used. The script may also send back
483 a new domain name to replace the current one, and specify a method of
484 looking this name up (gethostbyname, DNS, or pass to next router).
488 The configuration file determines which routers are actually used, and in
489 which order. It is possible to use the same router more than once, with
493 Like directors, routers can be constrained to handle only certain domains or
494 certain local parts (though I haven't seen a good use for that yet). If a
495 router times out, either the delivery can be deferred, or the address can be
496 passed on to the next router.
499 A flag controls whether a router is called when an address is being verified,
500 as opposed to being routed for delivery.
503 <A NAME="9"><H2>11. Transports</H2></A>
506 Local and remote transports are handled differently. A local transport is
507 always run in a separate process with an appropriate real uid and gid. Their
508 values can be specified in the transport's configuration, or passed over from
509 the director that handled the address. The existing transports are:
512 <LI> appendfile: This local transport appends the message to a file whose name
513 is specified as a string containing variable expansions. The current
514 local-part can be inserted via the expansion mechanism, and file names
519 /home/${local_part}/inbox<BR>
520 /var/mail/${local_part}
523 are typical examples. However, it is possible to look up each individual
524 user's inbox name in a file, should that be required.
527 Exclusive access to the file is ensured by using the traditional mailbox
528 locking strategy of creating a lock file. The lock creation process uses
529 a 'hitching post' algorithm (similar to that used by Pine) which is
530 robust when the mailbox file is NFS-mounted. The file is also locked
531 using the lockf function.
534 Options on this transport allow for the insertion of a prefix line (e.g.
535 'From xxx...') and suffix line, special processing of message lines
536 starting with 'From', and the addition of Return-path, Delivery-date, and
537 Envelope-to headers. If the mailbox file is not a regular file, or does
538 not have the correct owner, group, or permissions, no delivery takes
539 place; the address is deferred and the postmaster is informed, except
540 that, if the file's permissions are greater than those required, Exim
541 reduces the permissions and carries on. There are additional checks to
542 reduce the possibility of security exposures caused by race conditions.
545 <LI> pipe: This local transport passes the message via a pipe to a specified
546 command (program or script) which is run in a separate process under a
547 given uid and gid. Various parameters of the message are passed as
548 environment variables, and there are the same options as for appendfile
549 for controlling the form of the message.
553 The returned status of the command may be used to determine success or
554 failure, or it can be ignored. A configuration option specifies whether
555 any standard output generated by the transport is to be returned to the
556 sender. If this is set and output is actually generated, the delivery is
557 deemed to have failed, whatever the returned status of the command. The
558 maximum amount of output generated by the command can be controlled, and
559 a timeout may be set for it.
562 <LI> smtp: This remote transport delivers a message using SMTP over TCP/IP.
563 All addresses in the message that route to the same set of hosts, and
564 have the same errors address (return path), are normally sent in a single
565 transaction. An explicit list of hosts can be set for the transport, or a
566 host list may be attached to an address by one of the routers. If all the
567 hosts are temporarily unable to accept the message, it is delivered to
568 one of a list of fallback hosts, if configured.
572 <A NAME="10"><H2>12. Exim logs</H2></A>
575 Exim write four different log files:
578 <LI> The main log records the arrival of each message and the result of each
579 delivery attempt in a single line in each case. The format is as compact
580 as possible, in an attempt to keep down the size of log files. A number
581 of other events are also recorded on the main log.
583 <LI> The reject log records information from messages that are rejected
584 because their return paths are invalid (a configurable option). The
585 headers are written to this log, following a copy of the one-line message
586 that is also written to the main log. Other types of message rejection
587 also cause writing to this log.
589 <LI> The panic log is written when Exim suffers a disaster and has to bomb
592 <LI> On systems that support signal handlers that restart a system call on
593 exit, Exim reacts to a USR1 signal by writing a line describing its
594 current activity to the process log. This makes it possible to find out
595 what each exim process on a machine is currently doing.
599 A utility script for renaming and compressing the main and reject logs each
600 night is provided. There are also scripts for extracting statistics from log
601 files and for searching log files for the entries for messages that match a
602 given pattern. For example, one can pull out all entries relating to messages
603 for a given local part.
606 <A NAME="11"><H2>13. Exim databases</H2></A>
609 Exim maintains a number of databases in DBM files to help it perform efficient
610 mail delivery. In effect, the files contain hints, and if they are lost it is
611 not a disaster - Exim's performance just suffers a bit. The three databases
615 <LI> retry: This contains information about each failing remote host and
616 temporary failing local delivery - when the first failure was detected,
617 when the delivery (or directing or routing) was last tried, and when it
618 should next be tried. More details about retry algorithms are given
621 <LI> wait-smtp: This contains information about messages that are waiting for
622 particular hosts after an SMTP delivery failure (see the next section).
624 <LI> reject: This contains information about SMTP message rejections (see
629 There is a utility program that lists the contents of one of these databases,
630 and another that allows manual modifications to be applied in some cases.
631 Database records are timestamped, and there is a utility that removes records
632 that are older than a given period, and also cleans up wait-smtp records
633 containing references to messages that no longer exist. Running this daily or
634 weekly should be sufficient to keep the files reasonably tidy.
637 <A NAME="12"><H2>14. SMTP batching</H2></A>
640 When an SMTP delivery attempt fails, causing the message to be deferred till
641 later, Exim updates a DBM database that contains records keyed by host name
642 plus IP address. Each record holds a list of messages that are waiting for
643 that host and address.
646 When an SMTP delivery succeeds, Exim consults the database to see if there are
647 any other messages waiting for the same host and address. If it finds any, it
648 creates a new Exim process and passes it the open SMTP channel and a message
649 identification. The new process then delivers the waiting message down the
650 existing channel and may in turn cause the creation of yet another process.
651 Any other waiting addresses in the message are skipped. The maximum number of
652 messages sent down one connection is configurable.
655 This scheme achieves some SMTP efficiency when a number of messages have been
656 queued up for a given host, without the overhead of a heavyweight queueing
660 <A NAME="13"><H2>15. Retries</H2></A>
663 When a message cannot immediately be directed, routed, or delivered, it
664 remains on the queue and another delivery attempt occurs at a later time.
665 While failures to deliver to remote hosts are the most common cause of this,
666 it is also possible for a message to be deferred as a result of temporary
667 local delivery failure, or following directing or routing. A local delivery
668 can fail if the user is over quota, while directing can be delayed if a user's
669 home directory is not available (e.g. missing NFS mount), and therefore the
670 existence of a .forward file cannot be tested. Routing can be delayed by DNS
674 Exim can be given a set of rules which specify how often to retry deferred
675 addresses, and when to give up. These rules apply to directing and routing as
676 well as to transporting, and are keyed by (wildcarded) domain name or, for
677 local users, by local-part and domain name, either of which can be wildcarded.
680 Each rule is actually a sequential list of subrules, which are applied
681 successively as time passes. At present there are two kinds of subrule: fixed
682 interval, and geometrically increasing interval. For example, it is possible
683 to specify a rule such as 'retry every 15 minutes for 2 hours; then increase
684 the interval between retries by a factor of 1.5 each time until 8 hours have
685 passed; then retry every 8 hours until 4 days have passed; then give up'. The
686 times are measured from when the address first failed, so, for example, if a
687 host has been down for 2 days, new messages will immediately go on to the
688 8-hour retry schedule.
691 Exim does not have an elaborate series of alarm clocks to cause retries to
692 happen exactly on schedule. A queue-runner process is started periodically, to
693 attempt delivery, one by one, of messages containing addresses that have
694 passed their next retry time. If such an address fails again, a new retry time
695 is computed, and so subsequent messages queued for the same address get
696 skipped. The queue is not processed sequentially, but in a 'random' order, to
697 prevent one rogue message that causes a problem blocking other messages to the
698 same destination for ever.
701 When the maximum time for retrying has passed, pending addresses are failed.
702 However, a next try time is still computed from the final subrule. Until that
703 time is reached, any new messages for the address are immediately failed. When
704 the next try time is passed, one further delivery attempt is made; if this
705 fails, a new next try time is computed, and so on.
708 The increasing number of small computers on the Internet has caused there to
709 be a lot of messages addressed to hosts that are never going to listen. The
710 retry logic described above should reduce the amount of wasted time spent on
711 trying to deliver such messages. However, some administrators are unhappy
712 about this rather draconian approach, which can cause an address to be failed
713 without any deliveries being attempted. Exim can alternatively be configured
714 always to try at least once those hosts whose last failure was before the
715 arrival of the message. This option increases the number of attempts to
716 deliver to dead hosts.
719 Retry rules can be predicated on particular errors as well as on domain names,
720 and for domains that are looked up in the DNS, further discrimination on
721 whether MX records were used or not is also possible. Thus it is possible to
722 treat 'connection refused' and 'connection timed out' differently, or to
723 distinguish between 'connection refused and there was only an A record' and
724 'connection refused from a host pointed to by an MX record'.
727 When a local delivery fails because a user is over quota, the retry rule can
728 be predicated on the length of time since the mailbox was last read. For
729 example, if the mailbox has been recently read, the delivery can be retried
730 for a while; otherwise it can be failed quickly.
733 <A NAME="14"><H2>16. Header rewriting</H2></A>
736 There are those who argue that header rewriting is a totally Bad Thing; there
737 are others who swear they cannot live without it. Exim provides the facility -
738 you do not have to use it!
741 Exim can be configured to rewrite the address portions of headers when a
742 message is received. For debugging purposes, the original headers are retained
743 in the spool file, but are not, of course, transported with the message.
744 Rewriting rules can be targeted at individual headers and the envelope fields;
745 it is possible, for example, just to rewrite the 'From' header and no others.
748 Rewriting rules are keyed by local-part and domain, either of which can be
749 wildcarded, and the replacement text is a general expansion string which can
750 contain file lookups. This makes it possible to replace login names by
751 'friendly' names in outgoing addresses via a DBM lookup, for example. The
752 other most common rewriting requirement of replacing *.foo.bar with foo.bar is
756 Headers are also automatically rewritten by Exim in two cases:
759 <LI> If a locally-generated message contains addresses without domains, a
760 configured qualifying domain is added to each of them. It is also
761 possible to specify which remote systems are permitted to send messages
762 containing unqualified addresses. These too get qualified on reception.
764 <LI> Routing of a domain may reveal that is was only a partial domain, in
765 which case the headers are rewritten to contain the full domain. For
766 example, as a result of routing, an address such as xxx@foo may turn into
770 <A NAME="15"><H2>17. Host verification</H2></A>
774 Exim can be configured to accept incoming SMTP calls from certain hosts only,
775 or it can be configured to reject calls from certain hosts. In both cases, the
776 test may include an RFC 1413 identification check. A system that gets all its
777 mail via a central hub might want to lock out the rest of the world, while a
778 number of systems under one management might want to exchange mail only via
779 the standard mailer, and hence reject mail from all but certain specified ids
783 When a host fails the acceptance test, Exim can either give an error code
784 immediately on connection, or allow the connection to proceed and then give
785 error codes to all the message's recipients. The latter approach is useful
786 when using the mechanism to reject unsolicited junk mail and mail bombs,
787 because it normally prevents the sender from trying again with the same
791 <A NAME="16"><H2>18. SMTP port reservation</H2></A>
794 The maximum number of simultaneous incoming SMTP calls can be set, and in
795 addition, a number of them can be reserved for particular hosts or particular
796 IP networks. It is also possible to specify a system load value above which
797 only calls from the reserved hosts are accepted.
800 <A NAME="17"><H2>19. Control of relaying</H2></A>
803 A host is said to act as a relay if it accepts an incoming message from an
804 external host and delivers it to an external host. Unscrupulous persons have
805 been known to use unsuspecting hosts as relays in an attempt to disguise the
806 origin of messages. An Exim host can be configured to accept mail from any
807 host for onward transmission to a specified set of domains only, and to accept
808 mail only from a specified list of hosts or networks for onward transmission
812 <A NAME="18"><H2>20. Sender verification</H2></A>
815 The return path of a message (also known as the 'envelope sender') is used
816 when Exim has to return an error message. If this is a bad address, the error
817 message cannot be delivered, and the postmaster has to sort things out.
820 Sender verification (a configurable option that applies to SMTP input) is
821 intended to pass this work to a foreign postmaster, by refusing to accept the
822 message in the first place. There is an exception list which can specify
823 certain hosts (with optional RFC 1413 identifications) that are allowed to
827 There are two main causes of bad return paths: misconfigured mailers (gateways
828 in particular), and users fooling around with mail. Sadly, the latter are
829 rather common in educational institutions. Sender verification catches both of
830 them. It operates by passing the sender address through the directors and
831 routers in verification mode; if this fails, the message is not accepted.
834 The first thing foreign postmasters ask when they learn about a rejected
835 message is 'What were the headers?'. For this reason, and also to collect
836 evidence in cases of mail forgery, Exim does not initially reject a message
837 after the MAIL FROM command in the SMTP session. It reads the message, so as
838 to be able to write the headers to the rejection log, and then gives a hard
839 error response to the sending host.
842 Unfortunately, several mailers believe that any error response after the data
843 for a message has been sent indicates a temporary error. Consequently, such
844 mailers will continue to try to send a message that has been rejected as
845 described above. To prevent this, whenever a message is rejected, Exim records
846 the time, bad address, and host in a DBM database. If the same host sends the
847 same bad address within 24 hours, it is rejected immediately at the MAIL FROM
851 Sadly, even this doesn't stop some mailers from repeatedly trying to send the
852 message. As a last resort, if the same host sends the same bad address for a
853 third time in 24 hours, the MAIL FROM command is accepted, but all subsequent
854 RCPT TO commands are rejected. If this does not stop a remote mailer then it
858 If the attempt to verify the sender address cannot be completed (typically
859 because of a DNS timeout) Exim gives temporary error code to the MAIL FROM
860 command, which should cause the remote mailer to try again later. However, it
861 is possible to configure Exim to accept the message in these circumstances.
864 Many messages with bad return paths in fact contain perfectly valid 'From' or
865 'Reply-to' headers. For administrators that want a quieter life, there is a
866 configuration option which causes Exim to check these headers if the return
867 path is bad, and if a good address is found, to use it to replace the return
868 path. The old value is retained in an X- header.
871 <A NAME="19"><H2>21. Sender lock out</H2></A>
874 More and more unsolicited junk mail is being seen on the Internet. It is
875 sometimes useful to be able to reject messages (from any host) with particular
876 sender addresses in the envelope. Exim can be configured to reject messages
877 whose sender addresses match certain patterns, either by failing the MAIL FROM
878 command, or (because some mailers take no notice of that) by failing all RCPT
882 <A NAME="20"><H2>22. Receiver verification</H2></A>
885 Exim can be configured so that it checks the addresses given in incoming SMTP
886 RCPT TO commands as they are received. A failing address can be immediately
887 rejected, or it can be logged and accepted. If verification cannot be
888 completed (typically because of a DNS timeout) either a temporary error code
889 can be given, or the address can be logged and accepted.
892 <A NAME="21"><H2>23. The 'percent hack'</H2></A>
895 The so-called 'percent hack' is the feature of mailers whereby a local-part
896 containing a percent sign gets interpreted as an entire new address, with the
897 percent replaced by @. This is used for explicit mail routing and sometimes
898 for testing. In Exim, it is possible to configure which local domains, if any,
899 allow the 'percent hack'.
902 <A NAME="22"><H2>24. Security</H2></A>
905 Exim is written as a single binary that has to run setuid to root. I did start
906 off trying to write it as a number of different modules, but soon came to the
907 conclusion that, for this type of mailer, it was not worth it, because the
908 functions don't decompose cleanly. For example, if you want to verify
909 addresses while receiving mail you need all the directing and routing
910 apparatus to be available.
913 Exim runs each local delivery in a separate process which is setuid to the
914 relevant local user. In addition, it can be configured to run under a given
915 non-root uid (and gid) for much of the rest of the time. In particular, it
916 need not be root while sending or receiving SMTP mail. On systems that do not
917 have the seteuid function, it uses setuid to give up root, which requires it
918 to re-invoke itself in order to regain the privilege when it needs to deliver
919 a message. On systems that do have seteuid, it can be configured to use that
920 function instead, thereby saving some resources.
923 Exim can be configured to use seteuid (on systems that have it) when reading a
924 .forward file in a user's home directory. This is necessary when home
925 directories are NFS mounted without root privilege, unless .forward files are
926 required to be world readable.
929 Exim checks the permissions and owners of files to which messages are to be
930 appended, and refuses to proceed with the delivery if things are not right.
933 Delivery of messages to pipes or files is supported only as a result of
934 expanding an address via an alias or a forward file, provided this is
935 permitted by the configuration. Externally generated local addresses cannot
936 specify files or pipes - no special action is taken for addresses starting
937 with the file or pipe characters, so they will usually fail.
940 Use of the VRFY function in SMTP connections is controlled by a configuration
941 option. The EXPN and DEBUG functions are not supported at all.
944 <A NAME="23"><H2>25. The Exim Monitor</H2></A>
947 A program for monitoring Exim and displaying information in an X window is
948 provided. This can be configured to show stripcharts of incoming and outgoing
949 mail in various categories. It also shows a 'tail' of the main log file, and
950 information about messages on the queue.
953 There is a menu of operations that can be performed by suitably privileged
954 users. Messages can be frozen, thawed, deleted, caused to be delivered,
955 modified, or returned to their senders from this interface.
958 <address><a href="mailto:Postmaster@exim.org">Nigel Metheringham</a></address>
959 <!-- Created: Sun May 16 21:43:01 BST 1999 -->
git://git.exim.org / exim-website.git / blob