1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
|
<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.52
from spec on 25 November 2000 -->
<TITLE>Exim Specification - 44. Intermittently connected hosts</TITLE>
</HEAD>
<body bgcolor="#FFFFFF" text="#00005A" link="#FF6600" alink="#FF9933" vlink="#990000">
Go to the <A HREF="spec_1.html">first</A>, <A HREF="spec_43.html">previous</A>, <A HREF="spec_45.html">next</A>, <A HREF="spec_59.html">last</A> section, <A HREF="spec_toc.html">table of contents</A>.
<P><HR><P>
<H1><A NAME="SEC798" HREF="spec_toc.html#TOC798">44. Intermittently connected hosts</A></H1>
<P>
<A NAME="IDX1729"></A>
<A NAME="IDX1730"></A>
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.
</P>
<P>
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.
</P>
<P>
<H2><A NAME="SEC799" HREF="spec_toc.html#TOC799">44.1 Exim on the upstream host</A></H2>
<P>
If the `holding system' is running Exim, it should be configured with a
long retry period for the intermittent host. For example:
<PRE>
cheshire.wonderland.fict.book * F,5d,24h
</PRE>
<P>
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 -<EM>M</EM> or -<EM>R</EM>
options, or by using the ETRN SMTP command -- see <EM>smtp_etrn_hosts</EM> and
section 48.6) 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.
</P>
<P>
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, 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 <EM>retry_include_ip_address</EM> on the <EM>smtp</EM> transport.
Since this has disadvantages for permanently connected hosts, it is best to
arrange a separate transport for the intermittently connected ones.
</P>
<H2><A NAME="SEC800" HREF="spec_toc.html#TOC800">44.2 Exim on the intermittently connected host</A></H2>
<P>
The value of
<EM>smtp_accept_queue_per_connection</EM>
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.
</P>
<P>
<A NAME="IDX1731"></A>
<A NAME="IDX1732"></A>
<A NAME="IDX1733"></A>
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 -<EM>qq</EM> instead
of -<EM>q</EM>. 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.
</P>
<H2><A NAME="SEC801" HREF="spec_toc.html#TOC801">44.3 Handling many intermittently connected hosts</A></H2>
<P>
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.
</P>
<P>
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.
</P>
<P><HR><P>
Go to the <A HREF="spec_1.html">first</A>, <A HREF="spec_43.html">previous</A>, <A HREF="spec_45.html">next</A>, <A HREF="spec_59.html">last</A> section, <A HREF="spec_toc.html">table of contents</A>.
</BODY>
</HTML>
|
