Differences between revisions 58 and 59
Revision 58 as of 2012-12-31 11:16:54
Size: 31855
Comment: spfquery is provided by spf-tools-perl in Squeeze
Revision 59 as of 2013-01-07 13:40:50
Size: 31779
Editor: OsamuAoki
Comment: The stupid /etc/exim4/passwd.client in 2006 has been changed. Let's keep the tone of text more positive tone.
Deletions are marked like this. Additions are marked like this.
Line 381: Line 381:
  * [[http://wiki.debian.org/GmailAndExim4|Gmail and Exim4 in this very wiki]] contains outdated information, and the way it informs people to edit /etc/exim4/passwd.client shows that the author does not understand what he is doing. No, the author of _this_ FAQ does not have the time to improve the Gmail HOWTO document, sorry.   * [[http://wiki.debian.org/GmailAndExim4|Gmail and Exim4 in this very wiki]] used to contain outdated information. No, the author of _this_ FAQ does not have the time to improve the Gmail HOWTO document, sorry. Read them only as secondary information.

Back to PkgExim4

1. Debian Exim4 User FAQ

This is work in progress, so it is probably not yet very helpful.

Contents

  1. Debian Exim4 User FAQ
    1. Meta
      1. Where can I find more information about Debian exim4
      2. I have a question
      3. I want to contribute
    2. Debian Configuration
      1. How do I re-execute the debconf-driven configuration?
      2. I get the error "Mailing to remote domains not supported".
      3. How does exim find out its host name to use in HELO/EHLO?
      4. How can I integrate third-party tools with Exim?
      5. What do the "DEBCONFfooDEBCONF" macros in the Debian configuration do?
      6. Why does "ps" display Exim's account name only as a number?
    3. Common issues
      1. When I try to deliver a message via SMTP to my Exim, I get "550 relay not permitted"
      2. How can I debug SMTP AUTH and/or other SMTP aspects
      3. Exim stops delivery after ten messages are received
      4. I don't have a FQDN on this machine and just want it to send notifications by email (to outside domains) via various scripts. Can exim do this? How?
      5. Where are my logs?
      6. How can I automatically replace my local username in all mail with my real public address?
      7. Why does exim take such a long time to start?
    4. Networking and ISP issues
      1. my exim cannot connect to the outside
      2. my exim cannot be connected to from the outside
      3. How do I configure exim to use a different port to receive mail
      4. How do I configure exim to use a different port to send mail
    5. Routing
      1. I am trying to have exim forward mail to some internal hosts, but all I am getting is "all relevant MX records point to non-existent hosts"
      2. What do "lowest numbered MX record points to local host" or "remote host address is the local host" mean?
      3. How do I configure a catch-all?
      4. How can I create a blacklist to deny specific hosts / ip addresses?
    6. TLS issues
      1. GnuTLS
      2. Building against OpenSSL
    7. Content Filtering
      1. Exim's built-in filter or sa-exim?
    8. Packaging issues
      1. exim4-config should depend on exim4-base, shouldn't it?
      2. Why are you not using exim's built-in SPF interface?
      3. The user name Debian-$PACKAGE is too long: it misaligns ls output and is truncated by ps and atop. And it's ugly!
    9. Questions needing answers
    10. Recommendable and not-so-recommendable third-party documentation
      1. I have configured exim with help of a non-Debian HOWTO. It doesn't work.


1.1. Meta

1.1.1. Where can I find more information about Debian exim4

http://pkg-exim4.alioth.debian.org/ has a truckload of links to documentation


1.1.2. I have a question

Do not edit this page to ask your question. Ask it on the Debian exim4 user mailing list where it is less likely to be missed. It might be possible that an answer appears here quickly.


1.1.3. I want to contribute

It is vital that this web page does not contain false information. It is appreciated if you could announce your changes on the Debian exim4 user mailing list to have them reviewed.

Of course, if your change is trivial, you don't need to do that.


1.2. Debian Configuration

1.2.1. How do I re-execute the debconf-driven configuration?

Debian's configuration is factored out into a dedicated package. Thus, dpkg-reconfiguring exim4, exim4-base or one of the daemon packages is not going to work. Please use  dpkg-reconfigure exim4-config or edit /etc/exim4/update-exim4.conf.conf directly.

More information can be found in the manual page for update-exim4.conf.


1.2.2. I get the error "Mailing to remote domains not supported".

This is exim's post-installation default. If you want to participate in global e-mail, reconfigure your exim and choose a different "General type of mail configuration".


1.2.3. How does exim find out its host name to use in HELO/EHLO?

Some paranoid third parties check the HELO/EHLO name of a host delivering mail to them. If the HELO/EHLO name does not match the reverse DNS of the originating IP, the message is rejected or scored appropriately.

The name used by Exim in EHLO/HELO is pulled from configuration option primary_hostname. Debian's exim4 default configuration does not set primary_hostname. Exim then defaults to uname() to find the host name. If that call only returns one component, gethostbyname() or getipnodebyname() is used to obtain the fully qualified host name.

If your Exim HELOs as localhost.localdomain, then you have most probably a misconfigured /etc/hosts created by some versions of the Debian installer. In this case, please fix your /etc/hosts.

Please refrain from using primary_hostname unless you cannot avoid using it. It enhances the complexity of your configuration and leads to error issues that are a hell to debug.


1.2.4. How can I integrate third-party tools with Exim?

On first look, Debian's exim configuration is radically different from what Upstream and the larger part of the rest of the world use. On second look, we're not _that_ different.

Most probably the documentation of the third-party tool is going to help you to create a working integration in Debian's exim configuration. You might not be able to use their point-and-drool step-by-step instructions, but with a moderate amount of reading and abstraction is going to deliver a working configuration. The documentation delivered with Debian's exim4 packages might help.


1.2.5. What do the "DEBCONFfooDEBCONF" macros in the Debian configuration do?

When the Exim daemon is started, the dpkg-conffiles in /etc/exim4 are post-processed to the result /var/lib/exim4/config.autogenerated, which is the configuration file that Exim reads. In this post-processing step, done by update-exim4.conf, the DEBCONFfooDEBCONF strings are replaced with values pulled from /etc/exim4/update-exim4.conf.conf and system configuration.

Please note that the string DEBCONF is kind of a misnomer since the strings are _not_ directly pulled from the Debconf database, but from user-editable conffiles instead. This is a common misunderstanding.

For more information, read the update-exim4.conf man page.


1.2.6. Why does "ps" display Exim's account name only as a number?

That's documented behavior of ps. When the account name does not fit the table layout (as it is the case for Debian-exim), ps displays the uid as a number.


1.3. Common issues

1.3.1. When I try to deliver a message via SMTP to my Exim, I get "550 relay not permitted"

Exim does not relay by default for any host. If you want to use your exim as a smart host, please enter the IP ranges your exim should relay for into dc_relay_nets in /etc/exim4/update-exim4.conf.conf or reconfigure exim using debconf.

Please note that you cannot use this mechanism if your client is on a dynamic IP as your client's IP address changes. In these case, use SMTP AUTH to have your client authenticate before relaying.

If this does work, verify that you're actually talking to your exim. Some ISPs block incoming SMTP connections (port tcp/25 blocking) or redirect these connections to their own server.


1.3.2. How can I debug SMTP AUTH and/or other SMTP aspects

Exim's logs are usually quite helpful. Use them!

A possible strategy is to find out first which side of the communication is causing the trouble. So it might be a good idea to find out whether the other side of the conversation causes the trouble.

You can use telnet or netcat to directly connect to the other side and manually run the SMTP transaction. If TLS is used, both openssl and gnutls-cli can act as a telnet replacement which can use TLS on the network side of the connection.

An extremely useful tool for this kind of debugging is swaks. If sending a test message with swaks --tls --auth --to some.address@target.example --server your.smarthost.example succeeds, then you know that your ISP's authentication works. If your ISP does not offer TLS, omit the --tls and allow exim to use plain text passwords on the unencrypted connection.

If this works, try to debug your own exim by trying to send a mail over the command line with appropriate debugging: < /dev/null exim -d-all+transport+lookup some.address@target.example. If you can't interpret the resulting output yourself, send it to the exim4 mailing list _after_ removing your password from the debug output (which is mentioned in the clear). If you want to have even more debug info, call < /dev/null exim -d some.address@target.example. Please only send full debug info to the mailing list when you're explicitly asked to do so.

Please note that it might be necessary to know about SMTP and have some experience for the debugging session to succeed.


1.3.3. Exim stops delivery after ten messages are received

In the default configuration, exim delivers the first ten messages received over a single SMTP connection immediately, and places the following messages on the queue. This is a feature geared to avoid load spikes in cases where many messages are delivered at once, and it is also exim's default (see Exim specification chapter 14.10 and 44.3).

By default, the Exim daemon starts a queue runner every 30 minutes, and the queued messages will be delivered then, in a serialized way.

This situation is most frequently experienced by sites running fetchmail, where it can be annoying to have messages delayed by up to 30 minutes. One possible fix is to increase the smtp_accept_queue_per_connection configuration value. This option is not in the default configuration, hence the default of 10 is used by exim.

It is, however, a better fix for the fetchmail case to have fetchmail execute exim -q after finishing the retrieving process. This decreases the load spike which would otherwise be experienced if one had simply increased smtp_accept_queue_per_connection.

You can specify a command to execute in fetchmailrc using the postconnect user option, e.g. postconnect "/usr/sbin/exim4 -q", in the appropriate "poll" line in your fetchmailrc. This, of course, assumes that the user running fetchmail has the appropriate privileges to cause an exim queue run (for example, it is a member of the Debian-exim group).

Alternatively, you can configure fetchmail to deliver incoming mail directly to a local mail delivery agent, such as procmail. You can do this with the mda keyword in the defaults or poll section in your fetchmail configuration file, for example: defaults mda "/usr/bin/procmail -d %T. This way, your incoming mail is not processed by exim at all, so you don't have any filtering, aliases, redirection, forwarding etc.


1.3.4. I don't have a FQDN on this machine and just want it to send notifications by email (to outside domains) via various scripts. Can exim do this? How?

Most scripts deliver e-mail either to /usr/lib/sendmail or via SMTP to localhost. Debian exim4 does always accept messages delivered via /usr/lib/sendmail. If you want to deliver via SMTP to localhost, make sure to set dc_local_interfaces to 127.0.0.1 or answer the question "IP-addresses to listen on for incoming SMTP connections" during configuration appropriately. Debian exim always relays messages delivered via SMTP from localhost.

If your host name is not configured in the world wide DNS, you need to set the "System mail name" to an existing domain name, or your messages will be rejected by most systems on the Internet due to sender verification.

If you have a smart host available, use it by choosing "mail sent by smarthost; no local mail" (dc_eximconfig_configtype='satellite'). Have the smarthost either accept messages from your host by virtue of its IP address relay list or use SMTP authentication.

If you are in a situation where you must use direct SMTP delivery to the target MX, choose "internet site; mail is sent and received directly using SMTP" (dc_eximconfig_configtype='internet'). This is not a 100 % fit of your needs as your system will also do local deliveries, so you need to make sure that you do not send local messages to addresses that exist locally as they will be delivered locally which might be undesired.

A lot of scripts generate syntactically bad headers which might cause a legitimate message sent out by your system to be classified as spam. If your system is sending out status messages to you, it is a good idea to have your sender IP address whitelisted on the receiving end. That way it is ensured that your status messages are actually received. If you send out messages to third parties, such whitelisting is not possible and you'll have to bite the bullet and generate "clean" messages with correct headers and non-spammy contents. This includes a valid sender in both message Envelope and headers.

If the target of the message does sender callout verification, make sure that the sender address your scripts use actually exists.


1.3.5. Where are my logs?

Exim 4 in Debian logs to three files in /var/log/exim4: mainlog, rejectlog and paniclog. Paniclog should always be empty, and the daily cron job sends out warnings if it is not since this is a misconfiguration issue you should look after.

Exim 4 in Debian does not log through syslog, so /var/log/mail.* is the wrong place to look!


1.3.6. How can I automatically replace my local username in all mail with my real public address?

You can use filename>/etc/email-addresses for this purpose, which will cause exim to change Reply-To, From, Sender and "MAIL FROM:" accordingly. The file includes examples and has a man page.


1.3.7. Why does exim take such a long time to start?

Exim will try to lookup the primary hostname at startup. It will first search for an AAAA record (IPv6), therefore triggering a DNS lookup even if there is an IPv4 address for the hostname listed in /etc/hosts.

There is a number of ways to fix this:

  • use dc_minimaldns='true'. Either edit /etc/exim4/update-exim4.conf.conf or use dpkg-reconfigure exim4-config)

  • Use the FQDN as hostname in /etc/hostname. That means using "foo.example.com" instead of just "foo". You have to execute "hostname -F /etc/hostname" to activate the change to /etc/hostname.

  • Add an IPv6 record for your hostname (listed in /etc/hostname) to /etc/hosts. You can check with "getent hosts your_hostname" whether this was successful.

  • Disable IPv6 host lookups in exim by setting "dns_ipv4_lookup = *".
  • Set "primary_hostname = your_hostname"
  • If this delay happens only during or directly after Debian installation, it is likely that you have are hit by a bug in base-config prior to 2.53.8, where exim is invoked with a signal handler for SIGTERM installed. Thus, stopping this exim daemon takes a long time because exim keeps ignoring the SIGTERM. This is a one-shot issue, though, and fixed in base-config 2.53.8 and later (see #301988).


1.4. Networking and ISP issues

1.4.1. my exim cannot connect to the outside

It might be possible that your ISP blocks outgoing connections to port TCP/25 of external hosts. This prevents computers on the ISP network from directly sending out e-mail. Many ISPs do this as a security precaution because compromised computers (called "Zombies") are frequently used to send out Spam.

On these networks, you cannot deliver e-mail directly. You need to use a smart host for outgoing mail. If your ISP offers a smart host for outgoing mail, it is probably a good idea to use it.

If your ISP does not offer a smart host or you want to deliver via a trusted third party, you need to have your exim deliver the messages to the smart host on a different port, for example tcp/587.


1.4.2. my exim cannot be connected to from the outside

It might be possible that your ISP blocks incoming connections to port TCP/25 of their customer's machines. This prevents computers on the ISP network from directly receiving e-mail. Many ISPs do this as a security precaution because misconfigured SMTP servers can be an open relay and thus be abused to send out Spam.

If you want to run a MX server on such a connection, you're out of luck. It is not possible to use a different port for MX servers since the Internet Standards don't offer the possibility to tell delivering hosts to try delivery on a different port.

If you want to run a smarthost on such a connection, it might be a solution to configure exim to listen on port tcp/587 additionally. Please note that the Internet standards demand that you only accept e-mail after authentication if the connection is made to TCP/587. Otherwise, you might open yourself to receiving and sending Spam.


1.4.3. How do I configure exim to use a different port to receive mail

Set SMTPLISTENEROPTIONS to the appropriate value in /etc/default/exim4. For example, use -oX 25:587 -oP /var/run/exim4/exim.pid to have exim listen on tcp/25 and tcp/587. The -oP parameter is necessary in this case since exim does not create a pid file automatically if -oX is given on the command line. If you omit the -oP parameter, the init script will malfunction.


1.4.4. How do I configure exim to use a different port to send mail

This does only make sense when delivering to a smarthost. Starting with exim4 4.63-5, you can enter smarthost.example::portnumber as a smarthost to have exim deliver to a different port.

With earlier exim versions, you need to modify the smarthost and hub_user_smarthost routers manually.


1.5. Routing

1.5.1. I am trying to have exim forward mail to some internal hosts, but all I am getting is "all relevant MX records point to non-existent hosts"

A probable cause for this might be that all MX records for the offending domain point to site local or link local IP addresses, which are ignored by the dnslookup router to protect from misconfigured external domains. The default configuration has relaxed checking for domains that the local system is configured to allow relaying to, so adding the offending domain to dc_relay_domains will most probably help. Please note that this entry might be necessary anyway to bypass relay control for the domains in question.

Please note that no domain on the public Internet should have MX records pointing to site local or link local IP addresses, so you might check your externally visible MX records.

If this doesn't help, try analyzing the output of exim -d -bt some.local.part@the.offending.domain.example

Upstream Exim FAQ Q0302 might help as well.


1.5.2. What do "lowest numbered MX record points to local host" or "remote host address is the local host" mean?

This is covered in Upstream Exim FAQ Q0301. The Debian default configuration has the hubbed_hosts router mentioned there already defined. Its configuration file is /etc/exim4/hubbed_hosts, and some documentation can be found in /etc/exim4/conf.d/router/150_exim4-config_hubbed_hosts.


1.5.3. How do I configure a catch-all?

A catch-all is most easily implemented by modifying the system_aliases router. It causes all local parts that have no explicit alias entry are aliased to one single target, unconditionally.

To enable this:

  • 1 add a * to the lsearch statement in the system_aliases router, giving lsearch* 1 add a line *: your.catchall.target.example to /etc/aliases

If you want mail for some other targets to be processed as before, you need to alias them to themselves (other-target: other-target) to prevent them from being caught by the catch-all.

It is no longer necessary to alias the catch-all target to itself as it was with previous versions of Exim.

Please note that it is a really bad idea to use a catch all in these days since incredible amounts of spam are received on these accounts. It is far superior to tell Exim which local parts exist so that it is possible to reject spam to non-existing addresses before actually accepting it.


1.5.4. How can I create a blacklist to deny specific hosts / ip addresses?

The access lists that come with Debian's exim4 configuration have some infrastructure for that and are extensively documented. Their function can be controlled with files placed in /etc/exim4. See also the manual page for exim4_files (available from exim4 4.62-2 on and linked to by PkgExim4) for explanation of these files.

There is also macro-driven infrastructure to use DNS-based block lists. See the ACL files and the Debian exim4 documentation for more information.

Please note that this needs basic familiarity with Exim ACLs and lookups.


1.6. TLS issues

1.6.1. GnuTLS

Exim4 in Debian uses GnuTLS, not OpenSSL, by default. Unfortunately, there still are a few rough edges in the GnuTLS stuff. There are several bugs tracking these issues in the BTS. Anyone having a problem with a Nokia / Symbian client should check out 390712 - there is a patch there to enable the gnutls_compat_mode option.

GnuTLS uses much entropy. On some systems, it uses more entropy than the system is generating. This has become a problem since the kernel developers decided to drop the network card as an entropy source in early 2.6.x due to the possibility of it being manipulated externally. You can find out how much entropy your system has available by looking into /proc/sys/kernel/random/entropy_avail. If that number stays under 100 for more than a few seconds, you have a problem. Possible solutions are using a hardware random number generator your system might be equipped with, or using a special solution that allows using a microphone connected to your system's audio in as an entropy source.

While replacing /dev/random with /dev/urandom is commonly touted as a possible solution, we advise against doing so since this will decrease the security of _all_ cryptographic functions of your system.

A constant source of entropy starvation is the generation of a file containing an RSA key and parameters needed for the Diffie-Hellman key change algorithm. That file is deleted in the daily cron job as recommended by the upstream Exim docs, and normally, the next exim process starting up a TLS session generates a new set of parameters. This, however, uses _lots_ of entropy, and exim blocks if not enough entropy is available, leading to session timeouts. More information about this can be found in the Exim specification chapter 38.3.

Since 4.52-2, if the package gnutls-bin is installed, the daily cron job does not simply remove the file but tries to generate a new parameter file. Only if this succeeds, the old parameter file is replaced by the new, so in theory, exim should always find a recent parameter file to use, avoiding the blocking situation.

In 4.63-4, that process was touched again and it can now use an installed openssl package as well as gnutls-bin to generate the new file.

Please note that both Debian and upstream are currently in dire need of people knowledgeable with GnuTLS and exim to debug these issues. If you can do this, please get in touch with the maintainers.

1.6.2. Building against OpenSSL

Starting with 4.60-3, the package can be rebuilt against OpenSSL by uncommenting the # OPENSSL:=1 line in debian/rules. This might result in a GPL violation, so be sure to check this with your legal department before actually doing so.


1.7. Content Filtering

1.7.1. Exim's built-in filter or sa-exim?

Exim can do content filtering (spam and malware) itself via ACLs. This is documented in spec.txt chapter 40. A lot of newbies use sa-exim because this turns out to be the first hit on Google for "exim spamassassin". This is not necessary for most environments since exim has its own spamassassin interface.

It would be good to have a comparison of sa-exim and exim here. Volunteers?

  • sa-exim allows usage of report_safe


1.8. Packaging issues

1.8.1. exim4-config should depend on exim4-base, shouldn't it?

No, it shouldn't. It's entirely possible to (want to) install an exim4-config package on a machine that doesn't run exim4 - for instance in order to examine the configuration before upgrading the machine to the exim4 packages using that configuration.

exim4-base correctly depends on a package providing one of the virtual packages exim4-config{,-2}. The requirement is that installing exim4 ensures that an appropriate configuration is installed, not vice versa. (Answer by Adam D. Barratt, in response to #310750, thanks!)


1.8.2. Why are you not using exim's built-in SPF interface?

exiscan 4.34-22 introduced support for the Sender Policy Framework by means of a spf ACL condition. We have chosen not to use this command, but implement this functionality in the Debian packages by means of external calls to spfquery

Rationale:

  • Calling spfquery is a reliable method, because it's the most transparent and easy to debug. It is also the method we have tested more thoroughly and are most experienced with.
  • We do not want to drag in another library dependency. That would add more potential for bugs and maintenance work than a configuration snippet that is disabled by default.
  • We haven't verified that all the features of spfquery are available using built-in support as well (in particular, support for X-SPF-Guess header, or the ability to add user extensions that rely on the same checks).

If you'd rather use exiscan's own SPF interface, you need to rebuild exim. The source package offers infrastructure to build your own exim4-daemon-custom with your own feature set.


1.8.3. The user name Debian-$PACKAGE is too long: it misaligns ls output and is truncated by ps and atop. And it's ugly!

The user name Debian-$PACKAGE was chosen in late 2003 when we, the maintainers of the Debian exim4 package found it necessary to create an account for exim to run under during package installation. To avoid accidentally zapping a locally used account, we intended to use a name from a name space with low potential for name conflicts.

About the same time, Fabio Massimo Di Nitto started the same discussion on debian-devel.

In this thread, many things were said:

  • This should be decided by the LSB. However, to my knowledge, that step has not yet happened.
  • It needs to be in policy. However, policy has not been amended, and there is no bug filed against policy.
  • Purging a package should remove the account as well.
  • Special care needs to be taken to avoid removing an account that doesn't belong to us.
  • The numeric UID shouldn't be re-used.

For the namespaces, we have the following suggestions:

  • Prepend/Append "Debian" or "debian"
  • Prepend/Append a single capital letter

  • Prepend/Append an underscore

Unfortunately, the way to get a LSB solution will take way too long. Additionally, the LSB likes to have pre-existing use as example before they change the standard.

So, it was our job to decide which account name to use. Andreas Metzler and me chose Debian-$PACKAGE, while Peter Palfrader started using debian-$PACKAGE. So we currently have Debian-exim, Debian-console-log, debian-tor, debian-mixminion and debian-sks.

Again, the goal was to create accounts that don't conflict with other, or with manually created accounts, and to get pre-existing use before trying to change the LSB and even Debian policy.

Migrating from one account name to another is extremely painful and error-prone since one needs to meddle with the local account database and has to optionally chown files. Additionally, it is necessary to change every script that accesses the account. To put it short: It's something you want to avoid.

This is also the reason why the account names used by these packages will not likely change before a namespace is dedicated and allocated either in the LSB or in Debian policy. The maintainers reserve the right of hurling this FAQ in the direction of everybody filing bugs about the "ugly" account names, and to close the bugs in the process.

We would appreciate, however, if people would aid in getting the standardization process under way as soon as possible. This needs to be in policy, the sooner the better.


1.9. Questions needing answers


1.10. Recommendable and not-so-recommendable third-party documentation

1.10.1. I have configured exim with help of a non-Debian HOWTO. It doesn't work.

Unfortunately, a lot of third-party documentation has been written by people who do not fully understand how things work. They might have been successful in solving the issue at their hands, but challenges are so different that it is extremely improbable that the solution will hold in other situations.

It is thus advisable to take third-party HOWTOs with extreme caution and use them only as input for a local solution. Taking a third-party configuration snippet verbatim is like asking for extreme trouble.

In this FAQ entry, we'll link to third-party HOWTO documents and comment about what we think about their contents.

  • SMTP Relaying Via a Smarthost. This document shows basic understanding of the concepts in an abstract way, but gives questionable advice in detail.

    • The document gives a truckload of Debian-specific advice and does not say that it is Debian-specific. This suggests that the author does not have too much E-Mail admin experience, and nearly none outside a Debian environment.
    • Why does the document recommend changing our local configuration to use a hardcoded user name instead of the file lookup that we provide?
    • Why does the document recommend having Exim listen on Port 26 instead of using the standardized submission port 587?
    • The author has never heard of swaks and advocates manual debugging
    • The author rants about Debian's exim4 configuration scheme and calls it "confusing". In the same paragraph, he says that he didn't find out how to use a single, hand-crafted exim4.conf file. Considered that it is prominently documented in the README that /etc/exim4/exim4.conf takes absolute preference over all other configurations, it looks to me that the author of this HOWTO did not bother to read our documentation.
  • Installing and configuring Exim 4 on Debian. This document gives advice how to configure spamassassin, clamav and some implementation of "virtual domains". Please note that "virtual" is a very overused term and you might think of "virtual domains" as something different than the document's author might think. Additionally, the documentation uses exim's built-in content scanning interface to link to clamav, but uses sa-exim for spamassassin integration. This is double work since exim's built-in content scanning can link to spamassassin as well.

  • Gemischtes Doppel. This Document in German language isn't so bad, but it switches off all Debian automatisms and leaves the user out in the dark without updates.

  • debian:exim4 [dbmail] is a HOWTO about how to use exim4 with dbmail. I have to advise against using this howto for the following reasons:

    • The author himself claims to be not an expert on spamassassin, pam, clamav or exim4. Yet, he publishes his (wrong and misleading) findings.
    • He neither did manage to get saslauthd to work, nor mySQL. Both things are trivial to do if one has familiarized oneself with exim as it is necessary to run a mail server on the Internet.
    • It advises to use sa-exim "For Spamassassin auto-blocking". I don't know what auto-blocking is, but exim can use spamassassin at SMTP time natively and can also block depending on the spamassassin results. I have not yet seen a setup where sa-exim was actually needed.
    • At least the HOWTO uses our configuration and allows people to receive updates in the future.
  • Mailserver configuration with Debian, Exim, ClamAV & dspam is a document worth reading. It was written by somebody with understanding of the way the Debian packages of Exim4 work, and the document shows how to enable the suggested features while still making use of our Defaults. That's the way a HOWTO should be.

  • Gmail and Exim4 in this very wiki used to contain outdated information. No, the author of _this_ FAQ does not have the time to improve the Gmail HOWTO document, sorry. Read them only as secondary information.

  • Installation von Exim 4 - Update von exim 3 is one of the worst HOWTOs I have ever read. Advises to do everything that is a bad idea, starting from using update4r4 to using spamassassin with the outdated router/transport algorithm to replacing our configuration with the generated converted one. Thankfully, it's in German and has somewhat limited audience. Do not use.


Back to PkgExim4