It is becoming quite common (because it is cheaper) for hosts to connect to the Internet periodically rather than remain connected all the time. The normal arrangement is that mail for such hosts accumulates on a system that is permanently connected.
Exim was designed for use on permanently connected hosts, and so it is not particularly well-suited to use in an intermittently connected environment. Nevertheless there are some features that can be used.
If the `holding system' is running Exim, then it should be configured with a long retry period for the intermittent host. For example:
cheshire.wonderland.fict.book * F,5d,24h
This stops a lot of failed delivery attempts from occurring, but Exim remembers which messages it has queued up for that host. Once the intermittent host comes online, forcing delivery of one message (either by using the `-M' or `-R' options, or by using the ETRN SMTP command -- see `smtp_etrn_hosts' and section "The ETRN command" in chapter "SMTP processing") causes all the queued up messages to be delivered, often down a single SMTP connection. While the host remains connected, any new messages get delivered immediately.
If the connecting hosts do not have fixed IP addresses, that is, if a host is issued with a different IP address each time it connects, then Exim's retry mechanisms on the holding host get confused, because the IP address is normally used as part of the key string for holding retry information. This can be avoided by unsetting `retry_include_ip_address' on the `smtp' transport. Since this has disadvantages for permanently connected hosts, it is best to arrange a separate transport for the intermittently connected ones.
The value of `smtp_accept_queue_per_connection' should probably be increased, or even set to zero (that is, disabled) on the intermittently connected host, so that all incoming messages down a single connection get delivered immediately.
Mail waiting to be sent from an intermittently connected host will probably not have been routed, since without a connection DNS lookups are not possible. This means that if a normal queue run is done at connection time, each message is likely to be sent in a separate SMTP session. This can be avoided by starting the queue run with a command line option beginning with `-qq' instead of `-q'. In this case, the queue is scanned twice. In the first pass, routing is done but no deliveries take place. The second pass is a normal queue run; since all the messages have been previously routed, those destined for the same host are likely to get sent as multiple deliveries in a single SMTP connection.
Leaving mail for intermittently connected hosts on the main queue of a holding system as suggested above does not scale very well. Two different kinds of waiting message are being mixed up in the same queue -- those that cannot be delivered because of some temporary problem, and those that are waiting for their destination host to connect. This makes it hard to manage the queue, as well as wasting resources, because each queue runner scans the entire queue.
A better approach is to separate off those messages that are waiting for an intermittently connected host. This can be done by using a separate version of Exim that stores only those messages, or by delivering such messages into local files in batch SMTP, `mailstore', or other envelope-preserving format, from where they are transmitted by other software when their destination connects. This makes it easy to collect all the mail for one host in a single directory, and to apply local timeout rules on a per-message basis if required.
Go to the first, previous, next, last section, table of contents.