RFC 5383

Deployment Considerations for Lemonade-Compliant Mobile Email

📅 published October 2008, from ietf

RFC 5383 🎀 Deployment Considerations for Lemonade-Compliant Mobile Email

Okay bestie, this is RFC 5383 💖, a Best Current Practice (that's BCP 143 💅). It came out of the Network Working Group in October 2008 and was written by R. Gellens at Qualcomm ✨. Its category is Best Current Practice, and its header doesn't list any RFC it obsoletes or updates, so it's standing on its own 🦋.

Status of This Memo 🌸

This doc specifies an Internet Best Current Practice for the Internet Community, and it's asking for discussion and suggestions for improvements 💬. Distribution of this memo is unlimited 🌈.

Abstract 🦋

This doc talks about deployment issues and lays out requirements for successful mobile email deployment that are implicit in the IETF lemonade documents 📬.

Table of Contents 📋

1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Ports ...........................................................2
4. TCP Connections .................................................3
   4.1. Lifetime ...................................................4
   4.2. Maintenance during Temporary Transport Loss ................5
5. Dormancy ........................................................6
6. Firewalls .......................................................6
   6.1. Firewall Traversal .........................................7
7. NATs ............................................................8
8. Security Considerations .........................................8
9. Acknowledgments ................................................10
10. Normative References ..........................................10
11. Informative References ........................................10

1. Introduction 💌

Okay so the IETF lemonade group has built a set of extensions to IMAP and Message Submission 🛠️. They also wrote a profile document that restricts server behavior and describes client usage [PROFILE] 💅.

Getting lemonade-compliant mobile email to actually work needs a bunch of functionality that everyone just assumes is there, so it's not really covered in email RFCs 🫠. This doc covers some of those extra considerations, with a focus on the ones that have been reported as problematic 🔥.

2. Conventions Used in This Document 📏

Here's the vibe on the key words 🤓: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS] ✨.

3. Ports 🔌

Okay, so both IMAP and Message Submission have well-known ports assigned [IANA], and those ports MUST be available 🚪. IMAP uses port 143, and Message Submission uses port 587 💖. It is REQUIRED that the client be able to contact the server on these ports. Hence, the client and server systems, as well as any intermediary systems, MUST allow communication on these ports 🫶.

Historically, Message User Agents (MUAs) used port 25 for Message Submission, and [SUBMISSION] does accommodate this 🕰️. But it's getting more and more common for ISPs and organizations to restrict outbound port 25 🚫. Hotels and other public places sometimes intercept port 25 connections no matter what the destination host is 😭. That means users can end up unknowingly submitting potentially sensitive stuff to unknown and untrusted third-party servers 💀. Typically, users have no idea this is happening. (Such interception violates [FIREWALLS] and has many negative consequences.) 🙈

Due to endemic security vulnerabilities in widely deployed SMTP servers, organizations often use application-level firewalls that intercept SMTP and only permit a limited subset of the protocol 🧱. So new extensions are harder to deploy on port 25 🥲. Since lemonade needs support for several [SUBMISSION] extensions, it is extremely important that lemonade clients use, and lemonade servers listen on, port 587 by default 👑.

Also, besides the traffic between client and server, lemonade requires that the Message Submission server be able to establish a TCP connection to the IMAP server (for forward-without-download) 📨. That uses port 143 by default 🌟.

Messaging clients sometimes use protocols to store, retrieve, and update configuration and preference data ⚙️. Stuff like setting a new device to use the settings from another device, or having a device inherit default configuration from a user account, an organization, or some other source, is likely to be even more useful with small mobile devices 📱🧚. There are lots of protocols for this, and most of them have designated ports 🎀. It's important that clients can reach these servers on the right ports 💅. As an example, [ACAP] is one protocol that can be used for this, and if you use it, port 674 needs to be available 🍓.

Note that systems that don't support application use of [TCP] on arbitrary ports are not full Internet clients 🙅‍♀️. As a result, such systems use gateways to the Internet that necessarily result in data integrity problems 😬.

4. TCP Connections 🧵

Both IMAP and Message Submission use [TCP] 🧶. Hence, the client system MUST be able to establish and maintain TCP connections to these servers 💖. The Message Submission server MUST be able to initiate a connection to the IMAP server 📤. Support for application use of [TCP] is REQUIRED of both client and server systems 🔥.

The requirements and advice in [HOST-REQUIREMENTS] SHOULD be followed 📖.

Okay, so for environments that don't support application use of [TCP] but do support it for HTTP, email can still be offered by deploying webmail 🌐. Webmail is the term for email over the web: the server speaks HTTP to the client and an email protocol (often IMAP) to the mail store 💌. Its functionality is necessarily limited by what the web client can do, what the webmail server can do, the protocols between the webmail server and the client (HTTP and a markup language such as HTML), and the protocols between the webmail server and the mail store 🕸️. But if HTTP is all an application has, the environment is by definition limited, so the functionality offered to the user must also be limited, and it can't be lemonade compliant 🥺.

4.1. Lifetime ⏳

In this doc, "idle" refers to the idle time, as in the "established connection idle-timeout" of [BEHAVE-TCP] 😴. "Duration" refers to the total time a TCP connection has been established ⏱️.

The duration of TCP connections between the client and server systems for both IMAP and Message Submission can be arbitrarily long 🌙. The client system, the server, and all intermediate systems MUST NOT terminate these TCP connections simply because of their duration (that is, just because of how long they've been open) 🙅‍♀️.

Lemonade depends on idle timers being enforced only at the application level (IMAP and Message Submission) 🎯. If no data is received within a period of time, either side MAY terminate the connection as permitted by the protocol (see [SUBMISSION] or [IMAP]) ✂️. Since IMAP permits unsolicited notifications of state changes, it's reasonable for clients to stay connected for long stretches with no data being exchanged 🥰. Being forced to send data just to keep the connection alive can prevent or hinder optimizations such as dormancy mode (see Section 5) 😤.

Two hours is a pretty common configuration timeout at middleboxes 🕑. There are a bunch of sites where the network tears down TCP connections two hours after data was last sent in either direction (for example, REQ-5 in [BEHAVE-TCP]) 💀. So lemonade clients and servers SHOULD make sure that, unless a specific configuration setting says otherwise with a longer maximum idle interval, the TCP connection doesn't sit idle for two hours ⭐. This rule makes sure that, by default, lemonade clients and servers work fine in environments set up with a two-hour maximum for idle TCP connections 🫶. Network and server operators can still let IMAP connections stay idle for more than two hours, and get more out of dormancy, by configuring lemonade clients, servers, and network equipment to allow it 🔧.

It's been reported that some networks put their own duration limits on TCP connections other than HTTP 🚧. That behavior is harmful to email and to all other TCP-based protocols 😡. It's unclear how widespread this is, or whether it's an accidental side effect of trying to optimize for HTTP traffic, implementation limits in firewalls, NATs, or other devices, or a deliberate choice 🤷‍♀️. Either way, a barrier like this to TCP connections is a serious risk to the growing use of IETF protocols on such networks 🚨. TCP is designed to be more efficient when it's used to transfer data over time, so prohibiting these connections imposes hidden costs on an operator's network and forces clients to use TCP in inefficient ways 📉. One way carriers can accidentally force TCP connections closed, so users waste packets reopening them, is described in Section 7 🙈.

Note that systems can still terminate TCP connections at any time based on local decisions, for example to prevent overload during a denial-of-service attack 🛡️. These mechanisms are allowed to take idle time into account, and these requirements don't affect them ✨.

4.2. Maintenance during Temporary Transport Loss 📶

TCP is designed to survive temporary loss of lower-level connectivity 💪. That kind of transient loss isn't uncommon in mobile systems (for example, due to handoffs, fade, and so on) 📵. The TCP connection SHOULD be able to survive temporary lower-level loss when the IP address of the client doesn't change (for example, a short loss of the mobile device's traffic channel or periods of high packet loss) 🫠. So the TCP/IP stack on the client, the server, and all intermediate systems SHOULD maintain the TCP connection during transient loss of connectivity 🧚.

Generally, applications can choose whether or not to turn on TCP keep-alives, but in lots of cases they can't change anything else about TCP keep-alive operation, like the time between keep-alive packets, the number of packets sent before the connection is aborted, and so on 🎛️. In some environments these are operating system tuning parameters that the application doesn't control 🙃. Operational difficulties have also been reported with applications using the TCP keep-alive option, which might be due to TCP implementation differences or defects specific to a platform 🐛. So lemonade client and server systems SHOULD NOT set the TCP keep-alive socket option unless they're operating in environments where it works correctly and such packets won't be sent more often than every two hours 🙅‍♀️. Application-level keep-alives (such as IMAP NOOP) MAY be used instead of the TCP keep-alive option 💜.

Client, server, and intermediate systems MUST comply with the "Destination Unreachable -- codes 0, 1, 5" text in Section 4.2.3.9 of [HOST-REQUIREMENTS], which states:

"Since these Unreachable messages indicate soft error conditions, TCP MUST NOT abort the connection" 🫶

5. Dormancy 💤

okay so cellular data channels are connection-oriented 📶, which means the network literally brings them up or tears them down to set up or end connections. setting up connections costs network resources, so this is a whole thing. generally speaking, a phone's battery lasts longer when the traffic channel gets used less 🔋 (it's giving efficiency).

some mobile devices and networks support dormant mode 😴. in dormant mode the traffic channel gets brought down during idle periods, but the PPP or equivalent level stays active and the mobile keeps its IP address ✨.

Maintenance of TCP connections during dormancy SHOULD be supported by the client, server, and any intermediate systems, as described in Sections 4.1 and 4.2 🫶.

sending packets just to keep the session alive is kinda messy 🙃. it causes unnecessary channel establishment and timeouts. with a long-idle TCP connection, the channel would keep waking up, sitting idle until it times out, then waking up again, on repeat, forever. however, unless you've got specific configuration info saying otherwise, it's necessary to do this to make sure things work correctly by default 💅.

6. Firewalls 🔥

new services have to pass through firewalls to be usable by corporate employees or organization members connecting from outside, like when they're using mobile devices 📱. firewalls exist to block traffic, but exceptions have to be made so services can actually be used. there's a whole body of best practices built on long experience here 📚, and there are plenty of techniques that help organizations balance protecting themselves with providing services to their members, employees, and/or customers 🛡️. (describing or even listing those techniques is beyond the scope of this document, but Section 8 does mention some 👀.)

it is critical that protocol design and architecture permit these practices and not constrain them 🙌. one key way a new service can help its own secure deployment is by keeping the one-to-one association between services and port numbers 🔐.

one or more firewalls might exist in the path between the client and server systems, as well as between the Message Submission and IMAP servers. proper deployment requires that TCP connections be possible from the client system to the IMAP and Message Submission ports on the servers, and also from the Message Submission server to the IMAP server. this may mean configuring firewalls to permit that usage 🎀.

Firewalls deployed in the network path MUST NOT damage protocol traffic. in particular, both Message Submission and IMAP connections from the client MUST be permitted. Firewalls MUST NOT partially block extensions to these protocols, such as by allowing one side of an extension negotiation. doing so leaves the two sides out of synch, which leads to later failures 💀. see [FIREWALLS] for more discussion 📖.

application proxies, which are not uncommon mechanisms, are discussed in [PROXIES] 🧚.

6.1. Firewall Traversal

an often-heard complaint from people trying to deploy new services inside an organization is that the group maintaining the firewall is unable or unwilling to open the required ports 😤. the group that owns the firewall is in charge of organizational network security, so it's often reluctant to open ports without understanding the benefits and security implications of the new service 🧐.

the group that wants to deploy the new service is often tempted to skip the procedure and the internal politics needed to open the ports 🙈. a tempting kludge is to tunnel the new service over an existing service that's already allowed through the firewall, typically HTTP on port 80 or sometimes SMTP on port 25. some of the downsides of this are discussed in [KLUDGE] 🫠.

this kind of bypass can look immediately successful, since the new service seems to deploy just fine. ⚠️ however, assuming the network security group is competent, once they find out about the kludge, they'll generally block the violation of organizational security policy. it's hard to design an application-level proxy/firewall that provides that access control without violating the transparency requirements of firewalls, as described in [FIREWALLS]. collateral damage is common here 😭. the new service (which seemed totally fine at first) and the existing services that were used to tunnel it both become subject to arbitrary and unpredictable failures. this builds an adversarial relationship between the two groups, which makes resolving things even harder 💔.

it's even more serious if a vulnerability is found in the new service 🚨. until the vulnerability is fixed, the network security group has to disable both the new service and the (typically mission-critical) existing service it's layered on top of.

there's a famous truism that any computer connected to a network is insecure 🥀. security and usefulness are both important, and organizations make choices to get acceptable measures in both areas 💜. deploying a new service typically means deciding to permit access to the ports it uses, with appropriate protections in place. the delay needed to review a new service's implications can be super frustrating 😩, but in the long run it's likely to cost less than a kludge 💅.

7. NATs 🌐

Any NAT boxes that are deployed between client and server systems MUST comply with REQ-5 in [BEHAVE-TCP], which requires that "the value of the 'established connection idle-timeout' MUST NOT be less than 2 hours 4 minutes" ⏰.

see Section 5 for more info on connection lifetimes 🦋.

note that IMAP and Message Submission clients will automatically re-open TCP connections as needed 🔄. but it saves time, packets, and processing to avoid having to do that. re-opening IMAP and Message Submission connections usually costs authentication, Transport Layer Security (TLS) negotiation, and server processing, plus resetting TCP behavior like windows 🥱. it's also wasteful to force clients to send NOOP commands just to keep NAT state alive, especially since that can defeat dormancy mode 🙅‍♀️.

8. Security Considerations 🔐

there are numerous security considerations whenever an organization chooses to make any of its services available via the Internet 🌍. this includes email from mobile clients 📧.

sites that care about email security should do a threat analysis, get relevant protections in place, and then make a conscious decision to open up this service 🧠. as discussed in Section 6.1, piggybacking email traffic on the HTTP port to avoid making a firewall configuration change that would explicitly permit mobile email connections would skip this important step and reduce the overall security of the system 🚫.

organizations deploying a messaging server "on the edge" (that is, reachable from the open Internet) are encouraged to choose one that's been designed to operate in that environment 🏰.

this document doesn't try to catalogue either the risks an organization might face or the many techniques for protecting against them 🙅. but to help show the deployment considerations, a very small sample of risks and countermeasures appears below 👇.

some organizations worry that letting clients reach their mail servers directly over the Internet increases their vulnerability 😰. a successful exploit against a mail server could potentially expose all the mail and authentication credentials stored on it, and it could serve as an injection point for spam 📩. there are also concerns about eavesdropping on or modifying mail data and authentication credentials 👀.

a large number of approaches exist that can reduce these risks while still allowing access to mail services from mobile clients ✨.

placing servers inside one or more DMZs (demilitarized zones, also called perimeter networks) can protect the rest of the network from a compromised server 🧱. another way to reduce risk is to store authentication credentials on a system that isn't reachable from the Internet, which the servers inside the DMZ can only access by sending the credentials as received from the client and getting back an authorized/not authorized response 🔑. this kind of isolation reduces how useful a compromised server is as a base for attacking other network hosts 🛡️.

there are lots of other techniques for further isolation too 🧩. for example, the DMZ IMAP server could have no mail store of its own. when a client connects to a server like that, the DMZ IMAP server might contact the authentication server and receive a ticket, which it passes to the mail store to access the client's mail. this way, a compromised IMAP server can't be used to access the mail or credentials of other users 🙌.

it's important to realize that just throwing an extra box in front of the mail servers doesn't by itself change the security picture 🙅‍♀️. that's true even for a gateway that uses HTTP or any of a number of synchronization protocols to talk to clients. with a gateway like that, the overall security of the system and the vulnerability of the mail servers may stay the same or get significantly worse 😱. isolation and indirection can protect against specific risks, but to work, those steps need to happen after a threat analysis, and with a real understanding of the issues involved 🤓.

Organizations SHOULD deploy servers that support the use of TLS for all connections and that can optionally be configured to require TLS 🔒. when TLS is used, it SHOULD be via the STARTTLS extensions rather than the alternate port method 💜. TLS can be an effective measure against specific threats, including eavesdropping on and alteration of traffic between the endpoints. however, just because TLS is deployed doesn't mean the system is "secure" 🙃.

attempts to bypass current firewall policy when deploying new services carry serious risks, as discussed in Section 6.1 🚨.

it's rare for a new service to have no associated security considerations 💅. making email available to an organization's members on mobile devices can offer significant benefits, though 🌸.

9. Acknowledgments 🫶

Chris Newman and Phil Karn suggested very helpful text 💖. Brian Ross and Dave Cridland reviewed drafts and gave excellent suggestions 👑.

10. Normative References 📚

  • [BEHAVE-TCP] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
  • [HOST-REQUIREMENTS] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
  • [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [IANA] IANA Port Number Registry, http://www.iana.org/assignments/port-numbers
  • [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

11. Informative References ✨

okay bestie, this is the reading list 📚 these are the docs the spec points to for extra background, not stuff you have to implement 🫶

  • [ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997. 🎀
  • [FIREWALLS] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000. 🧱
  • [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. 📬
  • [KLUDGE] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002. 🌸
  • [PROFILE] Maes, S. and A. Melnikov, "Internet Email to Support Diverse Service Environments (Lemonade) Profile", RFC 4550, June 2006. 💜
  • [PROXIES] Chatel, M., "Classical versus Transparent IP Proxies", RFC 1919, March 1996. 🦋
  • [SUBMISSION] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006. ✉️

Author's Address 🎀

the author is Randall Gellens, and you can reach him here 💌

Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA  92121

EMail: randy@qualcomm.com

Copyright (C) The IETF Trust (2008). 🌈

this doc is covered by the rights, licenses and restrictions in BCP 78, and apart from what that says, the authors keep all their rights 🫶

the doc and everything in it come "AS IS" 😭 THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀

Intellectual Property 🔥

the IETF doesn't take a side on whether any IPR claims about this tech are valid or how broad they are, and it also doesn't say it went looking for any 🕵️‍♀️ whether a license exists or not is up to the rights holders. The rules for rights in RFCs live in BCP 78 and BCP 79 📖

copies of IPR disclosures sent to the IETF Secretariat, any licence assurances, and the results of attempts to get a general license for implementers or users can be found in the IETF online IPR repository at http://www.ietf.org/ipr. 🌐

the IETF also invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard to tell them at ietf-ipr@ietf.org. Say something, periodt 📣👑

📦 where this page comes from