RFC 8621
The JSON Meta Application Protocol (JMAP) for Mail
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:
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.
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.
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.
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.
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 910.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
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 910.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.
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
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
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
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
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: IESG10.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
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.
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.
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.
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.
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>.
[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>.
[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>.
[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>.
[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