This is the main configuration question which will control which of the remaining questions are presented to you. It also controls things like daemon invocation and delivery of outgoing mail.

The "mail name" is the domain name used to "qualify" mail addresses without a domain name.

This name will also be used by other programs. It should be the single, full domain name (FQDN).

For example, if a mail address on the local host is foo@example.org, then the correct value for this option would be example.org.

Exim, as a rule, handles only fully qualified mail addresses, that is, addresses with a local part, an @ sign and a domain. If confronted with an unqualified address, that is, one without @ sign and without domain, first thing exim does is qualify the address by adding the @ sign and a domain.

This qualification happens for all addresses exim encounters, be it sender, recipient or else.

The domain name used to qualify unqualified mail addresses is called ``mail name'' on Debian systems and entered in this debconf dialog. What you enter here will end up in /etc/mailname, which is a file that might be used by other programs as well.

In some configuration types, the package configuration will offer you, at a later step, to hide this name from outgoing messages by rewriting the headers.

Please enter a semicolon-separated list of IP addresses. The Exim SMTP listener daemon will listen on all IP addresses listed here.

An empty value will cause Exim to listen for connections on all available network interfaces.

If this system does only receive e-mail directly from local services (and not from other hosts), it is suggested to prohibit external connections to the local Exim daemon. Such services include e-mail programs (MUSs) which talk to localhost only as well as fetchmail. External connections are impossible when 127.0.0.1 is entered here, as this will disable listening on public network interfaces.

Do not change this unless you know what you are doing. Altering this value could post a security risk to your system. For most users, the default value is sufficient.

Please enter a semicolon-separated list of recipient domains for which this machine should consider itself the final destination. These domains are commonly called 'local domains'. The local hostname and 'localhost' are always added to the list given here.

By default all local domains will be treated identically. If both a.example and b.example are local domains, acc@a.example and acc@b.example will be delivered to the same final destination. If different domain names should be treated differently, it is necessary to edit the config files afterwards.

The answer to this question ends up in the list of domains that Exim will consider local domains. Mail for recipients in one of these domains will be subject to local alias expansion and then delivered locally in the appropriate configuration types.

Please enter a semicolon-separated list of recipient domains for which this system will relay mail, for example as a fallback MX or mail gateway. This means that this system will accept mail for these domains from anywhere on the Internet and deliver them according to local delivery rules.

Do not mention local domains here. Wildcards may be used.

The answer to this question is a list of the domains for which Exim will relay messages coming in from anywhere on the Internet.

Please enter a semicolon-separated list of IP address ranges for which this system will unconditionally relay mail, functioning as a smarthost.

You should use the standard address/prefix format (e.g. 194.222.242.0/24 or 5f03:1200:836f::/48).

If this system should not be a smarthost for any other host, leave this list blank.

Please note that systems not listed here can still use SMTP AUTH to relay through this system. If this system only has clients on dynamic IP addresses that use SMTP AUTH, leave this list blank as well. Do NOT list 0.0.0.0/0!

Please enter the IP address or the host name of a mail server that this system should use as outgoing smarthost. If the smarthost only accepts your mail on a port different from TCP/25, append two colons and the port number (for example smarthost.example::587 or 192.168.254.254::2525). Colons in IPv6 addresses need to be doubled.

If the smarthost requires authentication, please refer to Section 2.3, “SMTP-AUTH” for notes about setting up SMTP authentication.

Multiple smarthost entries are permitted, semicolon separated. Each of the hosts is tried, in the order specified (See Exim specification, chapter 20.5).

The headers of outgoing mail can be rewritten to make it appear to have been generated on a different system, replacing the local host name in From, Reply-To, Sender and Return-Path.

If you ask Exim to hide the local mail name in outgoing mail, it will next ask you for the domain name that should be visible for your local users. These information is then used to establish the appropriate rewriting rules.

In normal mode of operation Exim does DNS lookups at startup, and when receiving or delivering messages. This is for logging purposes and allows keeping down the number of hard-coded values in the configuration.

If this system does not have a DNS full service resolver available at all times (for example if its Internet access is a dial-up line using dial-on-demand), this might have unwanted consequences. For example, starting up Exim or running the queue (even with no messages waiting) might trigger a costly dial-up-event.

This option should be selected if this system is using Dial-on-Demand. If it has always-on Internet access, this option should be disabled.

Exim is able to store locally delivered mail in different formats. The most commonly used ones are mbox and Maildir. mbox uses a single file for the complete mail folder stored in /var/mail/. With Maildir format every single message is stored in a separate file in ~/Maildir/.

Please note that most mail tools in Debian expect the local delivery method to be mbox in their default.

Our packages offer two (actually three, see Section 2.1.6, “Using a completely different configuration scheme”) possibilities:

Splitting the configuration across multiple files means that you have the actual configuration file automatically generated from the files below /etc/exim4/conf.d/ by invoking update-exim4.conf. Each section of Exim's configuration has its own subdirectory and the files in there are supposed to be read in alphanumeric order. router/00_exim4-config_header is followed by router/100_exim4-config_domain_literal, ...

If you chose unsplit configuration, update-exim4.conf builds the configuration from /etc/exim4/exim4.conf.template, which is basically the files from /etc/exim4/conf.d/ concatenated together at package build time, and thus guarantees consistency on the target system.

In both cases, update-exim4.conf generates exim configuration macros from the debconf configuration values and puts them into the actual configuration file, which is then used by the Exim daemon. See the update-exim4.conf manual page for more in-depth information about this mechanism.

Benefits of the split configuration approach:

Drawbacks of the split configuration approach:

Benefits of the unsplit configuration approach:

Drawbacks of the unsplit configuration approach:

If in doubt go for the unsplit config, because it is easier to roll back to Debian's default configuration in one step. If you intend to do many changes to the Debian setup, you might want to use the split config at the price of having to more closely examine the config file after an update.

We'd appreciate a patch that uses ucf and the 3-way-merge mechanism offered by that package. It might be the best way to handle the big configuration file.

If you are using unsplit configuration, have local changes to /etc/exim4/conf.d/ (either made by yourself or by other packages dropping their own routers or transports in) and want to re-generate /etc/exim4/exim4.conf.template to activate these changes, you can do so by using update-exim4.conf.template.

If you want to modify parameters that are supported by the debconf configuration, things are easy. Just invoke dpkg-reconfigure exim4-config or hand-edit /etc/exim4/update-exim4.conf.conf to your liking and restart Exim.

You can find explanation of the debconf questions in Section 2.1.1, “The Debconf questions”. Additionally, /etc/exim4/update-exim4.conf.conf is documented in the update-exim4.conf man page.

Some aspects of the Debian Exim configuration can be controlled by Exim macros. To find out about these, you need basic understanding of Exim configuration. Just look in our Exim configuration and see which macro needs to be set to a different value to alter Exim's behavior.

Section 2.1.3, “Using Exim Macros to control the configuration” gives a closer explanation about how to do this.

You can, of course, make direct change to the configuration. All configuration files in /etc/exim4 are dpkg-conffiles, and you can thus edit them any time. Your changes will be preserved through updates. You need to know about how to configure Exim to be successful.

If you use unsplit configuration, edit /etc/exim4/exim4.conf.template. If you use split configuration, edit the Exim configuration snippets in /etc/exim4/conf.d.

More information about how the Exim configuration is built can be found in this document and in the update-exim4.conf manual page.

If you are only running a small number of systems and want to completely disable Debian's magic, just take your monolithic configuration file and install it as /etc/exim4/exim4.conf. Exim will use that file verbatim. To have something to start, you can either take /etc/exim4/exim4.conf.template, run update-exim4.conf --keepcomments --output /etc/exim4/exim4.conf, or use upstream's default configuration file that is installed as /usr/share/doc/exim4-base/examples/example.conf.gz. You are going to lose all magic you get from packaging though, so you need to be familiar with Exim to build an actually working config.

/var/lib/exim4/config.autogenerated, the file generated by update-exim4.conf, is ignored as soon as /etc/exim4/exim4.conf is found. You should not edit /etc/exim4/exim4.conf directly when Exim is running, because the forked processes Exim starts for SMTP receiving or queue running would use the new configuration file, while the original main exim-daemon would still use the old configuration file.

Some third-party HOWTOs that reference Debian and claim to make things easy suggest dumping a pre-fabricated, static config file to /etc/exim4/exim4.conf. This is considered bad advice by the Debian maintainers since you are going to disable all updates and service magic that Debian might deliver in the future this way. If you do not know exactly what you're doing here, this is a bad choice. We try to comment on external HOWTOs found on the web in the Debian Exim4 User FAQ to help you find out which advice to follow.

We split off Exim's configuration system (debconf, update-exim4.conf, and the files in /etc/exim4/conf.d) to a separate package, exim4-config. If you want to, you can replace exim4-config by something entirely different. The other packages don't care. Your package needs to:

Your package must provide an executable update-exim4.conf that must be in root's path (/usr/sbin recommended). The init script will invoke that executable prior to invoking the actual exim daemon. If you do not need that script, have it exit 0.

If you want to create your own configuration packages, there is a number of helpers available.

Please note that exim4-config-simple and exim4-config-medium are only targeted to be used as a template. The configurations contained are not suitable for productive use. Of course, the Debian maintainers appreciate any patches you might find suitable. The scripts in exim4-config-simple and exim4-config-medium may not work at all in your environment. Unfortunately, they have not been updated in a long time as well. We are willing to accept patches.

See the development web page for links to the subversion repository.

Exchanging the entire exim4-config package with something custom comes particularly handy for sites that have more than a few machines that are similarly configured, but do not want to use the original exim4-config package. Build your own exim4-config-custom or exim4-config-foo, and simply apt that package to the machines that need to have that configuration. Future updates can then be handled via the dpkg-conffile mechanism, properly detecting local modifications.

In the future, it might be possible that Debian will contain multiple flavours of Exim4 configuration. However, these packages would have to be maintained by someone else because the exim4 package maintainers think that the scheme delivered with exim4-config is the least of all evils and would rather not spend the time to maintain multiple configuration schemes while only actually using one. It would be nice to have a configuration scheme using a monolithic config file, managed by ucf in three-way-merge mode. If anybody feels ready to maintain it, please go ahead.

rmail is the oldest way to transfer mail to a remote system. However, today it is normally required to use addresses with full domains for that (Well, they look like any normal address for you, and we do not tell about the other way to not confuse you ;). If you want this, you can use this transport:

rmail:
    debug_print = "T: rmail for $pipe_addresses"
    driver=pipe
    command = uux - -r -a$sender_address -gC $domain_data!rmail $pipe_addresses
    return_fail_output
    user=uucp
    batch_max = 20
	  

However, all recipients are handled via the command line, so you are discouraged to use it.

This is a more efficient way to transfer mails. It works like sending SMTP via a pipe, but instead of waiting for an answer, the SMTP is just batched; from this is also the name batched SMTP or short bsmtp.

Furthermore, this way won't fail on addresses like " "@do.main. If you want this, please use this, if the remote site uses rsmtp (e.g. is Exim 4):

rsmtp:
    debug_print = "T: rsmtp for $pipe_addresses"
    driver=pipe
    command = /usr/bin/uux - -r -a$sender_address -gC $domain_data!rsmtp
    use_bsmtp
    return_fail_output
    user=uucp
    batch_max = 100
	  

and this if it wants bsmtp as the command:

bsmtp:
    debug_print = "T: bsmtp for $pipe_addresses"
    driver=pipe
    command = /usr/bin/uux - -r -a$sender_address -gC $domain_data!bsmtp
    use_bsmtp
    return_fail_output
    user=uucp
    batch_max = 100
	  

Of course, these examples can be extended for e.g. compression (but you can also use ssh for compression, if you want).

You need a router to tell Exim 4 which mails to forward to UUCP. You can use this one; please adopt the last line. Of course, it is also possible to send mail via more than one way.

uucp_router:
    debug_print = "R: uucp_router for $local_part@$domain"
    driver=accept
    require_files = +/usr/bin/uux
    domains = wildlsearch;/etc/exim4/uucp
    transport = rsmtp
	  

The file /etc/exim4/uucp looks like:

*.do.main       uucp.name.of.remote.side
	  

If you have a leaf system (i.e. all your mail not for your local system goes to a single remote system), you can just forward all non-local mail to the remote UUCP system. In this case, you can replace "domains = ..." with "domains = ! +local_domains", but then you need also to replace $domain_data in the transport by the UUCP-name of your smarthost. The file /etc/exim4/uucp is not needed in this case.

Depending how much you trust your local users, you might use trusted_users and add uucp to it or use local_sender_retain=true and local_from_check=false.

Allow uucp to execute rsmtp via

commands        rmail rnews rsmtp
	    

in your /etc/uucp/sys, and ask the sending site to use rsmtp (and not bsmtp) as the batched command.