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 a `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.
The value of `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.
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.
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 in a single SMTP connection.
Go to the first, previous, next, last section, table of contents.