|
0
|
1
|
|
|
2
|
|
|
3
|
|
|
4
|
|
|
5
|
|
|
6
|
|
|
7 Network Working Group M. Crispin
|
|
|
8 Request for Comments: 1733 University of Washington
|
|
|
9 Category: Informational December 1994
|
|
|
10
|
|
|
11
|
|
|
12 DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4
|
|
|
13
|
|
|
14
|
|
|
15 Status of this Memo
|
|
|
16
|
|
|
17 This memo provides information for the Internet community. This memo
|
|
|
18 does not specify an Internet standard of any kind. Distribution of
|
|
|
19 this memo is unlimited.
|
|
|
20
|
|
|
21
|
|
|
22 Distributed Electronic Mail Models
|
|
|
23
|
|
|
24 There are three fundamental models of client/server email: offline,
|
|
|
25 online, and disconnected use. IMAP4 can be used in any one of these
|
|
|
26 three models.
|
|
|
27
|
|
|
28 The offline model is the most familiar form of client/server email
|
|
|
29 today, and is used by protocols such as POP-3 (RFC 1225) and UUCP.
|
|
|
30 In this model, a client application periodically connects to a
|
|
|
31 server. It downloads all the pending messages to the client machine
|
|
|
32 and deletes these from the server. Thereafter, all mail processing
|
|
|
33 is local to the client. This model is store-and-forward; it moves
|
|
|
34 mail on demand from an intermediate server (maildrop) to a single
|
|
|
35 destination machine.
|
|
|
36
|
|
|
37 The online model is most commonly used with remote filesystem
|
|
|
38 protocols such as NFS. In this model, a client application
|
|
|
39 manipulates mailbox data on a server machine. A connection to the
|
|
|
40 server is maintained throughout the session. No mailbox data are
|
|
|
41 kept on the client; the client retrieves data from the server as is
|
|
|
42 needed. IMAP4 introduces a form of the online model that requires
|
|
|
43 considerably less network bandwidth than a remote filesystem
|
|
|
44 protocol, and provides the opportunity for using the server for CPU
|
|
|
45 or I/O intensive functions such as parsing and searching.
|
|
|
46
|
|
|
47 The disconnected use model is a hybrid of the offline and online
|
|
|
48 models, and is used by protocols such as PCMAIL (RFC 1056). In this
|
|
|
49 model, a client user downloads some set of messages from the server,
|
|
|
50 manipulates them offline, then at some later time uploads the
|
|
|
51 changes. The server remains the authoritative repository of the
|
|
|
52 messages. The problems of synchronization (particularly when
|
|
|
53 multiple clients are involved) are handled through the means of
|
|
|
54 unique identifiers for each message.
|
|
|
55
|
|
|
56
|
|
|
57
|
|
|
58 Crispin [Page 1]
|
|
|
59
|
|
|
60 RFC 1733 IMAP4 - Model December 1994
|
|
|
61
|
|
|
62
|
|
|
63 Each of these models have their own strengths and weaknesses:
|
|
|
64
|
|
|
65 Feature Offline Online Disc
|
|
|
66 ------- ------- ------ ----
|
|
|
67 Can use multiple clients NO YES YES
|
|
|
68 Minimum use of server connect time YES NO YES
|
|
|
69 Minimum use of server resources YES NO NO
|
|
|
70 Minimum use of client disk resources NO YES NO
|
|
|
71 Multiple remote mailboxes NO YES YES
|
|
|
72 Fast startup NO YES NO
|
|
|
73 Mail processing when not online YES NO YES
|
|
|
74
|
|
|
75 Although IMAP4 has its origins as a protocol designed to accommodate
|
|
|
76 the online model, it can support the other two models as well. This
|
|
|
77 makes possible the creation of clients that can be used in any of the
|
|
|
78 three models. For example, a user may wish to switch between the
|
|
|
79 online and disconnected models on a regular basis (e.g. owing to
|
|
|
80 travel).
|
|
|
81
|
|
|
82 IMAP4 is designed to transmit message data on demand, and to provide
|
|
|
83 the facilities necessary for a client to decide what data it needs at
|
|
|
84 any particular time. There is generally no need to do a wholesale
|
|
|
85 transfer of an entire mailbox or even of the complete text of a
|
|
|
86 message. This makes a difference in situations where the mailbox is
|
|
|
87 large, or when the link to the server is slow.
|
|
|
88
|
|
|
89 More specifically, IMAP4 supports server-based RFC 822 and MIME
|
|
|
90 processing. With this information, it is possible for a client to
|
|
|
91 determine in advance whether it wishes to retrieve a particular
|
|
|
92 message or part of a message. For example, a user connected to an
|
|
|
93 IMAP4 server via a dialup link can determine that a message has a
|
|
|
94 2000 byte text segment and a 40 megabyte video segment, and elect to
|
|
|
95 fetch only the text segment.
|
|
|
96
|
|
|
97 In IMAP4, the client/server relationship lasts only for the duration
|
|
|
98 of the TCP connection. There is no registration of clients. Except
|
|
|
99 for any unique identifiers used in disconnected use operation, the
|
|
|
100 client initially has no knowledge of mailbox state and learns it from
|
|
|
101 the IMAP4 server when a mailbox is selected. This initial transfer
|
|
|
102 is minimal; the client requests additional state data as it needs.
|
|
|
103
|
|
|
104 As noted above, the choice for the location of mailbox data depends
|
|
|
105 upon the model chosen. The location of message state (e.g. whether
|
|
|
106 or not a message has been read or answered) is also determined by the
|
|
|
107 model, and is not necessarily the same as the location of the mailbox
|
|
|
108 data. For example, in the online model message state can be co-
|
|
|
109 located with mailbox data; it can also be located elsewhere (on the
|
|
|
110 client or on a third agent) using unique identifiers to achieve
|
|
|
111
|
|
|
112
|
|
|
113
|
|
|
114 Crispin [Page 2]
|
|
|
115
|
|
|
116 RFC 1733 IMAP4 - Model December 1994
|
|
|
117
|
|
|
118
|
|
|
119 common reference across sessions. The latter is particularly useful
|
|
|
120 with a server that exports public data such as netnews and does not
|
|
|
121 maintain per-user state.
|
|
|
122
|
|
|
123 The IMAP4 protocol provides the generality to implement these
|
|
|
124 different models. This is done by means of server and (especially)
|
|
|
125 client configuration, and not by requiring changes to the protocol or
|
|
|
126 the implementation of the protocol.
|
|
|
127
|
|
|
128
|
|
|
129 Security Considerations
|
|
|
130
|
|
|
131 Security issues are not discussed in this memo.
|
|
|
132
|
|
|
133
|
|
|
134 Author's Address:
|
|
|
135
|
|
|
136 Mark R. Crispin
|
|
|
137 Networks and Distributed Computing, JE-30
|
|
|
138 University of Washington
|
|
|
139 Seattle, WA 98195
|
|
|
140
|
|
|
141 Phone: (206) 543-5762
|
|
|
142
|
|
|
143 EMail: MRC@CAC.Washington.EDU
|
|
|
144
|
|
|
145
|
|
|
146
|
|
|
147
|
|
|
148
|
|
|
149
|
|
|
150
|
|
|
151
|
|
|
152
|
|
|
153
|
|
|
154
|
|
|
155
|
|
|
156
|
|
|
157
|
|
|
158
|
|
|
159
|
|
|
160
|
|
|
161
|
|
|
162
|
|
|
163
|
|
|
164
|
|
|
165
|
|
|
166
|
|
|
167
|
|
|
168
|
|
|
169
|
|
|
170 Crispin [Page 3]
|
|
|
171
|
