7Network Working Group R. Gellens
8Request for Comments: 5383 Qualcomm
10Category: Best Current Practice
13 Deployment Considerations for Lemonade-Compliant Mobile Email
17 This document specifies an Internet Best Current Practices for the
18 Internet Community, and requests discussion and suggestions for
19 improvements. Distribution of this memo is unlimited.
24 This document discusses deployment issues and describes requirements
25 for successful deployment of mobile email that are implicit in the
26 IETF lemonade documents.
30 1. Introduction ....................................................2
31 2. Conventions Used in This Document ...............................2
32 3. Ports ...........................................................2
33 4. TCP Connections .................................................3
34 4.1. Lifetime ...................................................4
35 4.2. Maintenance during Temporary Transport Loss ................5
36 5. Dormancy ........................................................6
37 6. Firewalls .......................................................6
38 6.1. Firewall Traversal .........................................7
39 7. NATs ............................................................8
40 8. Security Considerations .........................................8
41 9. Acknowledgments ................................................10
42 10. Normative References ..........................................10
43 11. Informative References ........................................10
58Gellens Best Current Practice [Page 1]
60RFC 5383 Lemonade Deployment Considerations October 2008
65 The IETF lemonade group has developed a set of extensions to IMAP and
66 Message Submission, along with a profile document that restricts
67 server behavior and describes client usage [PROFILE].
69 Successful deployment of lemonade-compliant mobile email requires
70 various functionality that is generally assumed and hence not often
71 covered in email RFCs. This document describes some of these
72 additional considerations, with a focus on those that have been
73 reported to be problematic.
752. Conventions Used in This Document
77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
79 document are to be interpreted as described in [KEYWORDS].
83 Both IMAP and Message Submission have been assigned well-known ports
84 [IANA] that MUST be available. IMAP uses port 143. Message
85 Submission uses port 587. It is REQUIRED that the client be able to
86 contact the server on these ports. Hence, the client and server
87 systems, as well as any intermediary systems, MUST allow
88 communication on these ports.
90 Historically, Message User Agents (MUAs) have used port 25 for
91 Message Submission, and [SUBMISSION] does accommodate this. However,
92 it has become increasingly common for ISPs and organizations to
93 restrict outbound port 25. Additionally, hotels and other public
94 accommodations sometimes intercept port 25 connections, regardless of
95 the destination host, resulting in users unexpectedly submitting
96 potentially sensitive communications to unknown and untrusted third-
97 party servers. Typically, users are not aware of such interception.
98 (Such interception violates [FIREWALLS] and has many negative
101 Due to endemic security vulnerabilities in widely deployed SMTP
102 servers, organizations often employ application-level firewalls that
103 intercept SMTP and permit only a limited subset of the protocol. New
104 extensions are therefore more difficult to deploy on port 25. Since
105 lemonade requires support for several [SUBMISSION] extensions, it is
106 extremely important that lemonade clients use, and lemonade servers
107 listen on, port 587 by default.
114Gellens Best Current Practice [Page 2]
116RFC 5383 Lemonade Deployment Considerations October 2008
119 In addition to communications between the client and server systems,
120 lemonade requires that the Message Submission server be able to
121 establish a TCP connection to the IMAP server (for forward-without-
122 download). This uses port 143 by default.
124 Messaging clients sometimes use protocols to store, retrieve, and
125 update configuration and preference data. Functionality such as
126 setting a new device to use the configuration and preference data of
127 another device, or having a device inherit default configuration data
128 from a user account, an organization, or other source, is likely to
129 be even more useful with small mobile devices. Various protocols can
130 be used for configuration and preference data; most of these
131 protocols have designated ports. It is important that clients be
132 able to contact such servers on the appropriate ports. As an
133 example, one protocol that can be used for this purpose is [ACAP], in
134 which case port 674 needs to be available.
136 Note that systems that do not support application use of [TCP] on
137 arbitrary ports are not full Internet clients. As a result, such
138 systems use gateways to the Internet that necessarily result in data
143 Both IMAP and Message Submission use [TCP]. Hence, the client system
144 MUST be able to establish and maintain TCP connections to these
145 servers. The Message Submission server MUST be able to initiate a
146 connection to the IMAP server. Support for application use of [TCP]
147 is REQUIRED of both client and server systems.
149 The requirements and advice in [HOST-REQUIREMENTS] SHOULD be
152 Note that, for environments that do not support application use of
153 [TCP] but do so for HTTP, email can be offered by deploying webmail.
154 Webmail is a common term for email over the web, where a server
155 speaks HTTP to the client and an email protocol (often IMAP) to the
156 mail store. Its functionality is necessarily limited by the
157 capabilities of the web client, the webmail server, the protocols
158 used between the webmail server and the client (HTTP and a markup
159 language such as HTML), and between the webmail server and the mail
160 store. However, if HTTP is all that is available to an application,
161 the environment is by definition limited and thus, functionality
162 offered to the user must also be limited, and can't be lemonade
170Gellens Best Current Practice [Page 3]
172RFC 5383 Lemonade Deployment Considerations October 2008
177 In this document, "idle" refers to the idle time, as in the
178 "established connection idle-timeout" of [BEHAVE-TCP], while
179 "duration" refers to the total time that a TCP connection has been
182 The duration of the TCP connections between the client and server
183 systems for both IMAP and Message Submission can be arbitrarily long.
184 The client system, the server, as well as all intermediate systems
185 MUST NOT terminate these TCP connections simply because of their
186 duration (that is, just because of how long they have been open).
188 Lemonade depends on idle timers being enforced only at the
189 application level (IMAP and Message Submission): if no data is
190 received within a period of time, either side MAY terminate the
191 connection as permitted by the protocol (see [SUBMISSION] or [IMAP]).
192 Since IMAP permits unsolicited notifications of state changes, it is
193 reasonable for clients to remain connected for extended periods with
194 no data being exchanged. Being forced to send data just to keep the
195 connection alive can prevent or hinder optimizations such as dormancy
196 mode (see Section 5).
198 Two hours is a fairly common configuration timeout at middleboxes.
199 That is, there are a number of sites at which TCP connections are
200 torn down by the network two hours after data was last sent in either
201 direction (for example, REQ-5 in [BEHAVE-TCP]). Thus, lemonade
202 clients and servers SHOULD make sure that, in the absence of a
203 specific configuration setting that specifies a longer maximum idle
204 interval, the TCP connection does not remain idle for two hours.
205 This rule ensures that, by default, lemonade clients and servers
206 operate in environments configured with a two-hour maximum for idle
207 TCP connections. Network and server operators can still permit IMAP
208 connections to remain idle in excess of two hours and thus increase
209 the benefits of dormancy, by configuring lemonade clients and
210 servers, and network equipment, to allow this.
212 It has been reported that some networks impose duration time
213 restrictions of their own on TCP connections other than HTTP. Such
214 behavior is harmful to email and all other TCP-based protocols. It
215 is unclear how widespread such reported behavior is, or if it is an
216 accidental consequence of an attempt at optimizing for HTTP traffic,
217 implementation limitations in firewalls, NATs, or other devices, or a
218 deliberate choice. In any case, such a barrier to TCP connections is
219 a significant risk to the increasing usage of IETF protocols on such
220 networks. Note that TCP is designed to be more efficient when it is
226Gellens Best Current Practice [Page 4]
228RFC 5383 Lemonade Deployment Considerations October 2008
231 used to transfer data over time. Prohibiting such connections thus
232 imposes hidden costs on an operator's network, forcing clients to use
233 TCP in inefficient ways. One way in which carriers can inadvertently
234 force TCP connections closed, resulting in users wasting packets by
235 reopening them, is described in Section 7.
237 Note that systems remain able to terminate TCP connections at any
238 time based on local decisions, for example, to prevent overload
239 during a denial-of-service attack. These mechanisms are permitted to
240 take idle time into consideration and are not affected by these
2434.2. Maintenance during Temporary Transport Loss
245 TCP is designed to withstand temporary loss of lower-level
246 connectivity. Such transient loss is not uncommon in mobile systems
247 (for example, due to handoffs, fade, etc.). The TCP connection
248 SHOULD be able to survive temporary lower-level loss when the IP
249 address of the client does not change (for example, short-duration
250 loss of the mobile device's traffic channel or periods of high packet
251 loss). Thus, the TCP/IP stack on the client, the server, and all
252 intermediate systems SHOULD maintain the TCP connection during
253 transient loss of connectivity.
255 In general, applications can choose whether or not to enable TCP
256 keep-alives, but in many cases are unable to affect any other aspect
257 of TCP keep-alive operation, such as time between keep-alive packets,
258 number of packets sent before the connection is aborted, etc. In
259 some environments, these are operating system tuning parameters not
260 under application control. In some cases, operational difficulties
261 have been reported with application use of the TCP keep-alive option,
262 which might be the result of TCP implementation differences or
263 defects specific to a platform. Lemonade client and server systems
264 SHOULD NOT set the TCP keep-alive socket option unless operating in
265 environments where this works correctly and such packets will not be
266 sent more frequently than every two hours. Application-level keep-
267 alives (such as IMAP NOOP) MAY be used instead of the TCP keep-alive
270 Client, server, and intermediate systems MUST comply with the
271 "Destination Unreachable -- codes 0, 1, 5" text in Section 4.2.3.9 of
272 [HOST-REQUIREMENTS], which states "Since these Unreachable messages
273 indicate soft error conditions, TCP MUST NOT abort the connection".
282Gellens Best Current Practice [Page 5]
284RFC 5383 Lemonade Deployment Considerations October 2008
289 Cellular data channels are connection-oriented (they are brought up
290 or down to establish or tear down connections); it costs network
291 resources to establish connections. Generally speaking, mobile
292 device battery charges last longer when the traffic channel is used
295 Some mobile devices and networks support dormant mode, in which the
296 traffic channel is brought down during idle periods, yet the PPP or
297 equivalent level remains active, and the mobile retains its IP
300 Maintenance of TCP connections during dormancy SHOULD be supported by
301 the client, server, and any intermediate systems, as described in
302 Sections 4.1 and 4.2.
304 Sending packets just to keep the session active causes unnecessary
305 channel establishment and timeout; with a long-idle TCP connection,
306 this would periodically bring up the channel and then let it idle
307 until it times out, again and again. However, in the absence of
308 specific configuration information to the contrary, it is necessary
309 to do this to ensure correct operation by default.
313 New services must necessarily have their traffic pass through
314 firewalls in order to be usable by corporate employees or
315 organization members connecting externally, such as when using mobile
316 devices. Firewalls exist to block traffic, yet exceptions must be
317 made for services to be used. There is a body of best practices
318 based on long experience in this area. Numerous techniques exist to
319 help organizations balance protecting themselves and providing
320 services to their members, employees, and/or customers. (Describing,
321 or even enumerating, such techniques and practices is beyond the
322 scope of this document, but Section 8 does mention some.)
324 It is critical that protocol design and architecture permit such
325 practices, and not constrain them. One key way in which the design
326 of a new service can aid its secure deployment is to maintain the
327 one-to-one association of services and port numbers.
338Gellens Best Current Practice [Page 6]
340RFC 5383 Lemonade Deployment Considerations October 2008
343 One or more firewalls might exist in the path between the client and
344 server systems, as well as between the Message Submission and IMAP
345 servers. Proper deployment REQUIRES that TCP connections be possible
346 from the client system to the IMAP and Message Submission ports on
347 the servers, as well as from the Message Submission server to the
348 IMAP server. This may require configuring firewalls to permit such
351 Firewalls deployed in the network path MUST NOT damage protocol
352 traffic. In particular, both Message Submission and IMAP connections
353 from the client MUST be permitted. Firewalls MUST NOT partially
354 block extensions to these protocols, such as by allowing one side of
355 an extension negotiation, as doing so results in the two sides being
356 out of synch, with later failures. See [FIREWALLS] for more
359 Application proxies, which are not uncommon mechanisms, are discussed
3626.1. Firewall Traversal
364 An often-heard complaint from those attempting to deploy new services
365 within an organization is that the group responsible for maintaining
366 the firewall is unable or unwilling to open the required ports. The
367 group that owns the firewall, being charged with organizational
368 network security, is often reluctant to open firewall ports without
369 an understanding of the benefits and the security implications of the
372 The group wishing to deploy a new service is often tempted to bypass
373 the procedure and internal politics necessary to open the firewall
374 ports. A tempting kludge is to tunnel the new service over an
375 existing service that is already permitted to pass through the
376 firewall, typically HTTP on port 80 or sometimes SMTP on port 25.
377 Some of the downsides to this are discussed in [KLUDGE].
379 Such a bypass can appear to be immediately successful, since the new
380 service seems to deploy. However, assuming the network security
381 group is competent, when they become aware of the kludge, their
382 response is generally to block the violation of organizational
383 security policy. It is difficult to design an application-level
384 proxy/firewall that can provide such access control without violating
385 the transparency requirements of firewalls, as described in
386 [FIREWALLS]. Collateral damage is common in these circumstances.
387 The new service (which initially appeared to have been successfully
388 deployed) as well as those existing services that were leveraged to
389 tunnel the new service, become subject to arbitrary and unpredictable
394Gellens Best Current Practice [Page 7]
396RFC 5383 Lemonade Deployment Considerations October 2008
399 failures. This encourages an adversarial relationship between the
400 two groups, which hinders attempts at resolution.
402 Even more serious is what happens if a vulnerability is discovered in
403 the new service. Until the vulnerability is corrected, the network
404 security group must disable both the new service and the (typically
405 mission-critical) existing service on which it is layered.
407 An often-repeated truism is that any computer that is connected to a
408 network is insecure. Security and usefulness are both
409 considerations, with organizations making choices about achieving
410 acceptable measures in both areas. Deploying new services typically
411 requires deciding to permit access to the ports used by the service,
412 with appropriate protections. While the delay necessary to review
413 the implications of a new service may be frustrating, in the long
414 run, it is likely to be less expensive than a kludge.
418 Any NAT boxes that are deployed between client and server systems
419 MUST comply with REQ-5 in [BEHAVE-TCP], which requires that "the
420 value of the 'established connection idle-timeout' MUST NOT be less
421 than 2 hours 4 minutes".
423 See Section 5 for additional information on connection lifetimes.
425 Note that IMAP and Message Submission clients will automatically re-
426 open TCP connections as needed, but it saves time, packets, and
427 processing to avoid the need to do so. Re-opening IMAP and Message
428 Submission connections generally incurs costs for authentication,
429 Transport Layer Security (TLS) negotiation, and server processing, as
430 well as resetting of TCP behavior, such as windows. It is also
431 wasteful to force clients to send NOOP commands just to maintain NAT
432 state, especially since this can defeat dormancy mode.
4348. Security Considerations
436 There are numerous security considerations whenever an organization
437 chooses to make any of its services available via the Internet. This
438 includes email from mobile clients.
440 Sites concerned about email security should perform a threat
441 analysis, get relevant protections in place, and then make a
442 conscious decision to open up this service. As discussed in Section
443 6.1, piggybacking email traffic on the HTTP port in an attempt to
444 avoid making a firewall configuration change to explicitly permit
445 mobile email connections would bypass this important step and reduce
446 the overall security of the system.
450Gellens Best Current Practice [Page 8]
452RFC 5383 Lemonade Deployment Considerations October 2008
455 Organizations deploying a messaging server "on the edge" (that is,
456 accessible from the open Internet) are encouraged to choose one that
457 has been designed to operate in that environment.
459 This document does not attempt to catalogue either the various risks
460 an organization might face or the numerous techniques that can be
461 used to protect against the risks. However, to help illustrate the
462 deployment considerations, a very small sample of some of the risks
463 and countermeasures appear below.
465 Some organizations are concerned that permitting direct access to
466 their mail servers via the Internet increases their vulnerability,
467 since a successful exploit against a mail server can potentially
468 expose all mail and authentication credentials stored on that server,
469 and can serve as an injection point for spam. In addition, there are
470 concerns over eavesdropping or modification of mail data and
471 authentication credentials.
473 A large number of approaches exist that can mitigate the risks while
474 allowing access to mail services via mobile clients.
476 Placing servers inside one or more DMZs (demilitarized zones, also
477 called perimeter networks) can protect the rest of the network from a
478 compromised server. An additional way to reduce the risk is to store
479 authentication credentials on a system that is not accessible from
480 the Internet and that the servers within the DMZ can access only by
481 sending the credentials as received from the client and receiving an
482 authorized/not authorized response. Such isolation reduces the
483 ability of a compromised server to serve as a base for attacking
486 Many additional techniques for further isolation exist, such as
487 having the DMZ IMAP server have no mail store of its own. When a
488 client connects to such a server, the DMZ IMAP server might contact
489 the authentication server and receive a ticket, which it passes to
490 the mail store in order to access the client's mail. In this way, a
491 compromised IMAP server cannot be used to access the mail or
492 credentials for other users.
494 It is important to realize that simply throwing an extra box in front
495 of the mail servers, such as a gateway that may use HTTP or any of a
496 number of synchronization protocols to communicate with clients, does
497 not itself change the security aspects. By adding such a gateway,
498 the overall security of the system, and the vulnerability of the mail
499 servers, may remain unchanged or may be significantly worsened.
500 Isolation and indirection can be used to protect against specific
501 risks, but to be effective, such steps need to be done after a threat
502 analysis, and with an understanding of the issues involved.
506Gellens Best Current Practice [Page 9]
508RFC 5383 Lemonade Deployment Considerations October 2008
511 Organizations SHOULD deploy servers that support the use of TLS for
512 all connections and that can be optionally configured to require TLS.
513 When TLS is used, it SHOULD be via the STARTTLS extensions rather
514 than the alternate port method. TLS can be an effective measure to
515 protect against specific threats, including eavesdropping and
516 alteration, of the traffic between the endpoints. However, just
517 because TLS is deployed does not mean the system is "secure".
519 Attempts at bypassing current firewall policy when deploying new
520 services have serious risks, as discussed in Section 6.1.
522 It's rare for a new service to not have associated security
523 considerations. Making email available to an organization's members
524 using mobile devices can offer significant benefits.
528 Chris Newman and Phil Karn suggested very helpful text. Brian Ross
529 and Dave Cridland reviewed drafts and provided excellent suggestions.
53110. Normative References
533 [BEHAVE-TCP] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar,
534 S., and P. Srisuresh, "NAT Behavioral
535 Requirements for TCP", BCP 142, RFC 5382, October
538 [HOST-REQUIREMENTS] Braden, R., Ed., "Requirements for Internet Hosts
539 - Communication Layers", STD 3, RFC 1122, October
542 [KEYWORDS] Bradner, S., "Key words for use in RFCs to
543 Indicate Requirement Levels", BCP 14, RFC 2119,
546 [IANA] IANA Port Number Registry,
547 <http://www.iana.org/assignments/port-numbers>
549 [TCP] Postel, J., "Transmission Control Protocol", STD
550 7, RFC 793, September 1981.
55211. Informative References
554 [ACAP] Newman, C. and J. Myers, "ACAP -- Application
555 Configuration Access Protocol", RFC 2244,
562Gellens Best Current Practice [Page 10]
564RFC 5383 Lemonade Deployment Considerations October 2008
567 [FIREWALLS] Freed, N., "Behavior of and Requirements for
568 Internet Firewalls", RFC 2979, October 2000.
570 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
571 VERSION 4rev1", RFC 3501, March 2003.
573 [KLUDGE] Moore, K., "On the use of HTTP as a Substrate",
574 BCP 56, RFC 3205, February 2002.
576 [PROFILE] Maes, S. and A. Melnikov, "Internet Email to
577 Support Diverse Service Environments (Lemonade)
578 Profile", RFC 4550, June 2006.
580 [PROXIES] Chatel, M., "Classical versus Transparent IP
581 Proxies", RFC 1919, March 1996.
583 [SUBMISSION] Gellens, R. and J. Klensin, "Message Submission
584 for Mail", RFC 4409, April 2006.
589 QUALCOMM Incorporated
593 EMail: randy@qualcomm.com
618Gellens Best Current Practice [Page 11]
620RFC 5383 Lemonade Deployment Considerations October 2008
623Full Copyright Statement
625 Copyright (C) The IETF Trust (2008).
627 This document is subject to the rights, licenses and restrictions
628 contained in BCP 78, and except as set forth therein, the authors
629 retain all their rights.
631 This document and the information contained herein are provided on an
632 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
633 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
634 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
635 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
636 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
637 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
641 The IETF takes no position regarding the validity or scope of any
642 Intellectual Property Rights or other rights that might be claimed to
643 pertain to the implementation or use of the technology described in
644 this document or the extent to which any license under such rights
645 might or might not be available; nor does it represent that it has
646 made any independent effort to identify any such rights. Information
647 on the procedures with respect to rights in RFC documents can be
648 found in BCP 78 and BCP 79.
650 Copies of IPR disclosures made to the IETF Secretariat and any
651 assurances of licenses to be made available, or the result of an
652 attempt made to obtain a general license or permission for the use of
653 such proprietary rights by implementers or users of this
654 specification can be obtained from the IETF on-line IPR repository at
655 http://www.ietf.org/ipr.
657 The IETF invites any interested party to bring to its attention any
658 copyrights, patents or patent applications, or other proprietary
659 rights that may cover technology that may be required to implement
660 this standard. Please address the information to the IETF at
674Gellens Best Current Practice [Page 12]