Guidelines for Defining Packet Timestamps
RFC 8877

Network Working Group                                            S. Maes
Request for Comments: 4550                                        Oracle
Category: Standards Track                                    A. Melnikov
                                                              Isode Ltd.
                                                               June 2006

         Internet Email to Support Diverse Service Environments
                           (Lemonade) Profile

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes a profile (a set of required extensions,
   restrictions, and usage modes) of the IMAP and mail submission
   protocols.  This profile allows clients (especially those that are
   constrained in memory, bandwidth, processing power, or other areas)
   to efficiently use IMAP and Submission to access and submit mail.
   This includes the ability to forward received mail without needing to
   download and upload the mail, to optimize submission, and to
   efficiently resynchronize in case of loss of connectivity with the
   server.

   The Internet Email to Support Diverse Service Environments (Lemonade)
   profile relies upon extensions to IMAP and Mail Submission protocols;
   specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501)
   extensions and the BURL extension to the SUBMIT protocol (RFC 4409).

Maes & Melnikov             Standards Track                     [Page 1]
RFC 4550                    Lemonade Profile                   June 2006

Table of Contents

   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................3
   2. Forward without Download ........................................3
      2.1. Motivations ................................................3
      2.2. Message Sending Overview ...................................4
      2.3. Traditional Strategy .......................................4
      2.4. Step-by-Step Description ...................................5
           2.4.1. Message Assembly Using IMAP CATENATE Extension ......6
           2.4.2. Message Assembly Using SMTP CHUNKING and
                  BURL Extensions ....................................10
      2.5. Normative Statements Related to Forward without Download ..14
      2.6. Security Considerations for "pawn-tickets" ................14
      2.7. The fcc Problem ...........................................15
      2.8. Registration of $Forwarded IMAP Keyword ...................15
   3. Message Submission .............................................15
      3.1. Pipelining ................................................16
      3.2. DSN Support ...............................................16
      3.3. Message Size Declaration ..................................16
      3.4. Enhanced Status Code Support ..............................16
      3.5. TLS .......................................................16
   4. Quick Resynchronization ........................................16
   5. Additional IMAP Extensions .....................................17
   6. Summary of the Required IMAP and SMTP Extensions ...............17
   7. Future work ....................................................18
   8. Security Considerations ........................................18
      8.1. Confidentiality Protection of Submitted Messages ..........19
      8.2. TLS .......................................................19
   9. References .....................................................20
      9.1. Normative References ......................................20
      9.2. Informative References ....................................21
   10. Acknowledgements ..............................................21

Maes & Melnikov             Standards Track                     [Page 2]
RFC 4550                    Lemonade Profile                   June 2006

1.  Introduction

   Lemonade provides enhancements to Internet email to support diverse
   service environments.

   This document describes the Lemonade profile, which includes:

      -  "forward without download", which describes exchanges between
         Lemonade clients and servers to allow new email messages to be
         submitted incorporating content that resides on locations
         external to the client.

      -  Quick mailbox resynchronization using [CONDSTORE].

      -  Several IMAP and SMTP extensions that save bandwidth and/or
         number of round-trips required to send/receive data.

   The organization of this document is as follows.  Section 2 describes
   "forward without download".  Section 3 describes additional SMTP
   extensions that must be supported by all Lemonade Submission servers.
   Section 4 describes IMAP quick resynchronization.

1.1.  Conventions Used in This Document

   In examples, "M:", "I:", and "S:" indicate lines sent by the client
   messaging user agent, IMAP e-mail server, and SMTP submit server,
   respectively.

   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 [RFC2119].

   All examples in this document are optimized for Lemonade use and
   might not represent examples of proper protocol usage for a general
   use Submit/IMAP client.  In particular, examples assume that Lemonade
   Submit and IMAP servers support all Lemonade extensions described in
   this document, so they don't show how to deal with absence of an
   extension.

2.  Forward without Download

2.1.  Motivations

   The advent of client/server email using the [RFC3501], [RFC2821], and
   [SUBMIT] protocols has changed what formerly were local disk
   operations into repetitive network data transmissions.

Maes & Melnikov             Standards Track                     [Page 3]
RFC 4550                    Lemonade Profile                   June 2006

   Lemonade "forward without download" makes use of the [BURL] SUBMIT
   extension to enable access to external sources during the submission
   of a message.  In combination with the IMAP [URLAUTH] extension,
   inclusion of message parts or even entire messages from the IMAP mail
   store is possible with a minimal trust relationship between the IMAP
   and SMTP SUBMIT servers.

   Lemonade "forward without download" has the advantage of maintaining
   one submission protocol, and thus avoids the risk of having multiple
   parallel and possibly divergent mechanisms for submission.  The
   client can use Submit/SMTP [SUBMIT] extensions without these being
   added to IMAP.  Furthermore, by keeping the details of message
   submission in the SMTP SUBMIT server, Lemonade "forward without
   download&'Souza,
              "Initial Performance Metrics Registry Entries", Work in
              Progress, Internet-Draft, draft-ietf-ippm-initial-
              registry-16, 9 March 2020, <https://tools.ietf.org/html/
              draft-ietf-ippm-initial-registry-16>.

   [NSHMD]    Guichard, J., Smith, M., Kumar, S., Majee, S., and T.
              Mizrahi, "Network Service Header (NSH) MD Type 1: Context
              Header Allocation (Data Center)", Work in Progress,
              Internet-Draft, draft-ietf-sfc-nsh-dc-allocation-02, 25
              September 2018, <https://tools.ietf.org/html/draft-ietf-
              sfc-nsh-dc-allocation-02>.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <https://www.rfc-editor.org/info/rfc3339>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <https://www.rfc-editor.org/info/rfc3550>.

   [RFC4656]  Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
              Zekauskas, "A One-way Active Measurement Protocol
              (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
              <https://www.rfc-editor.org/info/rfc4656>.

   [RFC5357]  Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
              Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
              RFC 5357, DOI 10.17487/RFC5357, October 2008,
              <https://www.rfc-editor.org/info/rfc5357>.

   [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
              Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
              September 2009, <https://www.rfc-editor.org/info/rfc5646>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

   [RFC6019]  Housley, R., "BinaryTime: An Alternate Format for
              Representing Date and Time in ASN.1", RFC 6019,
              DOI 10.17487/RFC6019, September 2010,
              <https://www.rfc-editor.org/info/rfc6019>.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374,
              DOI 10.17487/RFC6374, September 2011,
              <https://www.rfc-editor.org/info/rfc6374>.

   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013,
              <https://www.rfc-editor.org/info/rfc6991>.

   [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
              "Specification of the IP Flow Information Export (IPFIX)
              Protocol for the Exchange of Flow Information", STD 77,
              RFC 7011, DOI 10.17487/RFC7011, September 2013,
              <https://www.rfc-editor.org/info/rfc7011>.

   [RFC7323]  Borman, D., Braden, B., Jacobson, V., and R.
              Scheffenegger, Ed., "TCP Extensions for High Performance",
              RFC 7323, DOI 10.17487/RFC7323, September 2014,
              <https://www.rfc-editor.org/info/rfc7323>.

   [RFC7384]  Mizrahi, T., "Security Requirements of Time Protocols in
              Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
              October 2014, <https://www.rfc-editor.org/info/rfc7384>.

   [RFC7456]  Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and
              D. Eastlake 3rd, "Loss and Delay Measurement in
              Transparent Interconnection of Lots of Links (TRILL)",
              RFC 7456, DOI 10.17487/RFC7456, March 2015,
              <https://www.rfc-editor.org/info/rfc7456>.

   [RFC7493]  Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
              DOI 10.17487/RFC7493, March 2015,
              <https://www.rfc-editor.org/info/rfc7493>.

   [RFC8186]  Mirsky, G. and I. Meilik, "Support of the IEEE 1588
              Timestamp Format in a Two-Way Active Measurement Protocol
              (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017,
              <https://www.rfc-editor.org/info/rfc8186>.

Acknowledgments

   The authors thank Russ Housley, Yaakov Stein, Greg Mirsky, Warner
   Losh, Rodney Cummings, Miroslav Lichvar, Denis Reilly, Daniel Franke,
   Éric Vyncke, Ben Kaduk, Ian Swett, Francesca Palombini, Watson Ladd,
   and other members of the NTP Working Group for their many helpful
   comments.  The authors gratefully acknowledge Harlan Stenn and the
   people from the Network Time Foundation for sharing their thoughts
   and ideas.

Authors' Addresses

   Tal Mizrahi
   Huawei
   8-2 Matam
   Haifa 3190501
   Israel

   Email: tal.mizrahi.phd@gmail.com

   Joachim Fabini
   TU Wien
   Gusshausstrasse 25/E389
   1040 Vienna
   Austria

   Phone: +43 1 58801 38813
   Email: Joachim.Fabini@tuwien.ac.at
   URI:   http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/

   Al Morton
   AT&T Labs
   200 Laurel Avenue South
   Middletown, NJ 07748
   United States of America

   Phone: +1 732 420 1571
   Email: acmorton@att.com