Ftp Web Hosting - J2Ee Hosting Sun Java Developing Blog

News begins when users create and post articles. Each user enters a message into a special application called a newsreader, which formats it appropriately for transmission to the local news server. In Unix environments the newsreader commonly uses the inews command to transmit articles to the newsserver using the TCP/IP protocol. But it’s also possible to write the article directly into a file in a special directory called the news spool. Once the posting is delivered to the local news server, it takes responsibility for delivering the article to other news users. News is distributed through the net by various transports. The medium used to be UUCP, but today the main traffic is carried by Internet sites. The routing algorithm used is called flooding. Each site maintains a number of links (news feeds) to other sites. Any article generated or received by the local news system is forwarded to them, unless it has already been at that site, in which case it is discarded. A site may find out about all other sites the article has already traversed by looking at the Path: header field. This header contains a list of all systems through which the article has been forwarded in bang path notation. To distinguish articles and recognize duplicates, Usenet articles have to carry a message ID (specified in the Message-Id: header field), which combines the posting site’s name and a serial number into . For each article processed, the news system logs this ID into a history file, against which all newly arrived articles are checked. The flow between any two sites may be limited by two criteria. For one, an article is assigned a distribution (in the Distribution: header field), which may be used to confine it to a certain group of sites. On the other hand, the newsgroups exchanged may be limited by both the sending and receiving systems. The set of news- groups and distributions allowed to be transmitted to a site are usually kept in the sys file. The sheer number of articles usually requires that improvements be made to the above scheme. On UUCP networks, systems collect articles over a period of time and combine them into a single file, which is compressed and sent to the remote site. This is called batching. An alternative technique is the ihave/sendme protocol that prevents duplicate articles from being transferred, thus saving net bandwidth. Instead of putting all articles in batch files and sending them along, only the message IDs of articles are combined into a giant “ihave” message and sent to the remote site. The remote site reads this message, compares it to its history file, and returns the list of articles it wants in a “sendme” message. Only the requested articles are sent. Of course, ihave/sendme makes sense only if it involves two big sites that receive news from several independent feeds each, and that poll each other often enough for an efficient flow of news. Sites that are on the Internet generally rely on TCP/IP-based software that uses the Network News Transfer Protocol (NNTP). NNTP is described in RFC-977; it is responsible for the transfer of news between news servers and provides Usenet access to single users on remote hosts. NNTP knows three different ways to transfer news. One is a real-time version of ihave/sendme, also referred to as pushing news. The second technique is called pulling news, in which the client requests a list of articles in a given newsgroup or hierarchy that have arrived at the server’s site after a specified date, and chooses those it cannot find in its history file. The third technique is for interactive newsreading and allows you or your news- reader to retrieve articles from specified newgroups, as well as post articles with incomplete header information. At each site, news is kept in a directory hierarchy below /var/spool/news, each article in a separate file, and each newsgroup in a separate directory. The directory name is made up of the newsgroup name, with the components being the path components. Thus, comp.os.linux.misc articles are kept in /var/spool/news/comp/os/linux/misc. The articles in a newsgroup are assigned numbers in the order they arrive. This number serves as the file’s name. The range of numbers of articles currently online is kept in a file called active, which at the same time serves as a list of newsgroups your site knows. Since disk space is a finite resource, you have to start throwing away articles after some time.123 This is called expiring. Usually, articles from certain groups and hierarchies are expired at a fixed number of days after they arrive. This may be overridden by the poster by specifying a date of expiration in the Expires: field of the article header. You now have enough information to choose what to read next. UUCP users should read about C-News in Chapter 21. If you’re using a TCP/IP network, read about NNTP in Chapter 22. If you need to transfer moderate Some people claim that Usenet is a conspiracy by modem and hard disk vendors.

It is very similar to the mail header format laid down in the Internet mail standard RFC-822, in that it consists of several lines of text, each beginning with a field name terminated by a colon, which is followed by the field’s value.121 Articles are submitted to one or more newsgroup. One may consider a newsgroup a forum for articles relating to a common topic. All newsgroups are organized in a hierarchy, with each group’s name indicating its place in the hierarchy. This often makes it easy to see what a group is all about. For example, anybody can see from the newsgroup name that comp.os.linux.announce is used for announcements concerning a computer operating system named Linux. These articles are then exchanged between all Usenet sites that are willing to carry news from this group. When two sites agree to exchange news, they are free to exchange whatever newsgroups they like, and may even add their own local news hierarchies. For example, groucho.edu might have a news link to barnyard.edu, which is a major news feed, and several links to minor sites which it feeds news. Now Barnyard College might receive all Usenet groups, while GMU only wants to carry a few major hierarchies like sci, comp, or rec. Some of the downstream sites, say a UUCP site called brewhq, will want to carry even fewer groups, because they don’t have the network or hardware resources. On the other hand, brewhq might want to receive newsgroups from the fj hierarchy, which GMU doesn’t carry. It therefore maintains another link with gargleblaster.com, which carries all fj groups and feeds them to brewhq. The news flow is shown in Figure 20.1. Figure 20.1: Usenet newsflow through Groucho Marx University The labels on the arrows originating from brewhq may require some explanation, though. By default, it wants all locally generated news to be sent to groucho.edu. However, as groucho.edu does not carry the fj groups, there’s no point in sending it any messages from those groups. Therefore, the feed from brewhq to GMU is labeled all,!fj, meaning that all groups except those below fj are sent to it. How Does Usenet Handle News? Today, Usenet has grown to enormous proportions. Sites that carry the whole of Netnews usually transfer something like a paltry 60 MB a day.122 Of course, this requires much more than pushing files around. So let’s take a look at the way most Unix systems handle Usenet news. 121 The format of Usenet news messages is specified in RFC-1036, “Standard for interchange of USENET messages.” 122 Wait a minute: 60 Megs at 9,600 bps, that’s 60 million multiplied by 1,024, that is… mutter, mutter… Hey! That’s 34 hours!

Chapter 20 - Netnews Netnews, or Usenet news, remains one of the most important and highly valued services on computer networks today. Dismissed by some as a mire of unsolicited commercial email and pornography, Netnews still maintains several cases of the high-quality discussion groups that made it a critical resource in pre-web days. Even in these times of a billion web pages, Netnews is still a source for online help and community on many topics. Usenet History The idea of network news was born in 1979 when two graduate students, Tom Truscott and Jim Ellis, thought of using UUCP to connect machines for information exchange among Unix users. They set up a small network of three machines in North Carolina. Initially, traffic was handled by a number of shell scripts (later rewritten in C), but they were never released to the public. They were quickly replaced by “A News,” the first public release of news software. A News was not designed to handle more than a few articles per group and day. When the volume continued to grow, it was rewritten by Mark Horton and Matt Glickman, who called it the “B” release (a.k.a. B News). The first public release of B News was version 2.1 in 1982. It was expanded continuously, with several new features added. Its current version is B News 2.11. It is slowly becoming obsolete; its last official maintainer switched to INN. Geoff Collyer and Henry Spencer rewrote B News and released it in 1987; this is release “C,” or C News. Since its release, there have been a number of patches to C News, the most prominent being the C News Performance Release. On sites that carry a large number of groups, the overhead involved in frequently invoking relaynews, which is responsible for dispatching incoming articles to other hosts, is significant. The Performance Release adds an option to relaynews that allows it to run in daemon mode, through which the program puts itself in the background. The Performance Release is the C News version currently included in most Linux releases. We describe C News in detail in Chapter 21, C News. All news releases up to C were primarily targeted for UUCP networks, although they could be used in other environments, as well. Efficient news transfer over networks like TCP/IP or DECNet required a new scheme. So in 1986, the Network News Transfer Protocol (NNTP) was introduced. It is based on network connections and specifies a number of commands to interactively transfer and retrieve articles. There are a number of NNTP-based applications available from the Net. One of them is the nntpd package by Brian Barber and Phil Lapsley, which you can use to provide newsreading service to a number of hosts inside a local network. nntpd was designed to complement news packages, such as B News or C News, to give them NNTP features. If you want to use NNTP with the C News server, you should read Chapter 22, NNTP and the nntpd Daemon, which explains how to configure the nntpd daemon and run it with C News. An alternative package supporting NNTP is INN, or Internet News. It is not just a frontend, but a news system in its own right. It comprises a sophisticated news relay daemon that can maintain several concurrent NNTP links efficiently, and is therefore the news server of choice for many Internet sites. We discuss it in detail in Chapter 23, Internet News. What Is Usenet, Anyway? One of the most astounding facts about Usenet is that it isn’t part of any organization, nor does it have any sort of centralized network management authority. In fact, it’s part of Usenet lore that except for a technical description, you cannot define what it is; at the risk of sounding stupid, one might define Usenet as a collaboration of separate sites that exchange Usenet news. To be a Usenet site, all you have to do is find another Usenet site and strike an agreement with its owners and maintainers to exchange news with you. Providing another site with news is called feeding it, whence another common axiom of Usenet philosophy originates: “Get a feed, and you’re on it.” The basic unit of Usenet news is the article. This is a message a user writes and “posts” to the net. In order to enable news systems to deal with it, it is prepended with administrative information, the so-called article header.

there is a problem, uux will generate some output and terminate with a non-zero error code. The setting of return_ fail_output makes sure that the output is returned to the sender. If incoming UUCP messages are grouped into files in batched SMTP format, they can be passed directly to Exim using a command like this: exim -bS

Protecting Against Mail Spam Mail spam, or unsolicited email advertising, is an annoying problem for many users. A project has been formed to address this problem called the Mail Abuse Protection System (MAPS), and a mechanism has been built that reduces the problem, called the Real Time Blackhole List (RBL). Information on how the MAPS RBL works can be obtained from its online documentation at http://maps.vix.com/rbl/. The idea is simple. Sites that are caught generating mail spam are added into the database and mail transfer agents like Exim are able to query the database to confirm that a source is not a spammer before accepting mail from it. Since the advent of the RBL, several other similar lists have been created. One of the most useful is the Dial-Up List (DUL), which lists the IP addresses of dial-up hosts. These should normally send outgoing mail only to their ISP’s mail servers. Many sites block mail from external dial-ups because when such a host avoids its own ISP’s server, it is usually up to no good. Exim provides support for the real-time and other blacklists. It is very easily configured. To enable it, add the following lines to your /etc/exim.conf file: # Vixie / MAPS RBL (http://maps.vix.com/rbl) rbl_domains = rbl.maps.vix.com : dul.maps.vix.com This example checks both the RBL and the DUL, rejecting any messages from hosts that are on either list. The rbl_hosts option allows you to specify groups of hosts to which RBL checking does (or does not) apply. The default setting is: rbl_hosts = * which means that all hosts are subject to RBL checking. If you wanted to override blacklisting and accept mail from a specific host without performing the RBL checking you could, for example, use: rbl_hosts = ! nocheck.example.com : * The exclamation mark before the first item in this list indicates a negated item: if the calling host is no- check.example.com, it will match this item. But because of the negation, RBL checking is not performed. Any other host matches the second item in the list. UUCP Setup Exim does not have any specific code for transporting mail via UUCP, nor does it support UUCP bang path addresses. However, if domain addressing is being used, Exim can be interfaced to UUCP fairly simply. Here is a configuration fragment for sending certain domains to UUCP, taken from a real installation: # 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 = domainlist route_file = /usr/exim/uucphosts search_type = lsearch In a complete configuration file, the transport would be inserted among the other transports, and the router probably defined as the first router. The file /usr/exim/uucphosts contains entries like this: darksite.example.com: darksite.UUCP which is interpreted to mean, “Send mail addressed to the domain darksite.example.com to the UUCP host darksite.” This configuration could be set up more simply without the router adding the suffix .UUCP to dark- site only to have the transport take it off again, but this way is useful because it makes clear the distinction between the domain name darksite.example.com and the UUCP host name darksite. Whenever the router comes across a domain that is in the route file, it will send the address to the UUCP transport, which subsequently pipes it to the uux command (described in Chapter 16, Managing Taylor UUCP). If

recipients is a comma-separated list of addresses that will be substituted for the alias. The recipient list may be continued across newlines if the next line begins with whitespace. A special feature allows Exim to handle mailing lists that are held separately from the alias file: if you specify :include:filename as a recipient, Exim reads the specified file and substitutes its contents as a list of recipients. An alternative to handling mailing lists is shown later in this chapter in “Mailing Lists”. The main aliases file is /etc/aliases. If you make this file world-writable or group-writeable, Exim will refuse to use it and will defer local deliveries. You can control the test it applies to the file’s permissions by setting mode- mask in the system_aliases director. This is a sample aliases file: # vbrew.com /etc/aliases file hostmaster: janet postmaster: janet usenet: phil # The development mailing list. development: joe, sue, mark, biff, /var/mail/log/development owner-development: joe # Announcements of general interest are mailed to all # of the staff announce: :include: /etc/Exim/staff, /var/mail/log/announce owner-announce: root # gate the ppp mailing list to a local newsgroup ppp-list: “|/usr/local/bin/gateit local.lists.ppp” When there are file names and pipe commands in an alias file, as here, Exim needs to be told which userid to run the deliveries under. The user option (and possibly group, too) must be set in Exim’s configuration file, either on the director that is handling the aliases, or on the transports to which it directs these items. If an error occurs while delivering to an address generated from the aliases file, Exim will send a bounce message to the sender of the message, as usual, but this might not be appropriate. The errors_to option can be used to specify that bounce messages are to be sent elsewhere; for example, to the postmaster. Mailing Lists Instead of the aliases file, mailing lists may also be managed by means a forwardfile director. The lists are all kept in a single directory such as /etc/exim/lists/, and a mailing list named nag-bugs is described by the file lists/nag-bugs. This should contain the members’ addresses separated by commas or newlines. Lines beginning with a hash sign (#) are treated as comments. A simple director to use such data is as follows: lists: driver = forwardfile file = /etc/exim/lists/${local_part} no_check_local_user errors_to = ${local_part}-request When this director runs, the values of the file and errors_to options are expanded. Expansion causes certain portions of the strings beginning with dollar characters to be replaced every time the string is used. The simplest kind of expansion is the insertion of the value of one of Exim’s variables, and this is what is happening here. The substring ${local_part} substitutes the value of the $local_part, which is the local part of the address that is being processed. For each mailing list, a user (or alias or mailing list) named listname-request should exist; any errors occurring when resolving an address or delivering to a list member are reported to this address.

Similarly, a pipe command may be any Unix command preceded by the pipe symbol (|), unless the string parses as a valid email address complete with domain. Unless you have changed the configuration, Exim does not use a shell to run the command; instead, it splits it up into a command name, arguments itself, and runs it directly. The message is fed to the command on its standard input. For example, to gate a mailing list into a local newsgroup, you might use a shell script named gateit, and set up a local alias that delivers all messages from this mailing list to the script using |gateit. If the command line contains a comma, it and the preceding pipe symbol must be enclosed in double quotes. Local users A local address most commonly denotes a user’s mailbox. This is normally located in /var/spool/mail and has the name of the user, who also owns the file. If it does not exist, it is created by Exim. In some configurations, the group is set to the user’s group and the mode is 0600. In these cases, delivery processes are run as the user, and the user may delete the mailbox entirely. In other configurations, the mailbox’s group is mail, and it has mode 660; delivery processes are run under a system uid and group mail, and users cannot delete their mailbox files, though they can empty them. Note that although /var/spool/mail is currently the standard place to put the mailbox files, some mail software may be compiled to use different paths, for example, /usr/spool/mail. If delivery to users on your machine fails consistently, you should see if it helps to make this a symbolic link to /var/spool/mail. The addresses MAILER-DAEMON and postmaster should normally appear in your alias file, expanding into the email address of the system administrator. MAILER-DAEMON is used by Exim as the sender address in bounce messages. It is also recommended that root be set up as an alias for an administrator, especially when deliveries are being run under the permissions of the recipient users, in order to avoid running any delivery as root. Forwarding Users can redirect their mail to alternative addresses by creating a .forward file in their home directories. This contains a list of recipients separated by commas and/or newlines. All lines of the file are read and interpreted. Any type of address may be used. A practical example of a .forward file for vacations might be: janet, “|vacation” In other descriptions of .forward files, you might see the username at the start preceded by a backslash. This was necessary in some older MTAs to stop a search for a .forward for the new name, which could lead to looping. The backslash is not necessary in Exim, which automatically avoids loops of this kind.119 However, a backslash is permitted, and in fact it does make a difference in configurations where several domains are being handled at once. Without a backslash, an unqualified username is qualified with a default domain; with a backslash the incoming domain is preserved. The first address in the forward file delivers the incoming message to janet’s mailbox, while the vacation command returns a short notification to the sender.120 In addition to supporting “traditional” forwarding files, Exim can be configured to allow more complex files called filters. Instead of being just a list of forwarding addresses, a filter file can contain tests on the contents of the incoming message so that, for example, messages could be forwarded only if the subject contained the message “urgent.” The system administrator must decide whether to allow users this flexibility. Alias Files Exim is able to handle alias files compatible with Berkeley’s sendmail alias files. Entries in the alias file can have the following form: alias: recipients 119 A director is skipped if the address it is about to process is one that it has previously processed in the course of generating the present address. 120 Please, if you choose to use a vacation program, make sure it will not reply to messages sent from mailing lists! It is very annoying to discover that someone has gone on vacation and find a vacation message for every message they’ve received. Mailing list administrators: this is a good example of why it is bad practice to force the Reply-To: field of mailing list messages to that of the list submission address.

Message Routing and Delivery Exim splits up mail delivery into three different tasks: routing, directing, and transporting. There are a number of code modules of each type, and each is separately configurable. Usually a number of different routers, directors, and transports are set up in the configuration file. Routers resolve remote addresses, determining which host the message should be sent to and which transport should be used. In Internet-connected hosts there is often just one router, which does the resolution by looking up the domain in the DNS. Alternatively, there may be one router that handles addresses destined for hosts on a local LAN, and a second to send any other addresses to a single smart host; for example, an ISP’s mail server. Local addresses are given to the directors, of which there are normally several, to handle aliasing and forwarding as well as identifying local mailboxes. Mailing lists can be handled by aliasing or forwarding directors. If an address gets aliased or forwarded, any generated addresses are handled independently by the routers or directors, as necessary. By far the most common case will be delivery to a mailbox, but messages may also be piped into a command or appended to a file other than the default mailbox. A transport is responsible for implementing a method of delivery; for example, sending the message over an SMTP connection or adding it to a specific mailbox. Routers and directors select which transport to use for each recipient address. If a transport fails, Exim either generates a bounce message or defers the address for a later retry. With Exim, you have a lot of freedom in configuring these tasks. For each of them, a number of drivers are available, from which you can choose those you need. You describe them to Exim in different sections of its configuration file. The transports are defined first, followed by the directors, and then the routers. There are no built-in defaults, though Exim is distributed with a default configuration file that covers simple cases. If you want to change Exim’s routing policy or modify a transport, it is easiest to start from the default configuration and make changes rather than attempt to set up a complete configuration from scratch. Routing Messages When given an address to deliver, Exim first checks whether the domain is one that is handled on the local host by matching it against a list in the local_domains configuration variable. If this option is not set, the local host name is used as the only local domain. If the domain is local, the address is handed to the directors. Otherwise, it is handed to the routers to find out which host to forward a message to.118 Delivering Messages to Local Addresses Most commonly, a local address is just a user’s login name, in which case the message is delivered to the user’s mailbox, /var/spool/mail/user-name. Other cases include aliases, mailing list names, and mail forwarding by the user. In these cases, the local address expands to a new list of addresses, which may be either local or remote. Apart from these “normal” addresses, Exim can handle other types of local message destinations, like filenames and pipe commands. When delivering to a file, Exim appends the message, creating the file if necessary. File and pipe destinations are not addresses in their own right, so you can’t send mail to, say, /etc/passwd@vbrew.com and expect to overwrite the password file; deliveries to a specific file are valid only if they come from forwarding or alias files. Note, however, that /etc/passwd@vbrew.com is a syntactically valid email address, but if Exim received it, it would (typically) search for a user whose login name was /etc/passwd, fail to find one, and bounce the message. In an alias list or forwarding file, a filename is anything that begins with a slash (/) that does not parse as a fully qualified email address. For example, /tmp/junk in a forwarding or alias file is interpreted as a file name, but /tmp/junk@vbrew.com is an email address, though it is not likely to be a very useful one. However, valid addresses of this type are seen when sending mail through X.400 gateways, because X.400 addresses start with a slash. This is a simplification. It is possible for directors to pass addresses to transports that deliver to remote hosts, and similarly, it is possible for routers to pass addresses to local transports that write the messsage to a file or a pipe. It is also possible for routers to pass addresses to the directors in some circumstances.

q15m option on the command line to process the queue every 15 minutes. You can also invoke exim -q from cron at these intervals. You can display the current mail queue by invoking Exim with the -bp option. Equivalently, you can make mailq a link to Exim, and invoke mailq: $ mailq 2h 52K 12EwGE-0005jD-00 D bob@vbrew.com harry@example.net This shows a single message from sam@vbrew.com to two recipients sitting in the message queue. It has been successfully delivered to bob@vbrew.com, but has not yet been delivered to harry@example.net, though it has been on the queue for two hours. The size of the message is 52K, and the ID by which Exim identifies this message is 12EwGE-0005jD-00. You can find out why the delivery is not yet complete by looking at the message’s individual log file, which is kept in the msglog directory in Exim’s spool directory. The -Mvl option is an easy way of doing this: $ exim -Mvl 12EwGE-0005jD-00 2000-01-30 17:28:13 example.net [192.168.8.2]: Connection timed out 2000-01-30 17:28:13 harry@example.net: remote_smtp transport deferred: Connection timed out Individual log files keep a copy of log entries for each message so you can easily inspect them. The same information could have been extracted from the main log file using the exigrep utility: $ exigrep 12EwGE-0005jD-00 /var/log/exim/exim_mainlog That would take longer, especially on a busy system where the log files can get quite big. The exigrep utility comes into its own when looking for information about more than one message. Its first argument is a regular expression, and it picks out all the log lines concerned with any messages that have at least one log line that matches the expression. Thus it can be used to pick out all messages for one specific address, or all those to or from a specific host. You can keep a general watch on what a running Exim is doing by running tail on its main log file. Another way of doing this is to run the eximon utility that comes with Exim. This is an X11 application that puts up a scrolling display of the main log, and also shows a list of messages that are awaiting delivery, as well as some stripcharts about delivery activity. Miscellaneous config Options Here are a few of the more useful options you can set in the configuration file: message_size_limit Setting this option limits the size of message that Exim will accept. return_size_limit Setting this option limits the amount of an incoming message that Exim will return as part of a bounce message. deliver_load_max If the system load exceeds the value given for this option, all mail delivery is suspended, though messages are still accepted. smtp_accept_max This is the maximum number of simultaneous incoming SMTP calls Exim is prepared to accept. log_level This option controls the amount of material that is written to the log. There are also some options with names beginning with log_ that control the logging of specific information.

These entries show that a message from jack@vstout.vbrew.com to jill@vbrew.com was successfully delivered to a mailbox on the local host. Message arrivals are flagged with <=, and deliveries with =>. There are two kinds of delivery errors: permanent and temporary. A permanent delivery error is recorded in a log entry like this, flagged with “**”: 2000-01-30 14:48:28 12EvcH-0003rC-00 ** bill@lager.vbrew.com R=lookuphost T=smtp: SMTP error from remote mailer after RCPT TO: : host lager.vbrew.com [192.168.157.2]: 550 … User unknown After a failure like this, Exim sends a delivery failure report, often called a bounce message back to the sender. Temporary errors are flagged with “==”: 2000-01-30 12:50:50 12E9Un-0004Wq-00 == jim@bitter.vbrew.com T=smtp defer (145): Connection timed out This error is typical for a situation in which Exim properly recognizes that the message should be delivered to a remote host, but is not able to connect to the SMTP service on that host. The host may be down or there could be a network problem. Whenever a message is deferred like this, it remains on Exim’s queue and is retried at intervals. However, if it fails to be delivered for a sufficiently long time (usually several days), a permanent error occurs and the message is bounced. If you are unable to locate your problem from the error message Exim generates, you may want to turn on debugging messages. You can do this using the -d flag, optionally followed by a number specifying the level of verbosity (a value of 9 gives maximum information). Exim then displays a report of its operation on the screen, which may give you more hints about what is going wrong. Compiling Exim Exim is still under active development; the version of Exim included in Linux distributions is probably not the latest release. If you need a feature or a bugfix found in a later release, you have to obtain a copy of the source code and compile it yourself. The latest release can be found via Exim’s web page at http://www.exim.org/. Linux is one of the many operating systems supported by the Exim source. To compile Exim for Linux, you should edit the src/EDITME file and put the result in a file called Local/Makefile. There are comments in src/EDITME that tell you what the various settings are used for. Then run make. See the Exim manual for detailed information on building Exim from source. Mail Delivery Modes As noted previously, Exim is able to deliver messages immediately or queue them for later processing. All incoming mail is stored in the input directory below /var/spool/exim. When queueing is not in operation, a delivery process is started for each message as soon as it arrives. Otherwise, it is left on the queue until a queue-runner process picks it up. Queueing can be made unconditional by setting queue_only in the configuration file, or it can be conditional on the 1-minute system load by a setting such as: queue_only_load = 4 which causes messages to be queued if the system load exceeds 4.117 If your host is not permanently connected to the Internet, you may want to turn on queueing for remote addresses, while allowing Exim to perform local deliveries immediately. You can do this by setting: queue_remote_domains = * in the configuration file. If you turn on any form of queuing, you have to make sure the queues are checked regularly, probably every 10 or 15 minutes. Even without any explicit queueing options, the queues need to be checked for messages that have been deferred because of temporary delivery failures. If you run Exim in daemon mode, you must add the The system load is a standard Unix measure of the average number of processes that are queued up, waiting to run. The uptime shows load averages taken over the previous 1, 5, and 15 minutes.