Q0601: What does the error Neither the xxx router nor the yyy transport set a uid for local delivery of... mean?
A0601: Whenever Exim does a local delivery, it runs a process under a specific user and group id (uid and gid). For deliveries into mailboxes, and to pipes and files set up by forwarding, it normally picks up the uid/gid of the receiving user. However, if an address is directed to a pipe or a file by some other means, such an entry in the system alias file of the form
majordomo: |/local/mail/majordomo ...
then Exim has to be told what uid/gid to use for the delivery. This can be done either on the routerr that handles the address, or on the transport that actually does the delivery. If a pipe is going to run a setuid program, then it doesn't matter what uid Exim starts it out with, and so the most straightforward thing is to put
user = exim
on either the router or the transport. A setting on the transport overrides a setting on the router, so if the same transport is being used with several routers, you should set the user on it only if you want the same uid to be used in all cases.
In the default configuration, the transports used for file and pipe deliveries are the ones called address_file and address_pipe. You can specify different transports by setting, for example,
pipe_transport = special_pipe_transport
on the system_aliases router. Then you can set up special_pipe_transport
special_pipe_transport:
driver = pipe
user = ????
which will be used only for pipe deliveries from that one router. What you put for the ???? is up to you, and depends on the particular circumstances.
Q0602: Exim keeps crashing with segmentation errors (signal 11 or 139) during delivery. This seems to happen when it is about to contact a remote host or when a delivery is deferred.
A0602: This could be a problem with Exim's databases. Try running a delivery with debugging turned on. If the last line of the debug output is something like this:
locked /var/spool/exim/db/retry.lockfile
the crash is happening inside the DBM library. Check that your DBM library is correctly installed. In particular, if you have installed a second DBM library onto a system that already had one, check that its version of ndbm.h is being seen first. For example, if the new version is in /usr/local/include, check that there isn't another version in /usr/include. If you are using Berkeley db, you can set
USE_DB=yes
in your Local/Makefile to avoid using ndbm.h altogether. This is particularly relevant for version 2 (or later) of Berkeley db, because no ndbm.h file is distributed with it. Another thing you can try is to run
exim_dumpdb /var/spool/exim retry
to see if it also crashes, or build the test_dbfn tool and fiddle around with it. If both fail, it is most almost certainly a problem with your DBM library. You could try to update it, or force Exim to use another library. See the file doc/dbm.discuss.txt for hints about this.
Q0603: How can mails that are being routed through routers that do not set check_local_user be delivered under the uid of the recipient?
A0603: Q0601 contains background information on this. If you are using, say, an alias file to direct messages to specific mailboxes, you can use the user option on either the router or the transport to set the uid. What you put in the setting depends on how the required uid is to be found. It could be looked up in a file or computed somehow from the local part, for example.
Q0604: I want to use MMDF-style mailboxes. How can I get Exim to append the ctrl-A characters that separate indvidual emails?
A0604: Set the message_suffix option in the appendfile transport. In fact, for MMDF mailboxes you need a prefix as well as a suffix to get it working right, so your transport should contain these settings:
message_prefix = "\1\1\1\1\n" message_suffix = "\1\1\1\1\n"
Also, you need to change the check_string and escape_string settings so that the escaping happens for lines in the message that happen to begin with the MMDF prefix or suffix string, rather than ``From'' (the default):
check_string = "\1\1\1\1\n" escape_string = "\1\1\1\1 \n"
Adding a space to the line is sufficient to prevent it being taken as a separator.
Q0605: If a user's mailbox is over quota, is there a way for me to set it up so that the mail bounces to the sender and is not stored in the mail queue?
A0605: In the retry section of the configuration, put
*@your.dom.ain quota
That is, provide no retry timings for over quota errors. They will then bounce immediately. Alternatively, you can set up retries for a short time only, or use something like this:
*@your.dom.ain quota_7d *@your.dom.ain quota F,2h,15m; F,3d,1h
which bounces immediately if the user's mailbox hasn't been read for 7 days, but otherwise tries for up to 3 days after the first quota failure.
Q0606: I'm using tmail to do local deliveries, but when I turned on the use_crlf option on the pipe transport (tmail prefers \r\n terminations) message bodies started to vanish.
A0606: You need to unset the mesage_prefix option, or change it so that its default \n terminator becomes \r\n. For example, the transport could be:
local_delivery_mbx:
driver = pipe
command = /usr/local/bin/tmail $local_part
user = exim
current_directory = /
use_crlf
message_prefix =
The reason for this is as follows: tmail uses the line terminator on the first line it sees to determine whether lines are terminated by \r\n or \n. If the latter, it moans to stderr and changes subsequent \n terminators to \r\n. The default setting of the message_prefix option is From ...\n, and this is unaffected by the use_crlf option. If you don't change this, tmail sees the first line terminated by \n and prepends \r to the \n terminator on all subsequent lines. However, if use_crlf is set, Exim makes all other lines \r\n terminated, leading to doubled \r\r\n lines and corrupt mbx mailboxes.
Q0607: When I activate ``return receipt'' for example in Netscape Mailbox sending options, then I get an error message from Exim... something like not supported. Can I activate delivery confirmations?
A0607: Exim does not support any kind of delivery notification.
(1) You can configure it to recognize headers such as Return-receipt-to: if you wish.
(2) Some people want MSN (message status notification). Such services are implemented in MUAs, and don't impact on the MTA at all.
(3) I investigated the RFCs which describe the DSN (delivery status notification) system. However, I was unable to specify any sensible way of actually doing anything with the data. There were comments on the mailing list at the time; many people, including me, conclude that DSN is in practice unworkable. The killer problem is with forwarding and aliasing. Do you propagate the DSN data with the generated addresses? Do you send back a ``reached end of the DSN world'' or ``expanded'' message? Do you do this differently for different kinds of aliasing/forwarding? For a user who has a .forward file with a single address in, this might seem easy - just propagate the data. But what if there are several forwardings? If you propagate the DSN data, the sender may get back several DSN messages - and should the sender really know about the detail of the receiver's forwarding arrangements? There isn't really any way to distinguish between a .forward file that is forwarding and one that is a mini mailing list. And so on, and so on. There are so many questions that don't have obvious answers.
Q0608: What does the message retry time not reached [for any host] on the log mean? Why won't Exim try to deliver the message?
A0608: That is not an error. It means exactly what it says. A previous attempt to deliver to that address failed with a temporary error, and Exim computed the earliest time at which to try again. This can apply to local as well as to remote deliveries. For remote deliveries, each host (if there are several) has its own retry time.
If you are running on a dial-up host, the rest of this answer probably does not apply to you. Go and read Q1404 instead. If your host is permanently online, read on...
Some MTAs have a retrying schedule for each message. Exim does not work like this. Retry timing is normally host-based for remote deliveries and address-based for local deliveries. (There are some exceptions for certain kinds of remote failure - see Errors in outgoing SMTP in the manual.)
If a new message arrives for a failing address and the retry time has not yet arrived, Exim will log retry time not reached and leave the message on the queue, without attempting delivery. Similarly, if a queue runner notices the message before the time to retry has arrived, it writes the same log entry. When the retry time has past, Exim attempts delivery at the next queue run. If you want to know when that will be, run the exinext utility on the address, for example:
exinext user@some.domain
You can suppress these messages on the log by including -retry_defer in the setting of log_selector. You can force a delivery attempt on a specific message (overriding the retry time) by means of the -M option:
exim -M 10hCET-0000Bf-00
If you want to do this for the entire queue, use the -qf option.
Q0609: Exim seems to be sending the same message twice, according to the log, although there is a difference in capitalization of the local part of the address.
A0609: That is correct. The RFCs are explicit in stating that capitalization matters for local parts. For remote domains, Exim is not entitled to assume case independence of local parts. I know, it is utterly silly, and it causes a lot of grief, but that's what the rules say. Here is a quote from RFC 2821:
... a command verb, an argument value other than a mailbox local-part, and free form text MAY be encoded in upper case, lower case, or any mixture of upper and lower case with no impact on its meaning. This is NOT true of a mailbox local-part. The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. Mailbox domains are not case sensitive. In particular, for some hosts the user "smith" is different from the user "Smith". However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.
Q0610: How can I force the next retry time for a host to be now?
A0610: You can change the retry time with the exim_fixdb utility, but its interface is very clumsy. If you have a message for the host on the queue, the simplest thing to do is to force a delivery with the -M command line option. If delivery succeeds, the retry data will get cleared. If the host is past the cutoff time, so that messages are bouncing immediately without trying a delivery, you can use -odq to put a message on the queue without a delivery attempt, and then use -M on it.
Q0611: I set up |/bin/grep Subject|/usr/bin/smbclient -M <netbiosname> as an alias but it doesn't work.
A0611: That is a shell command line. Exim does not run pipe commands under a shell by default (for added security - and it saves a process). You need something like
"|/bin/sh -c '/bin/grep Subject|/usr/bin/smbclient -M <netbiosname>'"
Q0612: Why does the pipe transport add a line starting with >From to messages?
A0612: Actually, it adds a line starting with From, because that is the default of the message_prefix option (/usr/ucb/vacation needs it, and that is the most common use of piping). If you don't want it, change the setting of message_prefix.
Q0613: I have set fallback_hosts on my smtp transport, but after the error sem@chat.ru cannot be resolved at this time Exim isn't using them.
A0613: fallback_hosts works only if an attempt at delivery to the original host(s) fails. In this case, Exim couldn't even resolve the domain chat.ru to discover what the original hosts were, so it never got as far as the transport. However, see Q0315 for a possible solution.
Q0614: After the holidays my ISP has always hundreds of e-mails waiting for me. These are forced down Exim's throat in one go. Exim spawns a lot of kids, but is there some limit to the number of processes it creates?
A0614: Unless you have changed smtp_accept_queue_per_connection it should spawn only that many processes per connection (default 10). Your ISP may be making many connections, of course. That is limited by smtp_accept_max.
Q0615: When a message in the queue got to 12h old, Exim wrote retry timeout exceeded and removed all messages in the queue to this host - even recent messages. How I can avoid this behaviour? I only want to remove messages that have exceeded the maximum retry time.
A0615: Exim's retrying is host-based rather than message-based. The philosophy is that if a host has been down for a very long time, there is no point in keeping messages hanging around. However, you might like to check out delay_after_cutoff in the smtp transport. It doesn't do what you want, but it might help.
Q0616: Can Exim add a Content-Length: header to messages it delivers?
A0616: You could include something like
headers_remove = "content-length" headers_add = "Content-Length: $message_body_size"
to the appendfile transport. However, the use of Content-Length: can cause several problems, and is not recommended unless you really know what you are doing. There is a discussion of the problems in http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/content-length.html.
Q0617: Exim seems to be trying to deliver a message every 10 minutes, though the retry rules specify longer times after a while, because it is writing a log entry every time, like this:
1999-08-26 14:51:19 11IVsE-000MuP-00 == example@example.com T=smtp defer (-34): some host address lookups failed and retry time not reached for other hosts or connection limit reached
A0617: It is looking at the message every 10 minutes, but it isn't actually trying to deliver. It's looking up example.com in the DNS and finding this information:
example.com. MX 10 example-com.isp.example.com. example.com. MX 0 mail.example.com. mail.example.com. A 202.77.183.45 A lookup for example-com.isp.example.com. yielded NXDOMAIN
The last line means that there is no address (A) record in the DNS for example-com.isp.example.com. That accounts for some host address lookups failed, but the retry time for mail.example.com hasn't been reached, which accounts for retry time not reached for other hosts.
Q0618: I am trying to set exim up to have a automatic failover if it sees that the system that it is sending all mail to is down.
A0618: Add to the remote_smtp transport the following:
fallback_hosts = failover.server.name(s)
If there are several names, they must be separated by colons.
Q0619: I can't get Exim to deliver over NFS. I get the error fcntl() failed: No locks available, though the lock daemon is running on the NFS server and other hosts are able to access it.
A0619: Check that you have lockd running on the NFS client. This is not always running by default on some systems (Red Hat is believed to be one such system).
Q0620: Why does Exim bounce messages without even attempting delivery, giving the error retry time not reached for any host after a long failure period?
A0620: This message means that all hosts to which the message could be sent have been failing for so long that the end of the retry period (typically 4 or 5 days) has been reached. In this situation, Exim still computes a next time to retry, but any messages that arrive in the meantime are bounced straight away. You can alter this behaviour by unsetting the delay_after_cutoff option on the smtp transport. Then Exim will try most messages for those hosts once before giving up.
Q0621: My .forward file is |/usr/bin/procmail -f- and mail gets delivered, but there was a bounce to the sender, sending him the output of procmail. How can I prevent this?
A0621: Exim's default configuration is set up like this:
address_pipe:
driver = pipe
return_output
The return_output option requests that any output that the pipe produces be returned to the sender. That is the safest default. If you don't want this, you can either remove the option altogether, or change it to return_fail_output, to return output only if the command fails. Note that this will affect all pipes that users run, not just your procmail one. It might be better to arrange for procmail not to produce any output when it succeeds.
Q0622: Can I write an ordinary file when I run a perl script as a transport filter for the remote_smtp and address_pipe transports?
A0622: Yes, provided the file is writeable by the uid under which the transport runs (the Exim user in the case of the remote transport). However, if two messages are being delivered at once, their data will get mixed up in the file unless you implement your own locking scheme. If all you want to do is to take a copy of the message, another approach that avoids the locking problem is to use a system filter to set up an ``unseen'' delivery to a file. If you only want the message's headers, you can set message_filter_file_transport to point to a special appendfile transport that has headers_only set.
Q0623: My /var/spool/mail has grown drastically. Is there any possibility of using two directories?
A0623: You can use an expansion string to split mailboxes between two directories. For example,
file = /var/spool/mail${nhash_2:$local_part}/$local_part
which does a hash on the local part, producing either 0 or 1, thereby using \(mail0) or mail1. But remember, the MUAs that read these mailboxes also have to know where they are.
Q0624: Sendmail has a program called smrsh that restricts what binaries can be run from sendmail aliases. Is there something like this in Exim ?
A0624: Check out the allow_commands option in the pipe transport.
Q0625: I wish to have large emails go out one at a time.
A0625: One possibility is to set up a router that defers all large messages, except in queue runs. Since queue runners deliver just one message at a time, if you limited the number of simultaneous queue runners to 1, you would get the effect you wanted. A suitable router might be
defer_if_large_unless_queue_run:
driver = redirect
condition = ${if or{{queue_running}{<{$message_size}{200K}}}{no}{yes}}
allow_defer
data = :defer: too large for immediate delivery
no_verify
Of course, this would always delay any large message until the next queue runner, but if you run them fairly regularly, this shouldn't be a huge problem, and may even be desirable. Note the use of no_verify to ensure that this router is not used when Exim is verifying addresses.
Q0626: Exim can route local parts independent of their case, but the Cyrus LMTP daemon requires the correct case. How can I fix this?
A0626: You need to rewrite the local part to the correct case before running the router that routes to Cyrus. For example, if you require all lower case, and your router is called local_user, put this router in front of it:
lowercase_local:
driver = redirect
redirect_router = local_user
domains = +local_domains
data = ${lc:$local_part}@$domain
The setting of redirect_router causes processing of the rewritten address to start at the next router, instead of the first router. See C045 for a more complete Cyrus configuration.
Q0627: Is there a command I can send to Exim to retry all queued messages regardless of their retry schedule?
A0627: The -qff option starts a queue runner that forces a delivery attempt for all messages, including frozen ones. If you use -qf, frozen messages are skipped.
Q0628: I have the default retry rule, which I thought meant that Exim should keep trying for four days, but it seems to be bouncing some messages immediately.