The Exim FAQ

Contents   Previous   Next

14. DIAL-UP AND ISDN

Q1401:  When I'm not connected to the Internet, how can I arrange for mail to other hosts on my local network to be delivered, while at the same time mail to Internet hosts is queued without any delivery attempts?

A1401:  Use the queue_domains option to control which domains are held on the queue for later delivery. For example,

   queue_domains = ! *.localnet

allows delivery to domains ending in .localnet, while queueing all the others.

Q1402:  I have a dial-up machine, and I use the queue_smtp_domains option so that remote mail only goes out when I do a queue run. However, any email I send with an address anything@aol.com is returned within about 15 minutes saying retry time exceeded, and all addresses are affected.

A1402:  You should be using queue_domains rather than queue_smtp_domains. With the latter, Exim is trying to route the addresses, which involves a DNS lookup. This is presumably timing out, causing a retry time to be set for the domain, and somehow a valid lookup never happened before the maximum retry time (default of 4 days) passed. Hence the bounce. The fact that it is aol.com is probably not relevant. You should probably also be using -qq to do your queue run rather than -q.

Q1403:  How should Exim be configured when it is acting as a temporary storage system for a domain on a dial-up host?

A1403:  Exim isn't really designed for this, but... The lowest-numbered MX record for the domain should be pointing to the dial-up host. A higher numbered MX record (lower priority) should point to the Exim server that is acting as a temporary storage system.

You should set a large retry time for the domain, so that Exim doesn't keep trying to deliver when the host is offline. When the host comes online, the waiting messages have to be kicked somehow. This can be done by calling Exim with the -R option, or via the SMTP ETRN command.

This works provided the number of messages is low. If you are handling lots of mail, keeping messages waiting for their host to connect and those that are having delivery problems to remote hosts all in the same queue doesn't work so well. It is better in this case to get Exim to deliver the mail for the dial-in hosts into some local files which then get transmitted by other software when the host connects. One tool for doing this can be found at http://cr.yp.to/serialmail.html.

For further discussion, see section entitled Intermittently connected hosts in the manual, and also the section in the Exim book with the same name.

Q1404:  I have queue_domains or queue_smtp_domains set, and use -qf to force delivery of waiting mail when I dial in. How can I arrange for any new messages that arrive while I'm connected to be delivered immediately?

A1404:  Instead of queue_domains or queue_smtp_domains, use the queue_only_file option. This causes messages to be queued if a particular file exists. If you put the word “smtp” before the file name, the queueing applies only to domains that are delivered by SMTP, thus not affecting local deliveries:

   queue_only_file = smtp/etc/present/when/not/connected

Then, in the scripts which are run when you connect and disconnect, arrange to remove the file after connection, and create it just before disconnection.

Q1405:  I have an ISDN connection and would like a way of running the queue automatically when it is up.

A1405:  The following shell commands test for the interface being up and then run the queue:

   ifconfig ppp0 | fgrep UP >/dev/null
   if [ $? -eq 0 ] ; then exim -q ; fi

You could put these commands into a script which runs them at regular intervals. You might want to use -qq instead of -q.

With Linux, the script /etc/ppp/ip-up is run after a ISDN connection or a more general PPP connection has been established. If you are using Linux, you could put the call to Exim in that script.

Q1406:  When I dial up to collect mail from my ISP, only the first 10 messages get delivered immediately; the remainder just sit on the queue until a queue runner process finds them.

A1406:  See Q0049.

Q1407:  RFC 1985 specifies that the SMTP command ETRN host.domain causes all mail queued for that host, no matter what domain it's for, to be delivered. Why doesn't Exim support this?

A1407:  Exim does not keep queues of mail for specific destinations. It just keeps one pool of undelivered messages. What is more, once you start a delivery of a message, it tries to deliver to all the addresses in the message, not just the one you may be interested in. (Of course, this doesn't usually do any harm.)

The only way it could be done within Exim would be, for every message on the queue, to go through the motions of routing each undelivered address and see if that resulted in a delivery to the host of interest. This could be extremely expensive (e.g. 1,000 messages on the queue, only 1 for the given host).

The bottom line is that Exim just wasn't designed for this kind of operation, that is, holding messages for intermittently connected hosts. The queueing arrangements are designed for handling delivery problems that are not expected to be common.

A better way to do this is to implement the required queues separately. After all, keeping such mail on an active queue (where Exim will keep trying to deliver) is silly. If there is a lot of mail for these hosts, it also masks genuine delivery problems when you inspect the queue.

Large ISPs who provide this kind of functionality do not usually leave waiting mail on the MTA's queue. Instead, they get it delivered into per-host directories, one message per file, in one of the special formats (BSMTP, maildir, or mailstore) and when an ETRN arrives, it kicks off some completely different program that establishes an SMTP connection to the host and shovels the waiting mail down it. That seems to me to be a much neater way of doing this. It means you can easily add additional functionality such as archiving or throwing away uncollected mail.

One program that has this functionality is ssmtp, which can be found in ftp://metalab.unc.edu/pub/Linux/system/mail/mta/. Alternatively, sample configuration C037 demonstrates an elegant way of using Exim itself to deliver the saved messages when the client issues an ETRN.

Q1408:  If email has been deferred to a member on a local mailing list (implemented through forward files), and one of our ETRN clients is on this mailing list, the -R won't flush the mailing list message for that client.

A1408:  That is because -R matches only original recipient addresses, not those produced as a result of expansion, because these are not (by default) preserved from delivery to delivery. You can get round this by setting one_time on the forwarding router, but you are not allowed to have expansions to pipes or files on routers that have one_time set. Therefore, you will have to have a separate router for mailing lists (with one_time set) to the one used for normal forward files that might specify pipe or file deliveries. However, the problem will still be present for any user who sets up a .forward file to redirect to any of the ETRN domains. See the last 3 paragraphs of Q1407 for a discussion of an alternative approach.

Q1409:  I would like to have a separate queue per domain for hosts which dial in to collect their mail.

A1409:  Exim isn't really designed for this kind of operation. The only way to do this would be to cause it to send those messages to a differently configured version of Exim with its own spool area. This could be done via a pipe or SMTP to a private port. The main Exim, listening on port 25, would then be configured to run an appropriate command to prod one of the others when it received ETRN, by means of the smtp_etrn_command option.

You could probably manage this with a single Exim binary and a number of different configuration files, passed to the special versions using the -C option. For this application they could all run as exim, since no root privilege would be needed.

An alternative approach id to get Exim to deliver mail for such hosts in batch SMTP format into some directory, and have the ETRN run something to pass such messages to the dialled-in host. See also Q1403.



Contents   Previous   Next