class Net::IMAP

Net::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.

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 Net::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

Net::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 Net::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 Net::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

Net::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.

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 Net::IMAP::NoResponseError, Net::IMAP::BadResponseError, and Net::IMAP::ByeResponseError, all of which are subclasses of Net::IMAP::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 Net::IMAP::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 Net::IMAP::ResponseParseError is thrown if a server response is non-parseable.

What’s here?

Connection control methods

Server capabilities

Handling server responses

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: Net::IMAP doesn’t support IMAP4rev2 yet.

Any state

Not Authenticated state

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

Authenticated state

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

Selected state

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

Logout state

No IMAP commands are valid in the “logout” state. If the socket is still open, Net::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, Net::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

RFC2177: IDLE

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

RFC2342: NAMESPACE

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

RFC2971: ID

RFC3516: BINARY

The fetch side of BINARY has been folded into IMAP4rev2.

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

RFC3691: UNSELECT

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

RFC4314: ACL

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

RFC4315: UIDPLUS

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

RFC4731: ESEARCH

Folded into IMAP4rev2.

RFC4959: SASL-IR

Folded into IMAP4rev2.

RFC5161: ENABLE

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

RFC5256: SORT

RFC5256: THREAD

X-GM-EXT-1

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

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.

RFC6855: UTF8=ACCEPT, UTF8=ONLY

RFC7162: CONDSTORE

RFC8438: STATUS=SIZE

RFC8474: OBJECTID

RFC9394: PARTIAL

RFC9586: UIDONLY

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

For currently unsupported features: