Class: Net::IMAP

IMAP implements Internet Message Access Protocol (IMAP) client functionality. The protocol is described in IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051].

IMAP Overview

An IMAP client connects to a server, and then authenticates itself using either #authenticate or #login. Having authenticated itself, there is a range of commands available to it. Most work with mailboxes, which may be arranged in an hierarchical namespace, and each of which contains zero or more messages. How this is implemented on the server is implementation-dependent; on a UNIX server, it will frequently be implemented as files in mailbox format within a hierarchy of directories.

To work on the messages within a mailbox, the client must first select that mailbox, using either #select or #examine (for read-only access). Once the client has successfully selected a mailbox, they enter the selected state, and that mailbox becomes the current mailbox, on which mail-item related commands implicitly operate.

Connection state

Once an IMAP connection is established, the connection is in one of four states: not authenticated, authenticated, selected, and #logout. Most commands are valid only in certain states.

See #connection_state.

Sequence numbers and UIDs

Messages have two sorts of identifiers: message sequence numbers and UIDs.

Message sequence numbers number messages within a mailbox from 1 up to the number of items in the mailbox. If a new message arrives during a session, it receives a sequence number equal to the new size of the mailbox. If messages are expunged from the mailbox, remaining messages have their sequence numbers “shuffled down” to fill the gaps.

To avoid sequence number race conditions, servers must not expunge messages when no command is in progress, nor when responding to #fetch, #store, or #search. Expunges may be sent during any other command, including #uid_fetch, #uid_store, and #uid_search. The #noop and #idle commands are both useful for this side-effect: they allow the server to send all mailbox updates, including expunges.

UIDs, on the other hand, are permanently guaranteed not to identify another message within the same mailbox, even if the existing message is deleted. UIDs are required to be assigned in ascending (but not necessarily sequential) order within a mailbox; this means that if a non-IMAP client rearranges the order of mail items within a mailbox, the UIDs have to be reassigned. An IMAP client thus cannot rearrange message orders.

Examples of Usage

List sender and subject of all recent messages in the default mailbox

imap = Net::IMAP.new('mail.example.com')
imap.authenticate('PLAIN', 'joe_user', 'joes_password')
imap.examine('INBOX')
imap.search(["RECENT"]).each do |message_id|
  envelope = imap.fetch(message_id, "ENVELOPE")[0].attr["ENVELOPE"]
  puts "#{envelope.from[0].name}: \t#{envelope.subject}"
end

Move all messages from April 2003 from “Mail/sent-mail” to “Mail/sent-apr03”

imap = Net::IMAP.new('mail.example.com')
imap.authenticate('PLAIN', 'joe_user', 'joes_password')
imap.select('Mail/sent-mail')
if not imap.list('Mail/', 'sent-apr03')
  imap.create('Mail/sent-apr03')
end
imap.search(["BEFORE", "30-Apr-2003", "SINCE", "1-Apr-2003"]).each do |message_id|
  imap.copy(message_id, "Mail/sent-apr03")
  imap.store(message_id, "+FLAGS", [:Deleted])
end
imap.expunge

Capabilities

Most IMAP methods do not currently modify their behaviour according to the server’s advertised #capabilities. Users of this class must check that the server is capable of extension commands or command arguments before sending them. Special care should be taken to follow the #capabilities requirements for #starttls, #login, and #authenticate.

See #capable?, #auth_capable?, #capabilities, #auth_mechanisms to discover server capabilities. For relevant capability requirements, see the documentation on each IMAP command.

imap = Net::IMAP.new("mail.example.com")
imap.capable?(:IMAP4rev1) or raise "Not an IMAP4rev1 server"
imap.capable?(:starttls)  or raise "Cannot start TLS"
imap.starttls

if imap.auth_capable?("PLAIN")
  imap.authenticate "PLAIN", username, password
elsif !imap.capability?("LOGINDISABLED")
  imap.login username, password
else
  raise "No acceptable authentication mechanisms"
end

# Support for "UTF8=ACCEPT" implies support for "ENABLE"
imap.enable :utf8 if imap.capable?("UTF8=ACCEPT")

namespaces  = imap.namespace if imap.capable?(:namespace)
mbox_prefix = namespaces&.personal&.first&.prefix || ""
mbox_delim  = namespaces&.personal&.first&.delim  || "/"
mbox_path   = prefix + %w[path to my mailbox].join(delim)
imap.create mbox_path

Basic IMAP4rev1 capabilities

IMAP4rev1 servers must advertise IMAP4rev1 in their capabilities list. IMAP4rev1 servers must implement the STARTTLS, AUTH=PLAIN, and LOGINDISABLED capabilities. See #starttls, #login, and #authenticate for the implications of these capabilities.

Caching CAPABILITY responses

IMAP automatically stores and discards capability data according to the the requirements and recommendations in IMAP4rev2 §6.1.1, §6.2, and §7.1. Use #capable?, #auth_capable?, or #capabilities to use this cache and avoid sending the #capability command unnecessarily.

The server may advertise its initial capabilities using the CAPABILITY ResponseCode in a PREAUTH or OK #greeting. When TLS has started (#starttls) and after authentication (#login or #authenticate), the server’s capabilities may change and cached capabilities are discarded. The server may send updated capabilities with an OK TaggedResponse to #login or #authenticate, and these will be cached by IMAP. But the TaggedResponse to #starttls MUST be ignored–it is sent before TLS starts and is unprotected.

When storing capability values to variables, be careful that they are discarded or reset appropriately, especially following #starttls.

Using IMAP4rev1 extensions

See the IANA IMAP4 capabilities registry for a list of all standard capabilities, and their reference RFCs.

IMAP4rev1 servers must not activate behavior that is incompatible with the base specification until an explicit client action invokes a capability, e.g. sending a command or command argument specific to that capability. Servers may send data with backward compatible behavior, such as response codes or mailbox attributes, at any time without client action.

Invoking capabilities which are unknown to IMAP may cause unexpected behavior and errors. For example, ResponseParseError is raised when unknown response syntax is received. Invoking commands or command parameters that are unsupported by the server may raise NoResponseError, BadResponseError, or cause other unexpected behavior.

Some capabilities must be explicitly activated using the #enable command. See #enable for details.

Thread Safety

IMAP supports concurrent threads. For example,

imap = Net::IMAP.new("imap.foo.net", "imap2")
imap.authenticate("scram-md5", "bar", "password")
imap.select("inbox")
fetch_thread = Thread.start { imap.fetch(1..-1, "UID") }
search_result = imap.search(["BODY", "hello"])
fetch_result = fetch_thread.value
imap.disconnect

This script invokes the FETCH command and the SEARCH command concurrently.

When running multiple commands, care must be taken to avoid ambiguity. For example, SEARCH responses are ambiguous about which command they are responding to, so search commands should not run simultaneously, unless the server supports ESEARCH [RFC4731] or IMAP4rev2. See RFC9051 §5.5 for other examples of command sequences which should not be pipelined.

Unbounded memory use

IMAP reads server responses in a separate receiver thread per client. Unhandled response data is saved to #responses, and response_handlers run inside the receiver thread. See the list of methods for handling server responses, below.

Because the receiver thread continuously reads and saves new responses, some scenarios must be careful to avoid unbounded memory use:

• Commands such as #list or #fetch can have an enormous number of responses.

• Commands such as #fetch can result in an enormous size per response.

• Long-lived connections will gradually accumulate unsolicited server responses, especially EXISTS, FETCH, and EXPUNGE responses.

• A buggy or untrusted server could send inappropriate responses, which could be very numerous, very large, and very rapid.

Use paginated or limited versions of commands whenever possible.

Use Config#max_response_size to impose a limit on incoming server responses as they are being read. This is especially important for untrusted servers.

Use #add_response_handler to handle responses after each one is received. Use the #response_handlers argument to .new to assign response handlers before the receiver thread is started. Use #extract_responses, #clear_responses, or #responses (with a block) to prune responses.

Errors

An IMAP server can send three different types of responses to indicate failure:

NO

the attempted command could not be successfully completed. For instance, the username/password used for logging in are incorrect; the selected mailbox does not exist; etc.

BAD

the request from the client does not follow the server’s understanding of the IMAP protocol. This includes attempting commands from the wrong client state; for instance, attempting to perform a SEARCH command without having SELECTed a current mailbox. It can also signal an internal server failure (such as a disk crash) has occurred.

BYE

the server is saying goodbye. This can be part of a normal logout sequence, and can be used as part of a login sequence to indicate that the server is (for some reason) unwilling to accept your connection. As a response to any other command, it indicates either that the server is shutting down, or that the server is timing out the client connection due to inactivity.

These three error response are represented by the errors NoResponseError, BadResponseError, and ByeResponseError, all of which are subclasses of ResponseError. Essentially, all methods that involve sending a request to the server can generate one of these errors. Only the most pertinent instances have been documented below.

Because the IMAP class uses Sockets for communication, its methods are also susceptible to the various errors that can occur when working with sockets. These are generally represented as Errno errors. For instance, any method that involves sending a request to the server and/or receiving a response from it could raise an Errno::EPIPE error if the network connection unexpectedly goes down. See the socket(7), ip(7), tcp(7), socket(2), connect(2), and associated man pages.

Finally, a DataFormatError is thrown if low-level data is found to be in an incorrect format (for instance, when converting between UTF-8 and UTF-16), and ResponseParseError is thrown if a server response is non-parseable.

What’s here?

• Connection control

• Server capabilities

• Handling server responses

• Core IMAP commands

  • for any state

  • for the “not authenticated” state

  • for the “authenticated” state

  • for the “selected” state

  • for the “logout” state

• IMAP extension support

Connection control methods

• .new: Creates a new IMAP client which connects immediately and waits for a successful server greeting before the method returns.

• #connection_state: Returns the connection state.

• #starttls: Asks the server to upgrade a clear-text connection to use TLS.

• #logout: Tells the server to end the session. Enters the #logout state.

• #disconnect: Disconnects the connection (without sending #logout first).

• #disconnected?: True if the connection has been closed.

Server capabilities

• #capable?: Returns whether the server supports a given capability.

• #capabilities: Returns the server’s capabilities as an array of strings.

• #auth_capable?: Returns whether the server advertises support for a given SASL mechanism, for use with #authenticate.

• #auth_mechanisms: Returns the #authenticate SASL mechanisms which the server claims to support as an array of strings.

• #clear_cached_capabilities: Clears cached capabilities.

  The capabilities cache is automatically cleared after completing #starttls, #login, or #authenticate.

• #capability: Sends the CAPABILITY command and returns the #capabilities.

  In general, #capable? should be used rather than explicitly sending a CAPABILITY command to the server.

Handling server responses

• #greeting: The server’s initial untagged response, which can indicate a pre-authenticated connection.

• #responses: Yields unhandled UntaggedResponse#data and non-nil ResponseCode#data.

• #extract_responses: Removes and returns the responses for which the block returns a true value.

• #clear_responses: Deletes unhandled data from #responses and returns it.

• #add_response_handler: Add a block to be called inside the receiver thread with every server response.

• #response_handlers: Returns the list of response handlers.

• #remove_response_handler: Remove a previously added response handler.

Core IMAP commands

The following commands are defined either by the [IMAP4rev1] base specification, or by one of the following extensions: [IDLE], [NAMESPACE], [UNSELECT], [ENABLE], [MOVE]. These extensions are widely supported by modern IMAP4rev1 servers and have all been integrated into [IMAP4rev2]. NOTE: IMAP doesn’t support IMAP4rev2 yet.

Any state

• #capability: Returns the server’s capabilities as an array of strings.

  In general, #capable? should be used rather than explicitly sending a CAPABILITY command to the server.

• #noop: Allows the server to send unsolicited untagged #responses.

• #logout: Tells the server to end the session. Enters the #logout state.

Not Authenticated state

In addition to the commands for any state, the following commands are valid in the not_authenticated state:

• #starttls: Upgrades a clear-text connection to use TLS.

  Requires the STARTTLS capability.

• #authenticate: Identifies the client to the server using the given SASL mechanism and credentials. Enters the authenticated state.

  The server should list "AUTH=#{mechanism}" capabilities for supported mechanisms.

• #login: Identifies the client to the server using a plain text password. Using #authenticate is preferred. Enters the authenticated state.

  The LOGINDISABLED capability must NOT be listed.

Authenticated state

In addition to the commands for any state, the following commands are valid in the authenticated state:

• #enable: Enables backwards incompatible server extensions. Requires the ENABLE or IMAP4rev2 capability.

• #select: Open a mailbox and enter the selected state.

• #examine: Open a mailbox read-only, and enter the selected state.

• #create: Creates a new mailbox.

• #delete: Permanently remove a mailbox.

• #rename: Change the name of a mailbox.

• #subscribe: Adds a mailbox to the “subscribed” set.

• #unsubscribe: Removes a mailbox from the “subscribed” set.

• #list: Returns names and attributes of mailboxes matching a given pattern.

• #namespace: Returns mailbox namespaces, with path prefixes and delimiters. Requires the NAMESPACE or IMAP4rev2 capability.

• #status: Returns mailbox information, e.g. message count, unseen message count, UIDVALIDITY and UIDNEXT.

• #append: Appends a message to the end of a mailbox.

• #idle: Allows the server to send updates to the client, without the client needing to poll using #noop. Requires the IDLE or IMAP4rev2 capability.

• Obsolete #lsub: Replaced by LIST-EXTENDED and removed from IMAP4rev2. Lists mailboxes in the “subscribed” set.

  Note: Net::IMAP hasn’t implemented LIST-EXTENDED yet.

Selected state

In addition to the commands for any state and the authenticated commands, the following commands are valid in the selected state:

• #close: Closes the mailbox and returns to the authenticated state, expunging deleted messages, unless the mailbox was opened as read-only.

• #unselect: Closes the mailbox and returns to the authenticated state, without expunging any messages. Requires the UNSELECT or IMAP4rev2 capability.

• #expunge: Permanently removes messages which have the Deleted flag set.

• #uid_expunge: Restricts expunge to only remove the specified UIDs. Requires the UIDPLUS or IMAP4rev2 capability.

• #search, #uid_search: Returns sequence numbers or UIDs of messages that match the given searching criteria.

• #fetch, #uid_fetch: Returns data associated with a set of messages, specified by sequence number or UID.

• #store, #uid_store: Alters a message’s flags.

• #copy, #uid_copy: Copies the specified messages to the end of the specified destination mailbox.

• #move, #uid_move: Moves the specified messages to the end of the specified destination mailbox, expunging them from the current mailbox. Requires the MOVE or IMAP4rev2 capability.

• #check: Obsolete: removed from IMAP4rev2. Can be replaced with #noop or #idle.

Logout state

No IMAP commands are valid in the #logout state. If the socket is still open, IMAP will close it after receiving server confirmation. Exceptions will be raised by IMAP commands that have already started and are waiting for a response, as well as any that are called after logout.

IMAP extension support

RFC9051: IMAP4rev2

Although IMAP4rev2 is not supported yet, IMAP supports several extensions that have been folded into it: ENABLE, IDLE, MOVE, NAMESPACE, SASL-IR, UIDPLUS, UNSELECT, STATUS=SIZE, and the fetch side of BINARY. Commands for these extensions are listed with the Core IMAP commands, above.

The following are folded into IMAP4rev2 but are currently unsupported or incompletely supported by Net::IMAP: RFC4466 extensions, SEARCHRES, LIST-EXTENDED, LIST-STATUS, LITERAL-, and SPECIAL-USE.

RFC2087: QUOTA

• #getquota: returns the resource usage and limits for a quota root

• #getquotaroot: returns the list of quota roots for a mailbox, as well as their resource usage and limits.

• #setquota: sets the resource limits for a given quota root.

RFC2177: IDLE

Folded into IMAP4rev2 and also included above with Core IMAP commands.

• #idle: Allows the server to send updates to the client, without the client needing to poll using #noop.

RFC2342: NAMESPACE

Folded into IMAP4rev2 and also included above with Core IMAP commands.

• #namespace: Returns mailbox namespaces, with path prefixes and delimiters.

RFC2971: ID

• #id: exchanges client and server implementation information.

RFC3516: BINARY

The fetch side of BINARY has been folded into IMAP4rev2.

• Updates #fetch and #uid_fetch with the BINARY, BINARY.PEEK, and BINARY.SIZE items. See FetchData#binary and FetchData#binary_size.

NOTE: The binary extension the #append command is not supported yet.

RFC3691: UNSELECT

Folded into IMAP4rev2 and also included above with Core IMAP commands.

• #unselect: Closes the mailbox and returns to the authenticated state, without expunging any messages.

RFC4314: ACL

• #getacl: lists the authenticated user’s access rights to a mailbox.

• #setacl: sets the access rights for a user on a mailbox

NOTE: DELETEACL, LISTRIGHTS, and MYRIGHTS are not supported yet.

RFC4315: UIDPLUS

Folded into IMAP4rev2 and also included above with Core IMAP commands.

• #uid_expunge: Restricts #expunge to only remove the specified UIDs.

• Updates #select, #examine with the UIDNOTSTICKY ResponseCode

• Updates #append with the APPENDUID ResponseCode

• Updates #copy, #move with the COPYUID ResponseCode

RFC4731: ESEARCH

Folded into IMAP4rev2.

• Updates #search, #uid_search with return options and ESearchResult.

RFC4959: SASL-IR

Folded into IMAP4rev2.

• Updates #authenticate with the option to send an initial response.

RFC5161: ENABLE

Folded into IMAP4rev2 and also included above with Core IMAP commands.

• #enable: Enables backwards incompatible server extensions.

RFC5256: SORT

• #sort, #uid_sort: An alternate version of #search or #uid_search which sorts the results by specified keys.

RFC5256: THREAD

• #thread, #uid_thread: An alternate version of #search or #uid_search, which arranges the results into ordered groups or threads according to a chosen algorithm.

X-GM-EXT-1

X-GM-EXT-1 is a non-standard Gmail extension. See Google’s documentation.

• Updates #fetch and #uid_fetch with support for X-GM-MSGID (unique message ID), X-GM-THRID (thread ID), and X-GM-LABELS (Gmail labels).

• Updates #search with the X-GM-RAW search attribute.

• #xlist: replaced by SPECIAL-USE attributes in #list responses.

NOTE: The OBJECTID extension should replace X-GM-MSGID and X-GM-THRID, but Gmail does not support it (as of 2023-11-10).

RFC6851: MOVE

Folded into IMAP4rev2 and also included above with Core IMAP commands.

• #move, #uid_move: Moves the specified messages to the end of the specified destination mailbox, expunging them from the current mailbox.

RFC6855: UTF8=ACCEPT, UTF8=ONLY

• See #enable for information about support for UTF-8 string encoding.

RFC7162: CONDSTORE

• Updates #enable with CONDSTORE parameter. CONDSTORE will also be enabled by using any of the extension’s command parameters, listed below.

• Updates #status with the HIGHESTMODSEQ status attribute.

• Updates #select and #examine with the condstore modifier, and adds either a HIGHESTMODSEQ or NOMODSEQ ResponseCode to the responses.

• Updates #search, #uid_search, #sort, and #uid_sort with the MODSEQ search criterion, and adds SearchResult#modseq to the search response.

• Updates #thread and #uid_thread with the MODSEQ search criterion (but thread responses are unchanged).

• Updates #fetch and #uid_fetch with the changedsince modifier and MODSEQ FetchData attribute.

• Updates #store and #uid_store with the unchangedsince modifier and adds the MODIFIED ResponseCode to the tagged response.

RFC8438: STATUS=SIZE

• Updates #status with the SIZE status attribute.

RFC8474: OBJECTID

• Adds MAILBOXID ResponseCode to #create tagged response.

• Adds MAILBOXID ResponseCode to #select and #examine untagged response.

• Updates #fetch and #uid_fetch with the EMAILID and THREADID items. See FetchData#emailid and FetchData#emailid.

• Updates #status with support for the MAILBOXID status attribute.

RFC9394: PARTIAL

• Updates #search, #uid_search with the PARTIAL return option which adds ESearchResult#partial return data.

• Updates #uid_fetch with the partial modifier.

RFC9586: UIDONLY

• Updates #enable with UIDONLY parameter.

• Updates #uid_fetch and #uid_store to return UIDFETCH response.

• Updates #expunge and #uid_expunge to return VANISHED response.

• Prohibits use of message sequence numbers in responses or requests.

References

[IMAP4rev1]

Crispin, M., “INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1”, RFC 3501, DOI 10.17487/RFC3501, March 2003, <www.rfc-editor.org/info/rfc3501>.

[IMAP-ABNF-EXT]

Melnikov, A. and C. Daboo, “Collected Extensions to IMAP4 ABNF”, RFC 4466, DOI 10.17487/RFC4466, April 2006, <www.rfc-editor.org/info/rfc4466>.

Note: Net::IMAP cannot parse the entire RFC4466 grammar yet.

[IMAP4rev2]

Melnikov, A., Ed., and B. Leiba, Ed., “Internet Message Access Protocol (IMAP) - Version 4rev2”, RFC 9051, DOI 10.17487/RFC9051, August 2021, <www.rfc-editor.org/info/rfc9051>.

Note: Net::IMAP is not fully compatible with IMAP4rev2 yet.

[IMAP-IMPLEMENTATION]

Leiba, B., “IMAP4 Implementation Recommendations”, RFC 2683, DOI 10.17487/RFC2683, September 1999, <www.rfc-editor.org/info/rfc2683>.

[IMAP-MULTIACCESS]

Gahrns, M., “IMAP4 Multi-Accessed Mailbox Practice”, RFC 2180, DOI 10.17487/RFC2180, July 1997, <www.rfc-editor.org/info/rfc2180>.

[UTF7]

Goldsmith, D. and M. Davis, “UTF-7 A Mail-Safe Transformation Format of Unicode”, RFC 2152, DOI 10.17487/RFC2152, May 1997, <www.rfc-editor.org/info/rfc2152>.

Message envelope and body structure

[RFC5322]

Resnick, P., Ed., “Internet Message Format”, RFC 5322, DOI 10.17487/RFC5322, October 2008, <www.rfc-editor.org/info/rfc5322>.

Note: obsoletes RFC-2822 (April 2001) and RFC-822 (August 1982).

[CHARSET]

Freed, N. and J. Postel, “IANA Charset Registration Procedures”, BCP 19, RFC 2978, DOI 10.17487/RFC2978, October 2000, <www.rfc-editor.org/info/rfc2978>.

[DISPOSITION]

Troost, R., Dorner, S., and K. Moore, Ed., “Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field”, RFC 2183, DOI 10.17487/RFC2183, August 1997, <www.rfc-editor.org/info/rfc2183>.

[MIME-IMB]

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, <www.rfc-editor.org/info/rfc2045>.

[MIME-IMT]

Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types”, RFC 2046, DOI 10.17487/RFC2046, November 1996, <www.rfc-editor.org/info/rfc2046>.

[MIME-HDRS]

Moore, K., “MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text”, RFC 2047, DOI 10.17487/RFC2047, November 1996, <www.rfc-editor.org/info/rfc2047>.

[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, <www.rfc-editor.org/info/rfc2231>.

[I18n-HDRS]

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

[LANGUAGE-TAGS]

Alvestrand, H., “Content Language Headers”, RFC 3282, DOI 10.17487/RFC3282, May 2002, <www.rfc-editor.org/info/rfc3282>.

[LOCATION]

Palme, J., Hopmann, A., and N. Shelness, “MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)”, RFC 2557, DOI 10.17487/RFC2557, March 1999, <www.rfc-editor.org/info/rfc2557>.

[MD5]

Myers, J. and M. Rose, “The Content-MD5 Header Field”, RFC 1864, DOI 10.17487/RFC1864, October 1995, <www.rfc-editor.org/info/rfc1864>.

[RFC3503]

Melnikov, A., “Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP)”, RFC 3503, DOI 10.17487/RFC3503, March 2003, <www.rfc-editor.org/info/rfc3503>.

IMAP Extensions

[QUOTA]

Melnikov, A., “IMAP QUOTA Extension”, RFC 9208, DOI 10.17487/RFC9208, March 2022, <www.rfc-editor.org/info/rfc9208>.

Note: obsoletes RFC-2087 (January 1997). Net::IMAP does not fully support the RFC9208 updates yet.

[IDLE]

Leiba, B., “IMAP4 IDLE command”, RFC 2177, DOI 10.17487/RFC2177, June 1997, <www.rfc-editor.org/info/rfc2177>.

[NAMESPACE]

Gahrns, M. and C. Newman, “IMAP4 Namespace”, RFC 2342, DOI 10.17487/RFC2342, May 1998, <www.rfc-editor.org/info/rfc2342>.

[ID]

Showalter, T., “IMAP4 ID extension”, RFC 2971, DOI 10.17487/RFC2971, October 2000, <www.rfc-editor.org/info/rfc2971>.

[BINARY]

Nerenberg, L., “IMAP4 Binary Content Extension”, RFC 3516, DOI 10.17487/RFC3516, April 2003, <www.rfc-editor.org/info/rfc3516>.

[ACL]

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

[UIDPLUS]

Crispin, M., “Internet Message Access Protocol (IMAP) - UIDPLUS extension”, RFC 4315, DOI 10.17487/RFC4315, December 2005, <www.rfc-editor.org/info/rfc4315>.

[SORT]

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

[THREAD]

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

[RFC5530]

Gulbrandsen, A., “IMAP Response Codes”, RFC 5530, DOI 10.17487/RFC5530, May 2009, <www.rfc-editor.org/info/rfc5530>.

[MOVE]

Gulbrandsen, A. and N. Freed, Ed., “Internet Message Access Protocol (IMAP) - MOVE Extension”, RFC 6851, DOI 10.17487/RFC6851, January 2013, <www.rfc-editor.org/info/rfc6851>.

[UTF8=ACCEPT]

[UTF8=ONLY]

Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., “IMAP Support for UTF-8”, RFC 6855, DOI 10.17487/RFC6855, March 2013, <www.rfc-editor.org/info/rfc6855>.

[CONDSTORE]

[QRESYNC]

Melnikov, A. and D. Cridland, “IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)”, RFC 7162, DOI 10.17487/RFC7162, May 2014, <www.rfc-editor.org/info/rfc7162>.

[OBJECTID]

Gondwana, B., Ed., “IMAP Extension for Object Identifiers”, RFC 8474, DOI 10.17487/RFC8474, September 2018, <www.rfc-editor.org/info/rfc8474>.

[PARTIAL]

Melnikov, A., Achuthan, A., Nagulakonda, V., and L. Alves, “IMAP PARTIAL Extension for Paged SEARCH and FETCH”, RFC 9394, DOI 10.17487/RFC9394, June 2023, <www.rfc-editor.org/info/rfc9394>.

[UIDONLY]

Melnikov, A., Achuthan, A., Nagulakonda, V., Singh, A., and L. Alves, “IMAP Extension for Using and Returning Unique Identifiers (UIDs) Only”, RFC 9586, DOI 10.17487/RFC9586, May 2024, <www.rfc-editor.org/info/rfc9586>.

IANA registries

• IMAP Capabilities

• IMAP Response Codes

• IMAP Mailbox Name Attributes

• IMAP and JMAP Keywords

• IMAP Threading Algorithms

• {Net::IMAP::SASL Mechanisms and SASL SCRAM Family Mechanisms}

• Service Name and Transport Protocol Port Number Registry: imap: tcp/143, imaps: tcp/993

• GSSAPI/Kerberos/SASL Service Names: imap

• Character sets

For currently unsupported features:

• IMAP Quota Resource Types

• LIST-EXTENDED options and responses

• IMAP METADATA Server Entry and Mailbox Entry Registries

• IMAP ANNOTATE Extension Entries and Attributes

• IMAP URLAUTH Access Identifiers and Prefixes

• IMAP URLAUTH Authorization Mechanism Registry