Adding debian version 4.94.2-7+deb11u2.debian/4.94.2-7+deb11u2debian

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 2049 insertions, 0 deletions

diff --git a/debian/README.Debian.xml b/debian/README.Debian.xml
new file mode 100644
index 0000000..02e6d77
--- /dev/null
+++ b/debian/README.Debian.xml
@@ -0,0 +1,2049 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+                         "http://www.docbook.org/xml/4.4/docbookx.dtd">
+<article> <title>Exim 4 for Debian</title>
+  <section> <title>Introduction</title>
+    <para>
+      If you're reading this, you have found the README.Debian
+      file. This is good, thanks! Please continue reading this file in
+      its entirety. It is full of important information and has been
+      written with the questions in mind that keep popping up on the
+      mailing lists.
+    </para>
+    <section> <title>How to find your way around the Documentation</title>
+      <para>
+        Exim comes with very extensive documentation. Here is how to
+        find it.
+     	<orderedlist>
+	  <listitem>
+	    <simpara>
+	      A lot of information about Debian's Exim 4
+              packaging can be found in this document.
+            </simpara>
+	  </listitem>
+	  <listitem>
+	    <simpara>
+	      The packages contain a lot of Debian-specific man pages.
+              Use the <command>apropos exim</command> command to get a list.
+            </simpara>
+	  </listitem>
+	  <listitem>
+	    <simpara>
+	      Most files that control the default configuration are
+	      documented in the exim4-config_files(5) man page, which
+	      is symlinked to the file names. man &lt;filename&gt; should
+	      lead you to the page.
+            </simpara>
+	  </listitem>
+	  <listitem>
+	    <para>
+	      The very extensive Upstream documentation is shipped
+	      <orderedlist>
+	        <listitem>
+		  <simpara>
+		    in text form
+	            (<filename>/usr/share/doc/exim4-base/spec.txt.gz</filename>)
+	            with the binary packages.
+		  </simpara>
+		</listitem>
+	        <listitem>
+		  <simpara>
+		    in HTML in the package
+		    <filename>exim4-doc-html</filename>
+		  </simpara>
+		</listitem>
+	        <listitem>
+		  <simpara>
+		    as a Texinfo file in the package
+                    <filename>exim4-doc-info</filename>
+		  </simpara>
+		</listitem>
+	      </orderedlist>
+	    </para>
+	  </listitem>
+        </orderedlist>
+      </para>
+      <para>
+        Please note that documentation found on the web or in other
+	parts of the Debian system (such as the Debian Reference)
+	might be outdated and thus give wrong advice. In doubt, the
+	documentation listed above should take precedence.
+      </para>
+    </section>
+    <section> <title>Getting Support</title>
+      <para>
+	For your questions and comments, there is a <ulink
+	  url="http://lists.alioth.debian.org/mailman/listinfo/pkg-exim4-users">
+	Debian-specific mailing	list</ulink>. Please ask Debian-specific
+	questions there, and only write to the upstream exim-users mailing
+	list if
+	you are sure that your question is not Debian-specific. 
+	Debian-specific questions are more likely to find answers on
+	our pkg-exim4-users mailing list, while complex custom
+	configuration issues might be more easily solved on the
+	upstream exim-users mailing list because of the broader and
+	more experienced audience there. You can subscribe to
+	pkg-exim4-users <ulink
+	  url="http://lists.alioth.debian.org/mailman/listinfo/pkg-exim4-users">
+	  via the subscription web page;</ulink> you need to be
+        subscribed to post.
+      </para>
+      <para>
+        If you think that your question might be more easily answered
+	if one knows a bit about your configuration, you might want to
+	execute <command>reportbug --subject="none" --offline --quiet
+	--severity=wishlist --body="none" --output=exim4.reportbug
+	exim4-config</command> on the system in question, answer yes
+        to both "include [extended] configuration" questions and include
+	the contents of the exim4.reportbug file generated by this
+	command with your question. Please check whether the file
+	contains any confidential information before sending.
+      </para>
+    </section>
+    <section> <title>Packaging</title>
+      <para>
+	Similar to the Apache2 package, Exim 4 is an entirely
+	different package that does not currently offer a smooth
+	upgrade path from Debian's Exim 3 packages.
+      </para>
+      <para>
+	It is the first Exim package in Debian that can be configured
+	using debconf. However, the entire configuration framework is
+	extremely flexible, allowing you to get exactly the amount of
+	control you need for the job at hand.
+      </para>
+      <section> <title>Feature Sets in the daemon packages</title>
+	<para>
+	  To use Exim 4, you need at least the following packages:
+	  <variablelist>
+	    <varlistentry>
+	      <term>exim4-base</term>
+	      <listitem>
+		<simpara>support files for all Exim MTA (v4) packages</simpara>
+	      </listitem>
+	    </varlistentry>
+	    <varlistentry>
+	      <term>exim4-config</term>
+	      <listitem>
+		<simpara>configuration for the Exim MTA (v4)</simpara>
+	      </listitem>
+	    </varlistentry>
+	    <varlistentry>
+	      <term>exim4-daemon-light</term>
+	      <listitem>
+		<simpara>lightweight exim MTA (v4) daemon</simpara>
+	      </listitem>
+	    </varlistentry>
+	  </variablelist>
+	</para>
+	<para>
+	  Just apting the metapackage <command>exim4</command> will pull
+	  in the other packages per dependency. You'll get an exim daemon
+	  with minimal feature set (no external lookups).
+	</para>
+	<para>
+	  If you need more advanced features like LDAP, sqlite, PostgreSQL
+	  and MySQL data lookups, SASL and SPA SMTP authentication, embedded
+	  Perl interpreter, and exiscan-acl for integration of
+	  virus-scanners and SpamAssassin, you can replace
+	  <command>exim4-daemon-heavy</command> instead of
+	  <command>exim4-daemon-light</command>. Additionally, the source
+	  package offers infrastructure to build your own custom-tailored
+	  exim4-daemon-custom which exactly fits your special local needs. 
+	  The infrastructure to do so is already in place, see
+	  debian/rules for instructions.
+	</para>
+      </section>
+      <section> <title>How to build a custom daemon</title>
+	<para>
+	  The process of building a custom daemon is partially
+          documented in the <filename>debian/rules</filename> file
+	  in the source package. Patches for more documentation are welcome.
+	</para>
+      </section>
+    </section>
+  </section>
+  <section> <title>Configuration of Exim 4 in the Debian packages</title>
+    <para>
+      Generally, the Debian Exim 4 packages are configured through
+      debconf. You have been asked some questions on package installation,
+      and your initial Exim configuration has been created from your
+      answers. You can repeat the configuration process any time by invoking
+      <command>dpkg-reconfigure exim4-config</command>. If you are an
+      experienced Exim administrator and prefer to have your own,
+      hand-crafted, non-automatic Exim configuration, you will find
+      information about how to do so in
+      <xref linkend="completely-different-configuration"/>.
+    </para>
+    <para>
+      The debconf-driven configuration is mainly geared for a
+      one-domain shell account machine/workstation with local delivery
+      as suggested by the original upstream default configuration.
+      If you configure the packages to handle more than one local
+      domain, all local domains are treated identically. The domain
+      part is not used for routing and filtering decisions.
+    </para>
+    <para>
+      Despite the default configuration being extended somewhat from
+      the original upstream, chances are that you'll need to
+      manually change the Exim configuration with an editor if you intend to
+      do something that is not covered by the debconf-driven configuration.
+      It has never been the packages' intention to offer all possible
+      configuration methods through debconf. The configuration files are
+      there to be changed, feel free to do so if you see fit. The Debian
+      Exim 4 maintainers have tried to make the configuration as flexible as
+      possible so that manual intervention can be minimized.
+    </para>
+    <para>
+      If you need to make manual changes to the Exim configuration,
+      please be familiar with how Exim works. At minimum, have read this
+      README file and the manpages delivered with the Debian Exim 4
+      packages, and <filename>/usr/share/doc/exim4-base/spec.txt.gz</filename>
+      chapters <phrase>"How Exim receives and delivers mail"</phrase> and
+      <phrase>"The Exim run time configuration file"</phrase>.
+      <filename>spec.txt.gz</filename> is an excellent reference.
+    </para>
+    <para>
+      Please note that while most free-form fields in the
+      debconf-driven configuration have the entered string end up
+      verbatim in Exim's configuration file (and thus using more
+      advanced features like host, address and domain lists is possible
+      and will probably work), this is not officially supported.
+      Only plain lists are supported in the debconf dialogs. You may
+      use more advanced features, but they may stop working any time
+      during upgrades.
+    </para>
+    <section> <title>The Configuration System</title>
+        <section id="debconf-questions"> <title>The Debconf questions</title>
+	    <para>
+	      In this section, we try to document and explain the debconf
+	      questions, which are themselves limited to a small screen of
+	      information and might leave questions unanswered. Since you
+	      can usually read this file only after having answered the 
+	      questions, the process can always be repeated by invoking
+	      <command>dpkg-reconfigure exim4-config.</command> 
+	      <filename>/etc/exim4/update-exim4.conf.conf</filename>,
+	      documented in the <command>update-exim4.conf</command>
+	      manual page, is
+	      a simple shell-script snippet used to store the answers
+	      that you passed to debconf when initially configuring Exim.
+	      You may also modify this file with an editor of your choice.
+	      The package maintainer scripts can handle this and will
+	      preserve your changes. 
+	    </para>
+	  <section> <title>General type of mail configuration</title>
+              <para>
+                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.
+              </para>
+	      <section> <title> internet site; mail is sent and
+	      received directly using SMTP</title>
+	          <para>
+		    This option is suitable for a standalone system
+		    with full internet connectivity.
+		  </para>
+                  <itemizedlist>
+                      <listitem>
+		          <para>
+			    The Exim SMTP daemon will accept messages
+			    to local domains, and deliver them locally.
+                          </para>
+		      </listitem>
+                      <listitem>
+		          <para>
+			    Outgoing mail will be delivered directly
+			    to the mail exchange servers of the
+			    recipient domain
+                          </para>
+		      </listitem>
+		  </itemizedlist>
+              </section>
+	      <section> <title> mail sent by smarthost; received via
+	      SMTP or fetchmail</title>
+	          <para>
+		    This option is suitable for a standalone client system
+		    which has restricted internet connectivity, for
+		    example on a residential connection where an SMTP
+		    smarthost is used. Some ISPs block outgoing SMTP
+		    connections to combat the spam problem, thus
+		    requiring the use of their smarthosts. It is
+		    generally a good idea to use the ISPs smart host
+		    if one is connected with a dynamic IP address
+		    since quite a few sites do not accept mail
+		    directly delivered from a dial-in pool.
+		  </para>
+		  <para>
+		    fetchmail can be used to retrieve incoming mail
+		    from the ISP's POP3 or IMAP mail server and
+		    deliver it to Exim via SMTP.
+		  </para>
+                  <itemizedlist>
+                      <listitem>
+		          <para>
+			    The Exim SMTP daemon will accept messages
+			    to local domains, and deliver them locally.
+                          </para>
+		      </listitem>
+                      <listitem>
+		          <para>
+			    Outgoing mail will always be delivered to
+			    the smarthost configured in exim4.
+                          </para>
+		      </listitem>
+		  </itemizedlist>
+              </section>
+	      <section> <title>mail sent by smarthost; no local mail</title>
+	          <para>
+		    This option is suitable for a client system in a
+		    computer pool which is not responsible for a local
+		    e-mail domain. All locally generated e-mail is
+		    sent to the smarthost without any local domains.
+		  </para>
+              </section>
+	      <section> <title>local delivery only; not on a network</title>
+	          <para>
+		    This option is suitable for a standalone system
+		    with no networking at all. Only messages for configured
+		    local domains are accepted and delivered locally;
+		    messages for all other domains are rejected:
+		    ``Mailing to remote domains not supported''.
+		  </para>
+              </section>
+	      <section> <title>no configuration at this time</title>
+	          <para>
+		    This option disables most of Debian's automatisms
+		    and leaves exim in an unconfigured state.
+		    update-exim4.conf will still copy
+		    <filename>/etc/exim4/exim4.conf.template</filename>
+		    or concatenate the files from
+		    <filename>/etc/exim4/conf.d,</filename> and will
+		    not generate any configuration control macros.
+		    Unless you manually edit the configuration source,
+		    this will leave Exim with a syntactically invalid
+		    configuration file, thus in a state where the
+		    daemon won't even start.
+		  </para>
+		  <para>
+		    Only choose this option if you know what you're
+		    doing and are prepared to create your own Exim
+		    configuration.
+		  </para>
+		  <para>
+		    dpkg-conffile handling is still in place, and you
+		    will be offered updates for configuration
+		    snippets, as soon as they become available.
+		  </para>
+              </section>
+          </section>
+	  <section> <title>System mail name</title>
+	      <para>
+	         The "mail name" is the domain name used to "qualify"
+		 mail addresses without a domain name.
+	      </para>
+	      <para>
+                 This name will also be used by other programs. It
+		 should be the single, full domain name (FQDN).
+	      </para>
+	      <para>
+                 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.
+	      </para>
+	      <para>
+	        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.
+	      </para>
+	      <para>
+	        This qualification happens for all addresses exim
+                encounters, be it sender, recipient or else.
+              </para>
+	      <para>
+	        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 <filename>/etc/mailname,</filename> which is a
+		file that might be used by other programs as well.
+	      </para>
+	      <para>
+	        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.
+	      </para>
+          </section>
+	  <section> <title>IP addresses to listen on for incoming SMTP
+	  connections</title>
+	      <para>
+	        Please enter a semicolon-separated list of IP addresses.
+	        The Exim SMTP listener daemon will listen on all IP
+	        addresses listed here.
+	      </para>
+	      <para>
+	        An empty value will cause Exim to listen for connections
+	        on all available network interfaces.
+	      </para>
+	      <para>
+	        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.
+	      </para>
+	      <para>
+	        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.
+	      </para>
+          </section>
+	  <section> <title>Other destinations for which mail is accepted</title>
+	      <para>
+	         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.
+	      </para>
+	      <para>
+                 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.
+	      </para>
+              <para>
+	        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.
+	      </para>
+          </section>
+	  <section> <title>Domains to relay mail for</title>
+	      <para>
+	        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.
+	      </para>
+	      <para>
+                Do not mention local domains here. Wildcards may be used.
+	      </para>
+              <para>
+                The answer to this question is a list of the domains
+		for which Exim will relay messages coming in from anywhere
+		on the Internet.
+	      </para>
+          </section>
+	  <section> <title>Machines to relay mail for</title>
+	      <para>
+	         Please enter a semicolon-separated list of IP address
+		 ranges for which this system will unconditionally relay
+		 mail, functioning as a smarthost.
+	      </para>
+	      <para>
+                 You should use the standard address/prefix format
+		 (e.g. 194.222.242.0/24 or 5f03:1200:836f::/48).
+	      </para>
+	      <para>
+                 If this system should not be a smarthost for any
+		 other host, leave this list blank.
+	      </para>
+	      <para>
+	        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
+		<emphasis>NOT</emphasis> list 0.0.0.0/0!
+	      </para>
+	      <para>
+		Warning: While it is possible to use 
+		host<emphasis>names</emphasis> instead of IP addresses in this
+		list extra care needs to be taken in this case. 
+		<emphasis>Unresolvable names in the host list will break
+		relaying.</emphasis> See
+		Exim specification chapter <phrase>"Domain, host, address, and
+		local part lists"</phrase>
+		and the exim4-config_files man page.
+	      </para>
+          </section>
+	  <section> <title>IP address or host name of the outgoing
+              smarthost</title>
+	      <para>
+	        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.
+	      </para>
+	      <para>
+	        If the smarthost requires authentication, please refer
+		to <xref linkend="smtp-auth"/> for notes about setting
+		up SMTP authentication.
+	      </para>
+	      <para>
+	        Multiple smarthost entries are permitted, semicolon
+		separated. Each of the hosts is tried, in the order
+		specified (See Exim specification, chapter
+		<phrase>"The manualroute router"</phrase>, section
+		<phrase>"How the list of hosts is used"</phrase>.)
+	      </para>
+          </section>
+	  <section> <title>Hide local mail name in outgoing mail</title>
+              <para>
+	        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.
+              </para>
+          </section>
+	  <section> <title>Visible domain name for local users</title>
+              <para>
+	        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.
+              </para>
+          </section>
+	  <section> <title>Keep number of DNS queries minimal
+              (Dial-on-Demand)</title>
+	      <para>
+	         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.
+	      </para>
+	      <para>
+                 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.
+	      </para>
+	      <para>
+                 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.
+	      </para>
+          </section>
+	  <section><title>Delivery method for local mail</title>
+	      <para>
+	        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/.
+	      </para>
+	      <para>
+	        Please note that most mail tools in Debian expect the
+		local delivery method to be mbox in their default.
+	      </para>
+	  </section>
+	  <section> <title>Split configuration into small files</title>
+              <para>
+	        Our packages offer two (actually three, see
+		<xref linkend="completely-different-configuration"/>)
+		possibilities:
+              </para>	
+              <orderedlist>
+    	          <listitem>	
+    	              <simpara>
+		          Generate Exim's configuration from
+			  <filename>/etc/exim4/exim4.conf.template,</filename>
+			  which is basically a normal Exim run-time
+			  configuration file which will be supplemented
+			  with some macros generated from Debconf in a
+			  post-processing step before it is passed to exim.
+		      </simpara>
+		  </listitem>
+		  <listitem>
+		      <simpara>
+			  Generate Exim's configuration from the
+			  multiple files in
+			  <filename>/etc/exim4/conf.d/</filename>. The
+			  directories in
+			  <filename>/etc/exim4/conf.d/</filename>
+			  correspond to the sections of the Exim
+			  run-time configuration file, so you should
+			  easily find your way around there.
+		      </simpara>
+		  </listitem>
+	      </orderedlist>
+              <para>
+	        Splitting the configuration across multiple files
+		means that you have the actual configuration file
+		automatically generated from the files below
+		<filename>/etc/exim4/conf.d/</filename> by invoking
+		<command>update-exim4.conf</command>. Each section
+		of Exim's configuration has its own subdirectory and
+		the files in there are supposed to be read in
+		alphanumeric order.
+		<filename>router/00_exim4-config_header</filename>
+		is followed by
+		<filename>router/100_exim4-config_domain_literal</filename>,
+		...
+              </para>
+              <para>
+    	        If you chose unsplit configuration,
+		<command>update-exim4.conf</command> builds the
+		configuration from
+		<filename>/etc/exim4/exim4.conf.template</filename>,
+		which is basically the files from
+		<filename>/etc/exim4/conf.d/</filename> concatenated
+		together at package build time, and thus guarantees
+		consistency on the target system.
+              </para>
+              <para>
+    	        In both cases, <command>update-exim4.conf</command>
+		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
+		<command>update-exim4.conf</command> manual
+		page for more in-depth information about this
+		mechanism.
+              </para>
+              <para>
+    	        Benefits of the split configuration approach:
+    		<itemizedlist>
+    	  	    <listitem>
+    	    	        <simpara>
+                          it means less work for you when upgrading.
+			  If we shipped one big file and modified
+			  for example the Maildir transport in a new
+			  version you won't have to do manual
+			  conffile merging unless you had changed
+			  exactly <emphasis>this</emphasis>
+			  transport.
+			</simpara>
+		    </listitem>
+		    <listitem>
+		        <simpara>
+			  It allows other packages (e.g. sa-exim) to
+			  modify Exim's configuration by dropping
+			  files into
+			  <filename>/etc/exim4/conf.d</filename>.
+			  This needs, however quite exact syncing
+			  between the exim4 packages and the other,
+			  cooperating package.
+			</simpara>
+		    </listitem>
+		</itemizedlist>
+	      </para>
+	      <para>
+		Drawbacks of the split configuration approach:
+		<itemizedlist>
+		    <listitem>
+		        <simpara>
+			  It is more fragile. If files from
+			  different sources (package, manually
+			  changed, or other package) get out of
+			  sync, it is possible for Exim to break
+			  until you manually correct this. This can
+			  for example happen if we decide to add a
+			  new option to the Debian setup of a later
+			  version, and you have already set this
+			  option in a local file.
+			</simpara>
+		    </listitem>
+		</itemizedlist>
+	      </para>
+	      <para>
+	        Benefits of the unsplit configuration approach:
+		<itemizedlist>
+		    <listitem>
+		        <simpara>
+			  People familiar with configuring Exim may
+			  find this approach easier to understand as
+			  <filename>exim4.conf.template</filename>
+			  basically is a complete Exim configuration
+			  file which will only undergo some basic
+			  string replacement before is it passed to
+			  exim.
+		        </simpara>
+		    </listitem>
+		    <listitem>
+			<simpara>
+			  Split-config's fragility mentioned
+			  above does not occur.
+			</simpara>
+		    </listitem>
+		</itemizedlist>
+	      </para>
+	      <para>
+	        Drawbacks of the unsplit configuration approach:
+		<itemizedlist>
+		    <listitem>
+		        <simpara>
+			  Will require manual intervention in case of an
+			  upgrade.
+			</simpara>
+		    </listitem>
+		</itemizedlist>
+	      </para>
+              <para>
+                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.
+	      </para>
+	      <para>
+	        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.
+	      </para>
+	      <para>
+	        If you are using unsplit configuration, have local
+		changes to <filename>/etc/exim4/conf.d/</filename>
+		(either made by yourself or by other packages dropping
+		their own routers or transports in) and want to
+		re-generate
+		<filename>/etc/exim4/exim4.conf.template</filename> to
+		activate these changes, you can do so by using
+		<command>update-exim4.conf.template</command>.
+	      </para>
+	  </section>
+      </section>
+      <section> <title>Access Control in the default configuration</title>
+        <para>
+          The Debian exim 4 packages come with a default configuration
+	  that allows flexible access control and blacklisting of
+	  sites and hosts. The acls involved can be found in
+	  /etc/exim4/conf.d/acl, or in /etc/exim4/exim4.conf.template,
+	  depending on which configuration scheme you use. Most
+	  rejections of messages due to this mechanism happen at RCPT
+	  time. Local configuration of the mechanisms happens through
+	  data files in /etc/exim4 or via Exim macros that you can set
+	  in /etc/exim4/conf.d/main, so there is normally no need to
+	  change the files in the acl subdirectory in a split-config
+	  setup. If you use the non-split config, you need to edit
+	  /etc/exim4/exim4.conf.template, which, as a big
+	  dpkg-conffile, won't give you any advantage of the .ifdef
+	  scheme.
+        </para>
+        <para>
+          The data files are documented in the exim4-config_files man
+          page.
+        </para>
+        <para>
+          The access lists delivered with the exim4 packages also
+	  contain quite a few configuration options that are too
+	  restrictive to be active by default on a real-life site.
+	  These are masked by .ifdef statements, can be activated by
+	  setting the appropriate macros, and are documented in the
+	  ACL files itself.
+        </para>
+    </section>
+    <section id='macros'> <title>Using Exim Macros to control the
+      configuration</title>
+      <para>
+	Our configuration can be controlled in a limited way by
+	setting macros. That way, you can switch on and off certain
+	parts of the default configuration and/or override values set
+        in Debconf without having to touch the dpkg-conffiles. While
+	touching dpkg-conffiles itself is explicitly allowed and wanted,
+	it can be quite a nuisance to be asked on package upgrade
+	whether one wants to use the locally changed file or the
+	file changed by the package maintainer.
+      </para>
+      <para>
+	Whenever you see an <command>.ifdef</command> or
+	<command>.ifndef</command> clause in the configuration file,
+	you can control the appropriate clause by setting the macro in
+	a local configuration file. <command>.ifndef</command> checks
+	whether a specific macro is set (to a nonempty value), the
+	actual value does not matter. (Both
+	<quote>EXIM4_EXAMPLE = true</quote> and
+	<quote>EXIM4_EXAMPLE = false</quote> pass this test.)
+	For split configuration, you can
+	drop the local configuration file anywhere in
+	<filename>/etc/exim4/conf.d/main</filename>. Just make sure it
+	gets read before the macro is first used. 
+	<filename>000_localmacros</filename> is a possible name,
+	guaranteeing first order. For a non-split configuration,
+	<filename>/etc/exim4/exim4.conf.localmacros</filename> gets
+	read before
+	<filename>/etc/exim4/exim4.conf.template</filename>. To
+	actually set the macro <varname>EXIM4_EXAMPLE</varname> to the
+	value "this is a sample", write the following line
+      </para>
+      <para>
+	EXIM4_EXAMPLE = this is a sample
+      </para>
+      <para>
+	into the appropriate file. For more detailed discussion of the
+	general macro mechanism, see the Exim specification, chapter
+	<phrase>"The Exim run time configuration file"</phrase>, for
+	details how macro expansion works.
+      </para>
+      </section>
+      <section>	<title>How does this work?</title>
+	<para>
+	  The script <command>update-exim4.conf</command> parses the
+	  <filename>/etc/exim4/update-exim4.conf.conf</filename> file
+	  and provides the configuration for the exim daemon.
+	</para>
+	<para>
+	  Depending on the value of
+	  <varname>dc_use_split_config</varname>, it either
+	  <itemizedlist>
+	    <listitem>
+	      <simpara>
+		takes all the files below
+		<filename>/etc/exim4/conf.d/</filename> and
+		concatenates them together or
+	      </simpara>
+	    </listitem>
+	    <listitem>
+	      <simpara>
+		uses <filename>exim4.conf.template</filename> as
+		input.
+	      </simpara>
+	    </listitem>
+	  </itemizedlist>
+	  The debconf-managed information from
+	  <filename>/etc/exim4/update-exim4.conf.conf</filename> is
+	  merged into the generated configuration file by generating a
+          number of Exim configuration macros.
+	</para>
+	<para>
+	  <varname>DCsmarthost</varname>, for example, is set to the
+	  value of <varname>$dc_smarthost</varname>
+	  in <filename>/etc/exim4/update-exim4.conf.conf</filename>
+	  which holds the answer to "Which machine will act as the
+	  smarthost and handle outgoing mail?"
+	</para>
+	<para>
+	  The result of these operations is saved as
+	  <filename>/var/lib/exim4/config.autogenerated</filename>,
+	  which is <emphasis>not</emphasis> a dpkg-conffile! Manual
+	  changes to this file will be overwritten by
+	  <command>update-exim4.conf</command>.
+	</para>
+	<para>
+	  Please consult <command>update-exim4.conf</command> manpage
+	  for more detailed information.
+	</para>
+	<para>
+	  <command>update-exim4.conf</command> is invoked by the init
+	  script prior to any operation that may invoke an exim process,
+	  and gives an error message if the generated config file is
+	  syntactically invalid. If you want to activate your changes to
+	  files in conf.d/ just execute <command>invoke-rc.d exim4 restart</command>.
+	</para>
+      </section>
+      <section id="howto-change-config"><title>How do I do minor tweaks to the configuration?</title>
+        <para>
+	  Some times, you want to do minor adjustments to the Exim
+	  configuration to make Exim behave exactly like you want it
+	  to behave. There are the following possibilities to modify
+	  Exim's behavior.
+	</para>
+	<section><title>Adjustments supported by the debconf configuration</title>
+	  <para>
+	    If you want to modify parameters that are supported by the
+	    debconf configuration, things are easy. Just invoke
+	    <command>dpkg-reconfigure exim4-config</command> or hand-edit
+	    <filename>/etc/exim4/update-exim4.conf.conf</filename> to your
+	    liking and restart Exim.
+	  </para>
+	  <para>
+	    You can find explanation of the debconf questions in <xref
+            linkend="debconf-questions"/>.
+            Additionally,
+	    <filename>/etc/exim4/update-exim4.conf.conf</filename>
+	    is documented in the <command>update-exim4.conf</command>
+	    man page.
+	  </para>
+	</section>
+	<section><title>Adjustments controlled by macros in the Debian Exim configuration</title>
+	  <para>
+	    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.
+	  </para>
+	  <para>
+	    <xref linkend="macros"/> gives a closer explanation about
+            how to do this.
+	  </para>
+	</section>
+	<section><title>Making direct changes to the Debian Exim configuration</title>
+	  <para>
+	    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.
+	  </para>
+	  <para>
+	    If you use unsplit configuration, edit
+            <filename>/etc/exim4/exim4.conf.template</filename>. If you use
+	    split configuration, edit the Exim configuration snippets in
+	    <filename>/etc/exim4/conf.d</filename>.
+	  </para>
+	  <para>
+	    More information about how the Exim configuration is built
+            can be found in this document and in the
+	    <command>update-exim4.conf</command> manual page.
+	  </para>
+	</section>
+      </section>
+      <section id="completely-different-configuration">	<title>Using a completely different configuration scheme</title>
+	<para>
+	  If you are an experienced Exim administrator, you might feel
+	  working with our pre-fabricated configuration
+	  cumbersome and complex. You might feel right if you need to
+	  make more complex changes and do not need to receive updates
+	  from us. This section is going to tell about how to use
+	  your own configuration.
+	</para>
+	<para>
+	  But, you might profit from keeping the Debian magic. Most
+	  files that come with Debian exim4 are conffiles. Debian is
+	  going to care about your changes and keeps them around.
+	  Additionally, a lot of configuration options can be
+	  overridden with a macro, which does not require you to
+	  actually change our configuration file. A lot of people are
+	  using our configuration scheme, and maybe it is going to
+	  save you a lot of time if you decide to spend some time
+	  familiarizing yourself with our scheme.
+	</para>
+	<section> <title>Override exim4-config configuration magic</title>
+	    <para>
+	    	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
+		<filename>/etc/exim4/exim4.conf</filename>. Exim will
+		use that file verbatim. To have something to start,
+		you can either take
+		<filename>/etc/exim4/exim4.conf.template</filename>, 
+		run <command>update-exim4.conf --keepcomments --output
+		/etc/exim4/exim4.conf</command>, or use upstream's
+		default configuration file that is installed as
+		<filename>/usr/share/doc/exim4-base/examples/example.conf.gz</filename>.
+		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.
+	    </para>
+	    <para>
+		<filename>/var/lib/exim4/config.autogenerated</filename>,
+		the file generated by
+		<command>update-exim4.conf</command>, is ignored as soon
+		as <filename>/etc/exim4/exim4.conf</filename> is found. 
+		You should not edit
+		<filename>/etc/exim4/exim4.conf</filename> 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.
+	    </para>
+	    <para>
+	    	Some third-party HOWTOs that reference Debian and
+		claim to make things easy suggest dumping a
+		pre-fabricated, static config file to
+		<filename>/etc/exim4/exim4.conf</filename>. 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 <ulink
+		url="http://wiki.debian.org/PkgExim4UserFAQ">Debian
+		Exim4 User FAQ</ulink> to help you find out which
+		advice to follow.
+	    </para>
+	</section>
+	<section> <title>Replacing exim4-config with your own exim4 configuration package.</title>
+	    <para>
+		We split off Exim's configuration system (debconf,
+		<command>update-exim4.conf</command>, and the files in
+		<filename>/etc/exim4/conf.d)</filename> 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:
+		<itemizedlist>
+		  <listitem>
+		    <simpara>
+			Provides: exim4-config-2, Conflicts:
+			exim4-config-2,exim4-config
+		    </simpara>
+		  </listitem>
+		  <listitem>
+		    <simpara>
+			drop the Exim 4 configuration either into
+			<filename>/var/lib/exim4/config.autogenerated</filename>
+			or into <filename>/etc/exim4/exim4.conf</filename>.
+		    </simpara>
+		  </listitem>
+		</itemizedlist>
+		Your package must provide an executable <command>update-exim4.conf</command>
+		that must be in root's path (<filename>/usr/sbin</filename> 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.
+	    </para>
+	    <para>
+		If you want to create your own configuration packages, there is a
+		number of helpers available.
+		<itemizedlist>
+	 	  <listitem>
+		    <simpara>
+			The Exim 4 Debian svn repository holds sources for a
+			exim4-config-simple package which contains a simple, not
+			debconf-driven configuration scheme as an example which can
+			be used as a template for a classical, exim4.conf based
+			configuration scheme.
+		    </simpara>
+		  </listitem>
+		  <listitem>
+		    <simpara>
+			The Exim 4 Debian svn repository holds sources for a
+			exim4-config-medium package which contains the conf.d
+			driven configuration of the main package with the
+			debconf interaction removed. This can be used to create
+			your own non-debconf configuration package that uses the
+			conf.d mechanism.
+		    </simpara>
+		  </listitem>
+		  <listitem>
+		    <simpara>
+			Finally, you can invoke the script
+			<filename>debian/config-custom/create-custom-config-package</filename>
+			which will create a new source package
+			"exim4-config-custom" with the debconf-driven config
+			scheme of exim4-config for your local modification.
+		    </simpara>
+		  </listitem>
+		</itemizedlist>
+		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.
+	    </para>
+	    <para>
+		See the development web page for links to the subversion
+		repository.
+	    </para>
+	    <para>
+		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.
+	    </para>
+	    <para>
+		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.
+	    </para>
+	</section>
+      </section>
+    </section>
+    <section id="TLS"> <title>Using TLS</title>
+    <para>
+      Both exim4-daemon-heavy and exim4-daemon-light support TLS/SSL
+      using the GnuTLS library.
+    </para>
+      <section>	<title>Exim 4 as TLS/SSL client</title>
+	<para>
+	  Exim will use TLS
+	  via STARTTLS <emphasis>automatically</emphasis> as client if
+	  the server Exim connects to offers it.
+	</para>
+	<para>
+	  This means that you will not need any special configuration if
+	  you want to use opportunistic TLS for outgoing mail. However,
+	  to enforce TLS and successful certificate verification, a few
+	  things need to be configured.
+	</para>
+	<para>
+		To enforce TLS and prevent fallback to unencrypted
+		connections, ensure that hosts_require_tls = * is in effect on
+		the respective transport.  For the remote_smtp_smarthost
+		transport, this setting can be controlled via the
+		REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS macro.
+	</para>
+	<para>
+		The certificate presented by the remote host is checked
+		against the system CA certificate store
+		(<filename>/etc/ssl/certs/</filename>) and the verification
+		result is logged (CV=...).
+		For the remote_smtp_smarthost transport successful
+		certificate verification against the system trust store is
+		enforced by default on encrypted connections.
+		(<quote>REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS = *</quote>
+		is set by default). Set this macro to an empty value to
+		disable this. To check against a certificate not present in
+		the system trust store point
+		REMOTE_SMTP_SMARTHOST_TLS_VERIFY_CERTIFICATES (which sets
+		tls_verify_certificates) to a file containing this (set of)
+		trusted certificates.
+	</para>
+	<para>
+                Successful certificate verification is
+                <emphasis>not enforced</emphasis>
+		by default for other transports.
+	</para>
+	<para>
+		Another possibility would be to use DANE for certificate
+		verification. This requires support on the server side and
+		a resolver with DNSSEC support on the client side.
+	</para>
+	<para>
+	  If your
+	  server setup mandates the use of client certificates, you
+	  need to amend your remote_smtp and/or remote_smtp_smarthost
+	  transports with a tls_certificate option. This is not
+          commonly needed.
+	</para>
+	<para id="tls_client_certicate">
+		To make exim send a TLS certificate to the remote host set
+		REMOTE_SMTP_TLS_CERTIFICATE/REMOTE_SMTP_PRIVATEKEY or for
+		the remote_smtp_smarthost transport
+		REMOTE_SMTP_SMARTHOST_TLS_CERTIFICATE/REMOTE_SMTP_SMARTHOST_PRIVATEKEY
+		respectively.
+	</para>
+	<para>
+	   TLS on connect is not natively supported.
+	</para>
+      </section>
+      <section>	<title>TLS support for Exim as server</title>
+	<para>
+    Exim supports incoming opportunistic TLS by using on-connect
+    autogenerated self-signed certificates. This is not optimal both for
+    performance reasons and because these certificates cannot be verified
+    by connecting clients/servers.
+  <para>
+    Each time an on-demand cert is created exim will log a info message
+    in the mainlog that looks like this:
+      <blockquote>
+        Warning: No server certificate defined; will use a selfsigned one.
+        Suggested action: either install a certificate or change
+        tls_advertise_hosts option
+      </blockquote>
+    This informative message can be ignored.
+  </para>
+  </para>
+  <para>
+    To avoid the (small) performance issue and the log message one can
+    locally create certificates. The exim-gencert script (which requires
+    openssl) can be helpful for this purpose. It is shipped in
+	  <filename>/usr/share/doc/exim4-base/examples/</filename> and
+	  takes care of proper access privileges on the private key
+	  file when installing key/certificate in
+	  <filename>/etc/exim4/</filename>.
+	</para>
+	<para>
+    One can also get a certificate from a CA and install the key in
+    <filename>/etc/exim4/exim.key</filename> and the certificate
+    in <filename>/etc/exim4/exim.crt</filename>.
+	</para>
+	<para>
+	  To enable use of the installed certificates set the macro
+    MAIN_TLS_ENABLE in a local configuration file as described in
+    <xref linkend="macros"/>.
+	</para>
+	<para>
+	  After this configuration, Exim will advertise STARTTLS when
+	  connected to on the normal SMTP ports. Some broken clients
+          (most prominent example being nearly all versions of Microsoft
+	  Outlook and Outlook Express, and Incredimail) insist on doing
+	  TLS on connect on Port 465. If you need to support these, set
+	  SMTPLISTENEROPTIONS='-oX 465:25 -oP /run/exim4/exim.pid'
+	  in <filename>/etc/default/exim4</filename> and
+	  "tls_on_connect_ports=465" in the main configuration section.
+	</para>
+	<para>
+	  The -oP is needed because Exim does not write an implicit pid
+	  file if -oX is given. Without pid file, init script and cron
+          job will malfunction.
+	</para>
+	<para>
+	  It might be appropriate to add "+tls_cipher" to
+	  any log_selector statement you might already have, or to add a
+	  log_selector statement setting these two options in a local
+	  configuration file. (For Debian's configuration simply define
+	  the MAIN_LOG_SELECTOR macro.)
+	  This option makes Exim log what cipher
+	  your Exim and the peer's mailer have negotiated to use to
+	  encrypt the transaction.
+	</para>
+	<para>
+	  Exim can be configured to ask a client for a certificate and to
+	  try to verify it. Debian's exim configuration used to enable
+	  this by default, but stopped doing so since it caused TLS errors
+	  with a couple of popular clients (Outlook, Incredimail, etc.).
+	  To enable this again set the macro MAIN_TLS_TRY_VERIFY_HOSTS to
+	  the lists hosts whose certificates you want to check. (Use * to
+	  try checking all hosts. The value of the macro is used to
+	  populate exim's main option tls_try_verify_hosts.) You should
+	  also point MAIN_TLS_VERIFY_CERTIFICATES to a file containing the
+	  accepted certificates, since its default setting
+	  (/etc/ssl/certs/ca-certificates.crt) can contain a large list of
+	  certificates which causes the interoperabilty problems with
+	  Outlook et.al. noted above.
+	</para>
+	<para>
+		The server certificate is only used for incoming connections,
+		please consult <xref linkend="tls_client_certicate"/> for the
+		corresponding outgoing conncection options.
+	</para>
+      </section>
+      <section>	<title>Troubleshooting</title>
+	<para>
+	  If Exim complains in an SMTP session that TLS is unavailable,
+	  the Exim mainlog or paniclog frequently has exact information
+	  about what might be wrong. Fo example, you might see
+	</para>
+	<para>
+	  2003-01-27 19:06:45 TLS error on connection from localhost [127.0.0.1]
+	  (cert/key setup): Error while reading file)
+	</para>
+	<para>
+	  showing that there has been an error while accessing the
+	  certificate or the private key file.
+	</para>
+	<para>
+	  Insuffient entropy available is a frequent cause of TLS
+          failures in Exim context. If Exim logs "not enough random bytes
+	  available", or simply hangs silently when an encrypted
+          connection should be established, then Exim was
+	  unable to read enough random data from
+	  <filename>/dev/random</filename> to do whatever cryptographic
+	  operation is requested. Please check that your
+	  <filename>/dev/random</filename> device is setup properly.
+	</para>
+	<para>
+	  You might also find "TLS error on connection to [...]
+	  (gnutls_handshake): The Diffie-Hellman prime sent by the server is
+	  not acceptable (not long enough)." given as reason. Exim by default
+	  requires a DH prime length of 1024 bits. This requirement can be
+	  downgraded by setting the tls_dh_min_bits option on the SMTP
+	  transport.  The setting is accessible in the Debian configuration by
+	  setting the macro TLS_DH_MIN_BITS. (e.g. "TLS_DH_MIN_BITS = 768").
+	</para>
+      </section>
+    </section>
+    <section id="smtp-auth"> <title>SMTP-AUTH</title>
+      <para>
+        Exim can do SMTP AUTH both as a client and as a server.
+      </para>
+      <para>
+	AUTH PLAIN and AUTH LOGIN are disabled for connections which are
+	not protected by SSL/TLS per default. These authentication
+	methods use cleartext passwords, and allowing the
+	transmission of cleartext passwords on unencrypted connections
+	is a security risk. Therefore, the default configuration configures
+	Exim not to use and/or allow AUTH PLAIN and AUTH LOGIN over
+        unencrypted connections.
+      </para>
+      <para>
+        It is thus recommended to set up Exim to use TLS to encrypt
+        the connections. Please refer to <xref linkend="TLS"/> for
+        documentation about this. Note that most Microsoft clients
+        need special handling for TLS.
+      </para>
+      <section>	<title>Using Exim as SMTP-AUTH client</title>
+	<para>
+	  If you want to set up Exim as SMTP AUTH client for delivery
+	  to your internet access provider's smarthost put the name of
+	  the server, your login and password in
+	  <filename>/etc/exim4/passwd.client</filename>. See the man
+          page for exim4-config_files(5) for more information about the
+	  required format.
+	</para>
+	<para>
+	  If you need to enable AUTH PLAIN or AUTH LOGIN for unencrypted
+	  connections because your service provider does support neither
+	  TLS encryption nor the CRAM MD5 authentication method, you can
+	  do so by setting the AUTH_CLIENT_ALLOW_NOTLS_PASSWORDS macro.
+	  Please refer to <xref linkend="macros"/> for an explanation of
+	  how best to do this.
+	</para>
+	<para>
+	  <filename>/etc/exim4/passwd.client</filename> needs to be
+	  readable for the exim user (user Debian-exim, group
+	  Debian-exim). It is suggested that you keep the default
+	  permissions root:Debian-exim 0640.
+	</para>
+      </section>
+      <section>	<title>Using Exim as SMTP-AUTH server</title>
+	<para>
+	  The configuration files include many, verbosely commented,
+	  examples for server-side smtp-authentication which just need
+	  to be uncommented.
+	</para>
+	<para>
+	  If you need to enable AUTH PLAIN or AUTH LOGIN for unencrypted
+	  connections because your clients neither support TLS encryption
+	  nor the CRAM MD5 authentication method, you can do so by setting
+	  the AUTH_SERVER_ALLOW_NOTLS_PASSWORDS macro. Please refer to
+	  <xref linkend="macros"/> for an explanation of how best to
+	  do this.
+	</para>
+	<para>
+	  If you want to authenticate against system passwords (e.g. 
+	  <filename>/etc/shadow</filename>) the easiest way is to use
+	  saslauthd in the Debian package sasl2-bin. You have to add the
+	  exim-user (currently Debian-exim) to the sasl group, to give
+	  exim permission to use the saslauthd service.
+	</para>
+	<para>
+	  The Debian exim4 maintainers consider using system login
+	  passwords a bad idea for the following reasons:
+	  <itemizedlist>
+	    <listitem>
+	      <simpara>
+	        A compromised password will give access to a system account.
+	      </simpara>
+	    </listitem>
+	    <listitem>
+	      <simpara>
+	        E-Mail passwords could accidentally be transmitted unencrypted.
+	      </simpara>
+	    </listitem>
+	    <listitem>
+	      <simpara>
+	        E-Mail passwords are likely to be stored with the
+                client software, which greatly increases the chance of a
+		compromise.
+	      </simpara>
+	    </listitem>
+	  </itemizedlist>
+	</para>
+      </section>
+    </section>
+
+    <section> <title>How the Exim daemon is started</title>
+      <para>
+        The Debian Exim 4 packages' init script is located in
+	<filename>/etc/init.d/exim4</filename>. Apart from the
+	functions that are required by Debian policy and the LSB, it
+	supports the commands <command>what</command>, which executes
+	<command>exiwhat</command> to show what your Exim processes
+	are doing, and <command>force_stop</command> which
+	unconditionally kills all Exim processes.
+      </para>
+      <para>
+        The init script can be configured to start listening and/or
+	queue running daemons. This configuration can be found in
+	<filename>/etc/default/exim4</filename>. This file is
+	extensively documented.
+      </para>
+    </section>
+
+    <section> <title>Miscellaneous packaging issues</title>
+      <section> <title>The daily cron job</title>
+	  <para>
+	    Exim4's daily cron job
+            (<filename>/etc/cron.daily/exim4-base</filename>)
+	    does basic housekeeping tasks:
+	    <itemizedlist>
+	      <listitem>
+	        <simpara>
+		  It reads <filename>/etc/default/exim4</filename>, so you
+		  can use this file to change any of the variables used in
+		  the cron job.
+	        </simpara>
+	      </listitem>
+	      <listitem>
+	        <simpara>
+		  It is a no-op if no Exim4 binary is found.
+	        </simpara>
+	      </listitem>
+	      <listitem>
+	        <simpara>
+		  If <command>$E4BCD_DAILY_REPORT_TO</command> is set
+		  to a non-empty string, the output of eximstats is
+		  mailed to the address given in that variable. The
+                  default is empty, so no reports are sent. Options
+                  for eximstats can be given in
+                  <command>$E4BCD_DAILY_REPORT_OPTIONS</command>.
+	        </simpara>
+	      </listitem>
+	      <listitem>
+	        <simpara>
+		  A non-empty paniclog is a nearly sure sign of bad
+		  things going on. Thus, the cron job will send out
+		  warning messages to the syslog and root if it finds
+		  the panic log non-empty.
+		  Please note that the paniclog is not rotated daily,
+		  so existing issues will be reported daily until
+		  either the paniclog is rotated due to its sheer
+		  size, or you manually move it away, for example by
+		  calling <command>logrotate -f
+		  /etc/logrotate.d/exim4-paniclog</command> from a shell.
+	        </simpara>
+		<simpara>
+		  Just in case your system logs transient error
+		  situations to the panic log as well (see, for
+		  example,
+		  <ulink url="http://www.exim.org/bugzilla/show_bug.cgi?id=92">Exim Bug 92</ulink>),
+		  you can configure
+		  <command>$E4BCD_PANICLOG_NOISE</command> to a
+		  regular expression. If the paniclog contains only
+		  lines that match that regular expression, no warning
+		  messages are generated.
+	        </simpara>
+		<simpara>
+		  If you want to disable paniclog monitoring
+		  completely, set <command>$E4BCD_WATCH_PANICLOG</command>
+		  to no. <command>E4BCD_WATCH_PANICLOG=once</command> will
+		  rotate a non-empty paniclog automatically after sending out
+		  the warning e-mail.
+	        </simpara>
+		<simpara>
+		  The <command>E4BCD_PANICLOG_LINES</command> setting can be
+		  used to limit the number of lines of paniclog quoted in
+		  warning email. It is set to 10 by default.
+		</simpara>
+	      </listitem>
+	      <listitem>
+	        <simpara>
+		  It tidies up the retry and hints databases.
+	        </simpara>
+	      </listitem>
+	    </itemizedlist>
+	  </para>
+      </section>
+    </section>
+
+    <section> <title>Using Exim with inetd/xinetd</title>
+      <para>
+	Exim4 is run as a separate daemon instead of inetd/xinetd for
+	two reasons:
+	<variablelist>
+	  <varlistentry>
+	    <term>Ease of maintenance:</term>
+	    <listitem>
+	      <simpara>
+		update-inetd is difficult to impossible to handle
+		correctly (Just check the archived bug reports of Exim.) 
+		and update-inetd seems to be unmaintained for a long
+		time, nobody dares to touch it. To quote Mark Baker, the
+		maintainer of Exim (v3): "I really wish I had never used
+		inetd in the first place, but simply set up exim to run
+		as a daemon, but it's too late to change that now."
+	      </simpara>
+	    </listitem>
+	  </varlistentry>
+	  <varlistentry>
+	    <term>Extended features</term>
+	    <listitem>
+	      <simpara>
+		Running from <command>inetd</command> interferes with
+		Exim's resource controls (e.g it disables
+		smtp_accept_max_per_host and smtp_accept_max).
+	      </simpara>
+	    </listitem>
+	  </varlistentry>
+	</variablelist>
+      </para>
+      <para>
+	If you introduce bugs on your systems by running from (x)inetd
+	you are on your own! If you want to run exim from
+	<command>xinetd</command>, follow these steps:
+	<orderedlist>
+	  <listitem>
+	    <simpara>
+	      Disable Exim 4's listening daemon by executing
+	      <command>update-exim4defaults --queuerunner
+		queueonly</command>
+	    </simpara>
+	  </listitem>
+	  <listitem>
+	    <para>
+	      Create <filename>/etc/xinetd.d/exim4</filename>
+	      <programlisting>
+service smtp
+{
+    disable     = no
+    flags       = NAMEINARGS
+    socket_type = stream
+    protocol    = tcp
+    wait        = no
+    user        = Debian-exim
+    group       = Debian-exim
+    server      = /usr/sbin/exim4
+    server_args = exim4 -bs
+}
+	      </programlisting>
+	    </para>
+	  </listitem>
+	  <listitem>
+	    <simpara>Run <command>invoke-rc.d exim4 restart; invoke-rc.d
+(x)inetd restart</command></simpara>
+	  </listitem>
+	</orderedlist>
+      </para>
+      <para>If you want to use plain inetd, insert following line into
+	<filename>/etc/inetd.conf</filename>:<programlisting>
+smtp stream   tcp     nowait  Debian-exim     /usr/sbin/exim4 exim4 -bs
+	</programlisting>
+      </para>
+    </section>
+
+    <section> <title>Handling incoming mail for local accounts with low UID</title>
+      <para>
+        Since system accounts (mail, uucp, lp etc) are usually aliased
+	to root, and root's mailbox is usually read by a human, these
+	account names have started to be a common target for spammers.
+	The Debian Exim 4 packages have a mechanism to deal with this
+	situation. However, since this derives rather far from normal
+	behavior, it is disabled by default.
+      </para>
+      <para>
+        To enable it, set the macro FIRST_USER_ACCOUNT_UID to a numeric,
+	non-zero value. Incoming mail for local users that have a UID
+	lower than FIRST_USER_ACCOUNT_UID is rejected with the message "no
+	mail to system accounts". Incoming mail for local users that
+	have a UID greater or equal FIRST_USER_ACCOUNT_UID are processed as
+	usual. Therefore, the default value of 0 ensures that the
+	mechanism is disabled. On Debian systems, setting
+	FIRST_USER_ACCOUNT_UID to 500 or 1000 (depending on your local policy)
+	will disable incoming mail for system accounts.
+      </para>
+      <para>
+        Just in case that you need exceptions to the rule,
+	<filename>/etc/exim4/lowuid-aliases</filename> is an alias
+	file that is only honored for local accounts with UID lower
+	than FIRST_USER_ACCOUNT_UID. If you define an alias for such an
+	account here, incoming mail is processed according to the
+	alias. If you alias the account to itself, messages are
+	delivered to the account itself, which is an exception to the
+	rule that messages for low-UID accounts are rejected. The
+	format of <filename>/etc/exim4/lowuid-aliases</filename> is
+	just another alias file.
+      </para>
+    </section>
+    <section> <title>How to bypass local routing specialities</title>
+      <para>
+        Sometimes, it might be desirable to be able to bypass local
+	routing specialities like the alias file or a user-forward
+	file. This is possible in the Debian Exim4 packages by
+	prefixing the account name with "real-". For a local account
+	name "foo", "real-foo@hostname.example" will result in direct
+	delivery to foo's local Mailbox.
+      </para>
+      <para>
+        This feature is by default only available for locally
+	generated messages. If you want it to be accessible for
+	messages delivered from remote as well, set the Exim macro
+	COND_LOCAL_SUBMITTER to true. If you do not want this at all,
+	set the macro to false. Please note that the userforward
+	router uses this feature to get error messages delivered, i.e.
+	notifying the user of a syntax error in her
+	<filename>.forward</filename> file.
+      </para>
+    </section>
+    <section> <title>Using more complex deliveries from alias files</title>
+      <para>
+	Delivery to arbitrary files, directory or to pipes in the
+	<filename>/etc/aliases</filename> file is disabled by default
+	in the Debian Exim 4 packages. The delivery process including the
+	program being piped to would run as the exim admin-user
+	Debian-exim, which might open up security holes.
+      </para>
+      <para>
+	Invoking pipes from <filename>/etc/aliases</filename> file is
+	widely considered obsolete and deprecated. The Debian Exim
+	package maintainers would like to suggest using a dedicated
+	router/transport pair to invoke local processes for mail
+	processing. For example, the Debian mailman package contains a
+	<filename>/usr/share/doc/mailman/README.Exim4.Debian</filename> file
+	that gives a good example how to implement this. Using a
+	dedicated router/transport pair have the following advantages:
+	<itemizedlist>
+	  <listitem>
+	    <para>
+	      The router/transport pair can be put in place by another
+	      package, giving a well-defined transaction point between
+	      Exim 4 and $PACKAGE.
+	    </para>
+	  </listitem>
+	  <listitem>
+	    <para>
+	      Not allowing pipe deliveries from alias files makes it
+	      harder to accidentally run programs with wrong
+	      privileges.
+	    </para>
+	  </listitem>
+	  <listitem>
+	    <para>
+	      It is possible to run different pipe processes under
+	      different accounts.
+	    </para>
+	  </listitem>
+	  <listitem>
+	    <para>
+	      Even if only invoking a single local program, it is easier
+	      to do with your dedicated router/transport since you won't
+	      need to change this file, making automatic updates of this
+	      file possible for future versions of the Exim 4 packages. If
+	      you do local changes here, dpkg conffile handling will
+	      bother you on future updates.
+	    </para>
+	  </listitem>
+	</itemizedlist>
+	If you insist on using <filename>/etc/aliases</filename> in
+	the traditional way, you will need to activate the
+	respective functions by setting the transport options on the
+        system_aliases router appropriately. Macros are defined to make
+	this easier. See
+       
+<filename>/etc/exim4/conf.d/router/400_exim4-config_system_aliases</filename>
+	for information about which macros are available. You might
+        find the address_file, address_pipe and/or address_directory
+        transports that are used for the userforward router helpful in
+	writing your own transports for use in the system_aliases router.
+      </para>
+      <para>
+	If any of your aliases expand to pipes or files or directories
+	you should set up a user and a group for these deliveries to run
+	under. You can do this by setting the "user" and - if necessary
+	- a "group" option and adding a "group" option if necessary. 
+	Alternatively, you can specify "user" and/or "group" on the
+	transports that are used.
+      </para>
+    </section>
+
+    <section> <title>Putting Exim 4 and UUCP together</title>
+      <para>
+	UUCP is a traditional way to execute remote jobs (e.g. spool
+	mails), and as a lot of old things there are much more than one
+	way to do it. However, today, the ways to handle it have boiled
+	down to more or less two different ways.
+      </para>
+      <para>
+	Our recommendation is to use bsmtp/rsmtp wherever possible,
+	because it supports all kinds of mail addresses (also the empty
+	ones in bounces), and is also better from the security point of
+	view.
+      </para>
+      <section>	<title>Sending mail via UUCP</title>
+	<section> <title>rmail with full addresses</title>
+	  <para>
+	    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:
+	  </para>
+	  <programlisting>
+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
+	  </programlisting>
+	  <para>
+	    However, all recipients are handled via the command line, so
+	    you are discouraged to use it.
+	  </para>
+	</section>
+	<section> <title>bsmtp/rsmtp</title>
+	  <para>
+	    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.
+	  </para>
+	  <para>
+	    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):
+	  </para>
+	  <programlisting>
+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
+	  </programlisting>
+	  <para>
+	    and this if it wants bsmtp as the command:
+	  </para>
+	  <programlisting>
+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
+	  </programlisting>
+	  <para>
+	    Of course, these examples can be extended for e.g. 
+	    compression (but you can also use ssh for compression, if
+	    you want).
+	  </para>
+	</section>
+	<section> <title>The router</title>
+	  <para>
+	    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.
+	  </para>
+	  <programlisting>
+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
+	  </programlisting>
+	  <para>
+	    The file <filename>/etc/exim4/uucp</filename> looks like:
+	  </para>
+	  <programlisting>
+*.do.main       uucp.name.of.remote.side
+	  </programlisting>
+	</section>
+	<section> <title>Speaking UUCP with the smarthost</title>
+	  <para>
+	    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 <filename>/etc/exim4/uucp</filename> is
+	    not needed in this case.
+	  </para>
+	</section>
+      </section>
+      <section>	<title>Receiving mail via UUCP</title>
+	<section> <title>Allow UUCP to use any envelope address</title>
+	  <para>
+	    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.
+	  </para>
+	</section>
+	<section> <title>If you get batched smtp</title>
+	  <para>
+	    Allow uucp to execute rsmtp via
+	    <programlisting>
+commands        rmail rnews rsmtp
+	    </programlisting>
+	    in your <filename>/etc/uucp/sys</filename>, and ask the
+	    sending site to use rsmtp (and not bsmtp) as the batched
+	    command.
+	  </para>
+	</section>
+      </section>
+    </section>
+    <section> <title>Notes on running SpamAssassin at SMTP time</title>
+       <para>
+         Exim can run
+         <ulink url="https://spamassassin.apache.org/">
+         SpamAssassin</ulink> while receiving a message by SMTP which
+         allows one to avoid acceptance of spam messages. The Debian
+         configuration contains some example code for running SpamAssassin,
+         but like all filtering this needs to be handled carefully.
+       </para>
+       <para>
+         SpamAssassin's default report should not be used in a add_header
+         statement since it contains empty lines. (This triggers e.g.
+         Amavis' warning "BAD HEADER SECTION, Improper folded header field
+         made up entirely of whitespace".) This is a safe, terse alternative:
+         <programlisting>
+            clear_report_template
+            report (_SCORE_ / _REQD_ requ) _TESTSSCORES(,)_ autolearn=_AUTOLEARN_
+         </programlisting>
+       </para>
+       <para>
+         Rejecting spam messages: Do not reject spam-messages received on
+         (non-spam) mailing lists, this can/will cause auto-unsubscription.
+         This also applies to messages received via forwarding services
+         (e.g. @debian.org addresses). If theses messages are rejected the
+         forwarding services will need to send a bounce address to the
+         spammer and will probably disable the forwarding if it happens all
+         the time. You will need to have some kind of whitelist to exclude
+         these hosts.
+       </para>
+       <para>
+         Security considerations: By default <command>spamd</command>
+         runs as root and changes uid/gid to the requested user to run
+         SpamAssassin. The example uses SpamAssassin default non-privileged
+         user (nobody) which prevents use of Bayesian filtering since this
+         requires persistent storage. You might want to setup a dedicated
+         user for exim spam scanning and use that one, either for a separate
+         SpamAssassin user profile or to run SpamAssassin as non-privileged
+         user.
+       </para>
+    </section>
+  </section>
+
+  <section> <title>Updating from Exim 3</title>
+    <para>
+      If you use <command>exim4-config</command> from Debian, you will
+      get the debconf based configuration scheme that is intended to
+      cover the majority of cases.
+    </para>
+    <para>
+      If <command>exim4-config</command> is installed while an Exim 3
+      package is present on the system,
+      <command>exim4-config</command> tries to parse the Exim 3 config
+      file to determine the answers that were given to
+      <command>eximconfig</command> on Exim 3 installation. These
+      answers are then taken as default values for the debconf based
+      configuration process. Be warned! <command>eximconfig</command>
+      from the Exim 3 packages does not record the explicit answers
+      given on Exim 3 configuration. So we have to guess the answers
+      from the Exim 3 configuration file
+      <filename>/etc/exim/exim.conf</filename>, which is bound to fail
+      if the config file has been modified after using
+      <command>eximconfig</command>.
+    </para>
+    <para>
+      This is the reason why we refrained from doing a "silent update", but
+      only use the guessed answers to get reasonable defaults for our
+      debconf based configuration process.
+    </para>
+    <para>
+      Please note that we do not use the
+      <command>exim_convert4r4</command> script, but try to configure
+      the Exim 4 package in the same way Exim 3 was. This will
+      hopefully aid future updates.
+    </para>
+    <para>
+      If you have used a customized Exim 3 configuration, you can of
+      course use <command>exim_convert4r4</command>, and install the
+      resulting file as <filename>/etc/exim4/exim4.conf</filename>
+      after careful inspection. Exim 4 will then use that file and
+      ignore the file that it generated from the debconf
+      configuration. To aid future updates, we do, however, encourage
+      you not to use the
+      <filename>exim_convert4r4-generated</filename> file verbatim but
+      instead drop appropriate configuration snippets in their
+      appropriate place in <filename>/etc/exim4/conf.d</filename>.
+    </para>
+  </section>
+  <section> <title>Misc Notes</title>
+    <section> <title>PAM</title>
+        <para>
+	  On Debian systems the PAM modules run as the same user
+	  as the calling program, so they cannot do anything you
+	  could not do yourself, and in particular cannot access
+	  <filename>/etc/shadow</filename> unless the user is in group
+	  shadow. - If you want to use
+	  <filename>/etc/shadow</filename> for Exim's SMTP AUTH you
+	  will need to run exim as group shadow.  Only
+	  exim4-daemon-heavy is linked against libpam. We suggest using
+	  saslauthd instead.
+        </para>
+    </section>
+    <section> <title>Account name restrictions</title>
+        <para>
+          In the default configuration, Exim cannot locally deliver
+          mail to accounts which have capitals in their name. This is
+          caused by the fact that Exim converts the local part of incoming
+          mail to lower case before the comparison done by the
+          check_local_user directive in routers is done.
+        </para>
+	<para>
+          The router option caseful_local_part can be used to control
+          this, and we decided not to set this option in the Debian
+          configuration since it would be a rather big change to Exim's
+          default behavior.
+        </para>
+    </section>
+    <section> <title>No deliveries to root!</title>
+        <para>
+            No Exim 4 version released with any Debian OS can run
+	    deliveries as root. If you don't redirect mail for root via
+            <filename>/etc/aliases</filename> to a nonprivileged
+            account, the mail will be delivered to
+	    <filename>/var/mail/mail</filename> with permissions 0600 and
+            owner mail:mail.
+	</para>
+	<para>
+	    This redirection is done by the mail4root router which
+            is last in the list and will thus catch mail for root that has not
+            been taken care of earlier.
+        </para>
+    </section>
+    <section> <title>Debugging maintainer and init scripts</title>
+        <para>
+	    Most of the scripts that come with this Debian package do a
+	    <command>set -x</command> if invoked with the environment
+	    variable EX4DEBUG defined and non-zero. This is particularly
+	    handy if you need to debug the maintainer scripts that are
+	    invoked during package installation. Since dpkg redirects
+	    stdout of maintainer scripts, calling dpkg with EX4DEBUG
+	    set might yield interesting results. If in doubt, invoke
+	    the maintainer scripts with EX4DEBUG set manually directly
+	    from the command line.
+        </para>
+    </section>
+    <section> <title>SELinux</title>
+        <para>
+            There is no SELinux policy for Exim4 available so far.
+	    Until this is resolved, users should use postfix or
+	    sendmail if they intend to run SELinux.
+        </para>
+	<para>
+	    The Debian Exim4 maintainers would appreciate if
+            somebody could write an SELinux policy. We will gladly
+	    use them in the Debian packages as long as there is
+	    somebody available to test, debug and support.
+	</para>
+    </section>
+    <section> <title>misc</title>
+        <itemizedlist>
+    	    <listitem>
+    	        <simpara>
+                    <command>convert4r4</command> is installed as
+                    <filename>/usr/sbin/exim_convert4r4.</filename>
+		</simpara>
+	    </listitem>
+    	    <listitem>
+    	        <simpara>
+                    The charset for $header_foo expansions defaults to
+		    UTF-8 instead of ISO-8859-1.
+		</simpara>
+	    </listitem>
+    	    <listitem>
+    	        <simpara>
+		    <ulink url="http://marc.merlins.org/linux/exim/">
+		    Marc Merlin's Exim 4 Page</ulink> has a lot of ACL
+		    examples.
+		</simpara>
+	    </listitem>
+    	    <listitem>
+    	        <simpara>
+		    For an example of Exim usage in a
+		    <emphasis>large</emphasis> installation, see
+		    Tony Finch's 
+		    <ulink
+url="http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/talks/2005-02-eximconf/">
+paper</ulink>
+		    about the Exim installation at University of Cambridge:
+		</simpara>
+	    </listitem>
+	</itemizedlist>
+    </section>
+  </section>  
+  <section> <title>Debian modifications to the Exim source</title>
+    <itemizedlist>
+      <listitem>
+        <simpara>
+		Install the exim binary as /usr/sbin/exim4 instead of 
+		/usr/sbin/exim-&lt;version&gt; with a symlink /usr/sbin/exim. Also
+		adapt the documentation.
+        </simpara>
+      </listitem>
+      <listitem>
+        <simpara>
+		Make the build reproducible. Pull date/time from debian/changelog
+		and use it as build time instead of using __DATE__.
+        </simpara>
+      </listitem>
+      <listitem>
+        <simpara>
+		Documentation updates
+        </simpara>
+        <itemizedlist>
+	  <listitem>
+            <simpara>
+                  Mention how to install the Debian packaged perl-modules needed
+                  for eximstats' graphs.
+            </simpara>
+	  </listitem>
+	  <listitem>
+            <simpara>
+                  Add a warning about convert4r4.
+            </simpara>
+	  </listitem>
+	  <listitem>
+	    <simpara>
+		  Point to the <ulink
+		  url="mailto:pkg-exim4-users@lists.alioth.debian.org">
+		  Debian-specific mailing list</ulink> instead of
+		  the <ulink url="mailto:exim-users@exim.org">official
+		  exim-users list</ulink>.
+	    </simpara>
+	  </listitem>
+	</itemizedlist>
+      </listitem>
+      <listitem>
+        <simpara>
+          <ulink
+           url="http://marc.merlins.org/linux/exim/files/sa-exim-current/">localscan_dlopen.patch</ulink>:
+		This patch makes it possible to use and switch between
+		different local_scan
+		functions without recompiling Exim. Use
+		local_scan_path = /path/to/sharedobject to utilize
+		local_scan() in <filename>/path/to/sharedobject</filename>.
+        </simpara>
+      </listitem>
+    </itemizedlist>
+  </section>
+
+  <section> <title>Credits</title>
+    <para><variablelist>
+	<varlistentry>
+	  <term><ulink url="mailto:aba@not.so.argh.org">Andreas
+	      Barth</ulink></term>
+	  <listitem>
+	    <simpara>UUCP documentation</simpara>
+	  </listitem>
+	</varlistentry>
+	<varlistentry>
+	  <term>Dan Weber, Ryen Underwood</term>
+	  <listitem>
+	    <simpara>inetd/xinetd documentation</simpara>
+	  </listitem>
+	</varlistentry>
+      </variablelist>
+    </para>
+  </section>
+
+</article>