Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8621

The JSON Meta Application Protocol (JMAP) for Mail

Pages: 108
Proposed Standard
Updates:  5788
Part 5 of 5 – Pages 88 to 108
First   Prev   None

Top   ToC   RFC8621 - Page 88   prevText

9. Security Considerations

All security considerations of JMAP [RFC8620] apply to this specification. Additional considerations specific to the data types and functionality introduced by this document are described in the following subsections.

9.1. EmailBodyPart Value

Service providers typically perform security filtering on incoming messages, and it's important that the detection of content-type and charset for the security filter aligns with the heuristics performed by JMAP servers. Servers that apply heuristics to determine the content-type or charset for an EmailBodyValue SHOULD document the heuristics and provide a mechanism to turn them off in the event they are misaligned with the security filter used at a particular mail host. Automatic conversion of charsets that allow hidden channels for ASCII text, such as UTF-7, have been problematic for security filters in the past, so server implementations can mitigate this risk by having such conversions off-by-default and/or separately configurable. To allow the client to restrict the volume of data it can receive in response to a request, a maximum length may be requested for the data returned for a textual body part. However, truncating the data may change the semantic meaning, for example, truncating a URL changes its location. Servers that scan for links to malicious sites should take care to either ensure truncation is not at a semantically significant point or rescan the truncated value for malicious content before returning it.

9.2. HTML Email Display

HTML message bodies provide richer formatting for messages but present a number of security challenges, especially when embedded in a webmail context in combination with interface HTML. Clients that render HTML messages should carefully consider the potential risks, including:
Top   ToC   RFC8621 - Page 89
   o  Embedded JavaScript can rewrite the message to change its content
      on subsequent opening, allowing users to be mislead.  In webmail
      systems, if run in the same origin as the interface, it can access
      and exfiltrate all private data accessible to the user, including
      all other messages and potentially contacts, calendar events,
      settings, and credentials.  It can also rewrite the interface to
      undetectably phish passwords.  A compromise is likely to be
      persistent, not just for the duration of page load, due to
      exfiltration of session credentials or installation of a service
      worker that can intercept all subsequent network requests
      (however, this would only be possible if blob downloads are also
      available on the same origin, and the service worker script is
      attached to the message).

   o  HTML documents may load content directly from the Internet rather
      than just referencing attached resources.  For example, you may
      have an "<img>" tag with an external "src" attribute.  This may
      leak to the sender when a message is opened, as well as the IP
      address of the recipient.  Cookies may also be sent and set by the
      server, allowing tracking between different messages and even
      website visits and advertising profiles.

   o  In webmail systems, CSS can break the layout or create phishing
      vulnerabilities.  For example, the use of "position:fixed" can
      allow a message to draw content outside of its normal bounds,
      potentially clickjacking a real interface element.

   o  If in a webmail context and not inside a separate frame, any
      styles defined in CSS rules will apply to interface elements as
      well if the selector matches, allowing the interface to be
      modified.  Similarly, any interface styles that match elements in
      the message will alter their appearance, potentially breaking the
      layout of the message.

   o  The link text in HTML has no necessary correlation with the actual
      target of the link, which can be used to make phishing attacks
      more convincing.

   o  Links opened from a message or embedded external content may leak
      private info in the Referer header sent by default in most
      systems.

   o  Forms can be used to mimic login boxes, providing a potent
      phishing vector if allowed to submit directly from the message
      display.
Top   ToC   RFC8621 - Page 90
   There are a number of ways clients can mitigate these issues, and a
   defence-in-depth approach that uses a combination of techniques will
   provide the strongest security.

   o  HTML can be filtered before rendering, stripping potentially
      malicious content.  Sanitising HTML correctly is tricky, and
      implementors are strongly recommended to use a well-tested library
      with a carefully vetted whitelist-only approach.  New features
      with unexpected security characteristics may be added to HTML
      rendering engines in the future; a blacklist approach is likely to
      result in security issues.

      Subtle differences in parsing of HTML can introduce security
      flaws: to filter with 100% accuracy, you need to use the same
      parser that the HTML rendering engine will use.

   o  Encapsulating the message in an "<iframe sandbox>", as defined in
      [HTML], Section 4.7.6, can help mitigate a number of risks.  This
      will:

      *  Disable JavaScript.

      *  Disable form submission.

      *  Prevent drawing outside of its bounds or conflicts between
         message CSS and interface CSS.

      *  Establish a unique anonymous origin, separate to the containing
         origin.

   o  A strong Content Security Policy (see <https://www.w3.org/TR/
      CSP3/>) can, among other things, block JavaScript and the loading
      of external content should it manage to evade the filter.

   o  The leakage of information in the Referer header can be mitigated
      with the use of a referrer policy (see <https://www.w3.org/TR/
      referrer-policy/>).

   o  A "crossorigin=anonymous" attribute on tags that load remote
      content can prevent cookies from being sent.

   o  If adding "target=_blank" to open links in new tabs, also add
      "rel=noopener" to ensure the page that opens cannot change the URL
      in the original tab to redirect the user to a phishing site.

   As highly complex software components, HTML rendering engines
   increase the attack surface of a client considerably, especially when
   being used to process untrusted, potentially malicious content.
Top   ToC   RFC8621 - Page 91
   Serious bugs have been found in image decoders, JavaScript engines,
   and HTML parsers in the past, which could lead to full system
   compromise.  Clients using an engine should ensure they get the
   latest version and continue to incorporate any security patches
   released by the vendor.

9.3. Multiple Part Display

Messages may consist of multiple parts to be displayed sequentially as a body. Clients MUST render each part in isolation and MUST NOT concatenate the raw text values to render. Doing so may change the overall semantics of the message. If the client or server is decrypting a Pretty Good Privacy (PGP) or S/MIME encrypted part, concatenating with other parts may leak the decrypted text to an attacker, as described in [EFAIL].

9.4. Email Submission

SMTP submission servers [RFC6409] use a number of mechanisms to mitigate damage caused by compromised user accounts and end-user systems including rate limiting, anti-virus/anti-spam milters (mail filters), and other technologies. The technologies work better when they have more information about the client connection. If JMAP email submission is implemented as a proxy to an SMTP submission server, it is useful to communicate this information from the JMAP proxy to the submission server. The de facto XCLIENT extension to SMTP [XCLIENT] can be used to do this, but use of an authenticated channel is recommended to limit use of that extension to explicitly authorised proxies. JMAP servers that proxy to an SMTP submission server SHOULD allow use of the submissions port [RFC8314]. Implementation of a mechanism similar to SMTP XCLIENT is strongly encouraged. While Simple Authentication and Security Layer (SASL) PLAIN over TLS [RFC4616] is presently the mandatory-to-implement mechanism for interoperability with SMTP submission servers [RFC4954], a JMAP submission proxy SHOULD implement and prefer a stronger mechanism for this use case such as TLS client certificate authentication with SASL EXTERNAL ([RFC4422], Appendix A) or Salted Challenge Response Authentication Mechanism (SCRAM) [RFC7677]. In the event the JMAP server directly relays mail to SMTP servers in other administrative domains, implementation of the de facto [milter] protocol is strongly encouraged to integrate with third-party products that address security issues including anti-virus/anti-spam, reputation protection, compliance archiving, and data loss prevention. Proxying to a local SMTP submission server may be a simpler way to provide such security services.
Top   ToC   RFC8621 - Page 92

9.5. Partial Account Access

A user may only have permission to access a subset of the data that exists in an account. To avoid leaking unauthorised information, in such a situation, the server MUST treat any data the user does not have permission to access the same as if it did not exist. For example, suppose user A has an account with two Mailboxes, inbox and sent, but only shares the inbox with user B. In this case, when user B fetches Mailboxes for this account, the server MUST behave as though the sent Mailbox did not exist. Similarly, when querying or fetching Email objects, it MUST treat any messages that just belong to the sent Mailbox as though they did not exist. Fetching Thread objects MUST only return ids for Email objects the user has permission to access; if none, the Thread again MUST be treated the same as if it did not exist. If the server forbids a single account from having two identical messages, or two messages with the same Message-Id header field, a user with write access can use the error returned by trying to create/import such a message to detect whether it already exists in an inaccessible portion of the account.

9.6. Permission to Send from an Address

In recent years, the email ecosystem has moved towards associating trust with the From address in the message [RFC5322], particularly with schemes such as Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC7489]. The set of Identity objects (see Section 6) in an account lets the client know which email addresses the user has permission to send from. Each email submission is associated with an Identity, and servers SHOULD reject submissions where the From header field of the message does not correspond to the associated Identity. The server MAY allow an exception to send an exact copy of an existing message received into the mail store to another address (otherwise known as "redirecting" or "bouncing"), although it is RECOMMENDED the server limit this to destinations the user has verified they also control. If the user attempts to create a new Identity object, the server MUST reject it with the appropriate error if the user does not have permission to use that email address to send from.
Top   ToC   RFC8621 - Page 93
   The SMTP MAIL FROM address [RFC5321] is often confused with the From
   message header field [RFC5322].  The user generally only ever sees
   the address in the message header field, and this is the primary one
   to enforce.  However, the server MUST also enforce appropriate
   restrictions on the MAIL FROM address [RFC5321] to stop the user from
   flooding a third-party address with bounces and non-delivery notices.

   The JMAP submission model provides separate errors for impermissible
   addresses in either context.

10. IANA Considerations

10.1. JMAP Capability Registration for "mail"

IANA has registered the "mail" JMAP Capability as follows: Capability Name: urn:ietf:params:jmap:mail Specification document: this document Intended use: common Change Controller: IETF Security and privacy considerations: this document, Section 9

10.2. JMAP Capability Registration for "submission"

IANA has registered the "submission" JMAP Capability as follows: Capability Name: urn:ietf:params:jmap:submission Specification document: this document Intended use: common Change Controller: IETF Security and privacy considerations: this document, Section 9
Top   ToC   RFC8621 - Page 94

10.3. JMAP Capability Registration for "vacationresponse"

IANA has registered the "vacationresponse" JMAP Capability as follows: Capability Name: urn:ietf:params:jmap:vacationresponse Specification document: this document Intended use: common Change Controller: IETF Security and privacy considerations: this document, Section 9

10.4. IMAP and JMAP Keywords Registry

This document makes two changes to the IMAP keywords registry as defined in [RFC5788]. First, the name of the registry is changed to the "IMAP and JMAP Keywords" registry. Second, a scope column is added to the template and registry indicating whether a keyword applies to "IMAP-only", "JMAP-only", "both", or "reserved". All keywords already in the IMAP keyword registry have been marked with a scope of "both". The "reserved" status can be used to prevent future registration of a name that would be confusing if registered. Registration of keywords with scope "reserved" omit most fields in the registration template (see registration of "$recent" below for an example); such registrations are intended to be infrequent. IMAP clients MAY silently ignore any keywords marked "JMAP-only" or "reserved" in the event they appear in protocol. JMAP clients MAY silently ignore any keywords marked "IMAP-only" or "reserved" in the event they appear in protocol. New "JMAP-only" keywords are registered in the following subsections. These keywords correspond to IMAP system keywords and are thus not appropriate for use in IMAP. These keywords cannot be subsequently registered for use in IMAP except via standards action.
Top   ToC   RFC8621 - Page 95

10.4.1. Registration of JMAP Keyword "$draft"

This registers the "JMAP-only" keyword "$draft" in the "IMAP and JMAP Keywords" registry. Keyword name: $draft Scope: JMAP-only Purpose (description): This is set when the user wants to treat the message as a draft the user is composing. This is the JMAP equivalent of the IMAP \Draft flag. Private or Shared on a server: BOTH Is it an advisory keyword or may it cause an automatic action: Automatic. If the account has an IMAP mailbox marked with the \Drafts special use attribute [RFC6154], setting this flag MAY cause the message to appear in that mailbox automatically. Certain JMAP computed values such as "unreadEmails" will change as a result of changing this flag. In addition, mail clients will typically present draft messages in a composer window rather than a viewer window. When/by whom the keyword is set/cleared: This is typically set by a JMAP client when referring to a draft message. One model for draft Emails would result in clearing this flag in an "EmailSubmission/set" operation with an "onSuccessUpdateEmail" argument. In a mail store shared by JMAP and IMAP, this is also set and cleared as necessary so it matches the IMAP \Draft flag. Related keywords: None Related IMAP/JMAP Capabilities: SPECIAL-USE [RFC6154] Security Considerations: A server implementing this keyword as a shared keyword may disclose that a user considers the message a draft message. This information would be exposed to other users with read permission for the Mailbox keywords. Published specification: this document Person & email address to contact for further information: JMAP mailing list <jmap@ietf.org> Intended usage: COMMON Owner/Change controller: IESG
Top   ToC   RFC8621 - Page 96

10.4.2. Registration of JMAP Keyword "$seen"

This registers the "JMAP-only" keyword "$seen" in the "IMAP and JMAP Keywords" registry. Keyword name: $seen Scope: JMAP-only Purpose (description): This is set when the user wants to treat the message as read. This is the JMAP equivalent of the IMAP \Seen flag. Private or Shared on a server: BOTH Is it an advisory keyword or may it cause an automatic action: Advisory. However, certain JMAP computed values such as "unreadEmails" will change as a result of changing this flag. When/by whom the keyword is set/cleared: This is set by a JMAP client when it presents the message content to the user; clients often offer an option to clear this flag. In a mail store shared by JMAP and IMAP, this is also set and cleared as necessary so it matches the IMAP \Seen flag. Related keywords: None Related IMAP/JMAP Capabilities: None Security Considerations: A server implementing this keyword as a shared keyword may disclose that a user considers the message to have been read. This information would be exposed to other users with read permission for the Mailbox keywords. Published specification: this document Person & email address to contact for further information: JMAP mailing list <jmap@ietf.org> Intended usage: COMMON Owner/Change controller: IESG
Top   ToC   RFC8621 - Page 97

10.4.3. Registration of JMAP Keyword "$flagged"

This registers the "JMAP-only" keyword "$flagged" in the "IMAP and JMAP Keywords" registry. Keyword name: $flagged Scope: JMAP-only Purpose (description): This is set when the user wants to treat the message as flagged for urgent/special attention. This is the JMAP equivalent of the IMAP \Flagged flag. Private or Shared on a server: BOTH Is it an advisory keyword or may it cause an automatic action: Automatic. If the account has an IMAP mailbox marked with the \Flagged special use attribute [RFC6154], setting this flag MAY cause the message to appear in that mailbox automatically. When/by whom the keyword is set/cleared: JMAP clients typically allow a user to set/clear this flag as desired. In a mail store shared by JMAP and IMAP, this is also set and cleared as necessary so it matches the IMAP \Flagged flag. Related keywords: None Related IMAP/JMAP Capabilities: SPECIAL-USE [RFC6154] Security Considerations: A server implementing this keyword as a shared keyword may disclose that a user considers the message as flagged for urgent/special attention. This information would be exposed to other users with read permission for the Mailbox keywords. Published specification: this document Person & email address to contact for further information: JMAP mailing list <jmap@ietf.org> Intended usage: COMMON Owner/Change controller: IESG
Top   ToC   RFC8621 - Page 98

10.4.4. Registration of JMAP Keyword "$answered"

This registers the "JMAP-only" keyword "$answered" in the "IMAP and JMAP Keywords" registry. Keyword name: $answered Scope: JMAP-only Purpose (description): This is set when the message has been answered. Private or Shared on a server: BOTH Is it an advisory keyword or may it cause an automatic action: Advisory. When/by whom the keyword is set/cleared: JMAP clients typically set this when submitting a reply or answer to the message. It may be set by the "EmailSubmission/set" operation with an "onSuccessUpdateEmail" argument. In a mail store shared by JMAP and IMAP, this is also set and cleared as necessary so it matches the IMAP \Answered flag. Related keywords: None Related IMAP/JMAP Capabilities: None Security Considerations: A server implementing this keyword as a shared keyword may disclose that a user has replied to a message. This information would be exposed to other users with read permission for the Mailbox keywords. Published specification: this document Person & email address to contact for further information: JMAP mailing list <jmap@ietf.org> Intended usage: COMMON Owner/Change controller: IESG
Top   ToC   RFC8621 - Page 99

10.4.5. Registration of "$recent" Keyword

This registers the keyword "$recent" in the "IMAP and JMAP Keywords" registry. Keyword name: $recent Scope: reserved Purpose (description): This keyword is not used to avoid confusion with the IMAP \Recent system flag. Published specification: this document Person & email address to contact for further information: JMAP mailing list <jmap@ietf.org> Owner/Change controller: IESG

10.5. IMAP Mailbox Name Attributes Registry

10.5.1. Registration of "inbox" Role

This registers the "JMAP-only" "inbox" attribute in the "IMAP Mailbox Name Attributes" registry, as established in [RFC8457]. Attribute Name: Inbox Description: New mail is delivered here by default. Reference: This document, Section 10.5.1 Usage Notes: JMAP only
Top   ToC   RFC8621 - Page 100

10.6. JMAP Error Codes Registry

The following subsections register several new error codes in the "JMAP Error Codes" registry, as defined in [RFC8620].

10.6.1. mailboxHasChild

JMAP Error Code: mailboxHasChild Intended use: common Change controller: IETF Reference: This document, Section 2.5 Description: The Mailbox still has at least one child Mailbox. The client MUST remove these before it can delete the parent Mailbox.

10.6.2. mailboxHasEmail

JMAP Error Code: mailboxHasEmail Intended use: common Change controller: IETF Reference: This document, Section 2.5 Description: The Mailbox has at least one message assigned to it, and the onDestroyRemoveEmails argument was false.

10.6.3. blobNotFound

JMAP Error Code: blobNotFound Intended use: common Change controller: IETF Reference: This document, Section 4.6 Description: At least one blob id referenced in the object doesn't exist.
Top   ToC   RFC8621 - Page 101

10.6.4. tooManyKeywords

JMAP Error Code: tooManyKeywords Intended use: common Change controller: IETF Reference: This document, Section 4.6 Description: The change to the Email's keywords would exceed a server-defined maximum.

10.6.5. tooManyMailboxes

JMAP Error Code: tooManyMailboxes Intended use: common Change controller: IETF Reference: This document, Section 4.6 Description: The change to the set of Mailboxes that this Email is in would exceed a server-defined maximum.

10.6.6. invalidEmail

JMAP Error Code: invalidEmail Intended use: common Change controller: IETF Reference: This document, Section 7.5 Description: The Email to be sent is invalid in some way.
Top   ToC   RFC8621 - Page 102

10.6.7. tooManyRecipients

JMAP Error Code: tooManyRecipients Intended use: common Change controller: IETF Reference: This document, Section 7.5 Description: The envelope [RFC5321] (supplied or generated) has more recipients than the server allows.

10.6.8. noRecipients

JMAP Error Code: noRecipients Intended use: common Change controller: IETF Reference: This document, Section 7.5 Description: The envelope [RFC5321] (supplied or generated) does not have any rcptTo email addresses.

10.6.9. invalidRecipients

JMAP Error Code: invalidRecipients Intended use: common Change controller: IETF Reference: This document, Section 7.5 Description: The rcptTo property of the envelope [RFC5321] (supplied or generated) contains at least one rcptTo value that is not a valid email address for sending to.
Top   ToC   RFC8621 - Page 103

10.6.10. forbiddenMailFrom

JMAP Error Code: forbiddenMailFrom Intended use: common Change controller: IETF Reference: This document, Section 7.5 Description: The server does not permit the user to send a message with this envelope From address [RFC5321].

10.6.11. forbiddenFrom

JMAP Error Code: forbiddenFrom Intended use: common Change controller: IETF Reference: This document, Sections 6.3 and 7.5 Description: The server does not permit the user to send a message with the From header field [RFC5322] of the message to be sent.

10.6.12. forbiddenToSend

JMAP Error Code: forbiddenToSend Intended use: common Change controller: IETF Reference: This document, Section 7.5 Description: The user does not have permission to send at all right now.
Top   ToC   RFC8621 - Page 104

11. References

11.1. Normative References

[HTML] Faulkner, S., Eicholz, A., Leithead, T., Danilo, A., and S. Moon, "HTML 5.2", World Wide Web Consortium Recommendation REC-html52-20171214, December 2017, <https://www.w3.org/TR/html52/>. [RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, DOI 10.17487/RFC1870, November 1995, <https://www.rfc-editor.org/info/rfc1870>. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <https://www.rfc-editor.org/info/rfc2045>. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, DOI 10.17487/RFC2047, November 1996, <https://www.rfc-editor.org/info/rfc2047>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, DOI 10.17487/RFC2231, November 1997, <https://www.rfc-editor.org/info/rfc2231>. [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, DOI 10.17487/RFC2369, July 1998, <https://www.rfc-editor.org/info/rfc2369>. [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, <https://www.rfc-editor.org/info/rfc2392>. [RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999, <https://www.rfc-editor.org/info/rfc2557>.
Top   ToC   RFC8621 - Page 105
   [RFC2852]  Newman, D., "Deliver By SMTP Service Extension", RFC 2852,
              DOI 10.17487/RFC2852, June 2000,
              <https://www.rfc-editor.org/info/rfc2852>.

   [RFC3282]  Alvestrand, H., "Content Language Headers", RFC 3282,
              DOI 10.17487/RFC3282, May 2002,
              <https://www.rfc-editor.org/info/rfc3282>.

   [RFC3461]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)",
              RFC 3461, DOI 10.17487/RFC3461, January 2003,
              <https://www.rfc-editor.org/info/rfc3461>.

   [RFC3463]  Vaudreuil, G., "Enhanced Mail System Status Codes",
              RFC 3463, DOI 10.17487/RFC3463, January 2003,
              <https://www.rfc-editor.org/info/rfc3463>.

   [RFC3464]  Moore, K. and G. Vaudreuil, "An Extensible Message Format
              for Delivery Status Notifications", RFC 3464,
              DOI 10.17487/RFC3464, January 2003,
              <https://www.rfc-editor.org/info/rfc3464>.

   [RFC3834]  Moore, K., "Recommendations for Automatic Responses to
              Electronic Mail", RFC 3834, DOI 10.17487/RFC3834, August
              2004, <https://www.rfc-editor.org/info/rfc3834>.

   [RFC4314]  Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
              RFC 4314, DOI 10.17487/RFC4314, December 2005,
              <https://www.rfc-editor.org/info/rfc4314>.

   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422,
              DOI 10.17487/RFC4422, June 2006,
              <https://www.rfc-editor.org/info/rfc4422>.

   [RFC4616]  Zeilenga, K., Ed., "The PLAIN Simple Authentication and
              Security Layer (SASL) Mechanism", RFC 4616,
              DOI 10.17487/RFC4616, August 2006,
              <https://www.rfc-editor.org/info/rfc4616>.

   [RFC4865]  White, G. and G. Vaudreuil, "SMTP Submission Service
              Extension for Future Message Release", RFC 4865,
              DOI 10.17487/RFC4865, May 2007,
              <https://www.rfc-editor.org/info/rfc4865>.
Top   ToC   RFC8621 - Page 106
   [RFC4954]  Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
              Extension for Authentication", RFC 4954,
              DOI 10.17487/RFC4954, July 2007,
              <https://www.rfc-editor.org/info/rfc4954>.

   [RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
              Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
              <https://www.rfc-editor.org/info/rfc5198>.

   [RFC5248]  Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
              Mail System Status Codes", BCP 138, RFC 5248,
              DOI 10.17487/RFC5248, June 2008,
              <https://www.rfc-editor.org/info/rfc5248>.

   [RFC5256]  Crispin, M. and K. Murchison, "Internet Message Access
              Protocol - SORT and THREAD Extensions", RFC 5256,
              DOI 10.17487/RFC5256, June 2008,
              <https://www.rfc-editor.org/info/rfc5256>.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <https://www.rfc-editor.org/info/rfc5321>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [RFC5788]  Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry",
              RFC 5788, DOI 10.17487/RFC5788, March 2010,
              <https://www.rfc-editor.org/info/rfc5788>.

   [RFC6154]  Leiba, B. and J. Nicolson, "IMAP LIST Extension for
              Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154,
              March 2011, <https://www.rfc-editor.org/info/rfc6154>.

   [RFC6409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
              STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
              <https://www.rfc-editor.org/info/rfc6409>.

   [RFC6532]  Yang, A., Steele, S., and N. Freed, "Internationalized
              Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
              2012, <https://www.rfc-editor.org/info/rfc6532>.

   [RFC6533]  Hansen, T., Ed., Newman, C., and A. Melnikov,
              "Internationalized Delivery Status and Disposition
              Notifications", RFC 6533, DOI 10.17487/RFC6533, February
              2012, <https://www.rfc-editor.org/info/rfc6533>.
Top   ToC   RFC8621 - Page 107
   [RFC6710]  Melnikov, A. and K. Carlberg, "Simple Mail Transfer
              Protocol Extension for Message Transfer Priorities",
              RFC 6710, DOI 10.17487/RFC6710, August 2012,
              <https://www.rfc-editor.org/info/rfc6710>.

   [RFC7677]  Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple
              Authentication and Security Layer (SASL) Mechanisms",
              RFC 7677, DOI 10.17487/RFC7677, November 2015,
              <https://www.rfc-editor.org/info/rfc7677>.

   [RFC8098]  Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition
              Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098,
              February 2017, <https://www.rfc-editor.org/info/rfc8098>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8314]  Moore, K. and C. Newman, "Cleartext Considered Obsolete:
              Use of Transport Layer Security (TLS) for Email Submission
              and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018,
              <https://www.rfc-editor.org/info/rfc8314>.

   [RFC8457]  Leiba, B., Ed., "IMAP "$Important" Keyword and
              "\Important" Special-Use Attribute", RFC 8457,
              DOI 10.17487/RFC8457, September 2018,
              <https://www.rfc-editor.org/info/rfc8457>.

   [RFC8474]  Gondwana, B., Ed., "IMAP Extension for Object
              Identifiers", RFC 8474, DOI 10.17487/RFC8474, September
              2018, <https://www.rfc-editor.org/info/rfc8474>.

   [RFC8620]  Jenkins, N. and C. Newman, "The JSON Meta Application
              Protocol", RFC 8620, DOI 10.17487/RFC8620, June 2019,
              <https://www.rfc-editor.org/info/rfc8620>.

11.2. Informative References

[EFAIL] Poddebniak, D., Dresen, C., Mueller, J., Ising, F., Schinzel, S., Friedberger, S., Somorovsky, J., and J. Schwenk, "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels", August 2018, <https://www.usenix.org/system/files/conference/ usenixsecurity18/sec18-poddebniak.pdf>. [milter] Postfix, "Postfix before-queue Milter support", 2019, <http://www.postfix.org/MILTER_README.html>.
Top   ToC   RFC8621 - Page 108
   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
              <https://www.rfc-editor.org/info/rfc3501>.

   [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
              Message Authentication, Reporting, and Conformance
              (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
              <https://www.rfc-editor.org/info/rfc7489>.

   [XCLIENT]  Postfix, "Postfix XCLIENT Howto", 2019,
              <http://www.postfix.org/XCLIENT_README.html>.

Authors' Addresses

Neil Jenkins Fastmail PO Box 234, Collins St. West Melbourne, VIC 8007 Australia Email: neilj@fastmailteam.com URI: https://www.fastmail.com Chris Newman Oracle 440 E. Huntington Dr., Suite 400 Arcadia, CA 91006 United States of America Email: chris.newman@oracle.com