You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a meta-ticket to track support for IMAP capabilities. I'm also listing capabilities that are already supported by Net::IMAP as well as extensions that are obsolete or unsupported by IMAP servers, so that (when completed) the list will be exhaustive. Later, we can copy the list of supported RFCs and extensions into the rdoc.
This list hasn't been carefully audited yet. Some unchecked items can probably be checked off without any extra effort. As tickets and PRs are created for various features, I'll update this list to include them.
Basic protocol specifications
RFC3501 (2003): Internet Message Access Protocol - version 4rev1
Appendix E: Changes since RFC3501 Only the relevant items are listed below. In some cases, all that we need do for Net::IMAP is add (or link to) documentation.
1. Support for 64-bit message and body part sizes. Net::IMAP doesn't validate number or number64 size, and thus automatically supports the larger 64-bit sizes
3. Added STATUS SIZE RFC8438 and STATUS DELETED. These are both numeric status attributes and thus were already implicitly supported. ⚡ Better Faster Cleaner STATUS parsing #225 added explicit support and documented both.
20. IDLE command can now return updates not related to the currently selected mailbox state. Not applicable: Net::IMAP does not interpret unsolicited responses, and leaves this up to the library users.
22. Clarified that client implementations MUST ignore response codes that they do not recognize. (Changed from a SHOULD to a MUST.)
RFC5738 (2010): obsoleted by RFC6855 (2013): UTF-8 support
RFC6186 (2011): SRV Records for Locating Email Services
updated by: RFC8314 (2018): Cleartext Obsolete: Use TLS for Email
updated by: [RFC8553] (2019): DNS AttrLeaf, fixing underscored node names
RFC6858 (2013): Simplified Downgrading for I18n Email
values simplicity of implementation over fidelity of representation, since implementing a high-fidelity downgrade algorithm... is likely more work than implementing proper UTF-8 support RFC6855.
RFC7817 (2016): Updated TLS Server Identity Check Procedure
RFC8314 (2018): Cleartext Obsolete: Use TLS for Email
This is not an exhaustive list of all extensions, but an opinionated selection of the most important extensions that Net::IMAP should support. It is partially based on CAPABILITY data for hundreds of thousands of IMAP4 accounts, and partially based on subjective judgement. Additionally, any RFCs we already support, even if only partially, have been promoted to this list. Some extension behaviors are out-of-scope for Net::IMAP, so "support" simply means parsing and adding the necessary documentation for users of net-imap to implement the extension bevavior. Please comment below if you think something should be promoted to this list!
X-GM-RAW, X-GM-MSGID, X-GM-THRID, X-GM-LABELS
n.b. GMail's non-standard extensions can almost be obsoleted by a combination of OBJECTID, SORT, THREAD, SEARCH=FUZZY, ESEARCH, ESORT, and AUTH=OAUTHBEARER. But GMail and other large email providers still haven't upgraded to use all of these new standards. Until such time as they are deprecated by GMail (and AUTH=XOAUTH2 is used by many providers), I think it's useful to add these to the standard library instead of installing a separate gem.
RFC8438 (2018): STATUS=SIZE(included in IMAP4rev2)
n.b. Net::IMAP imposes no restrictions on STATUS attributes and can parse any atom number extension in the response, so it automatically supports STATUS mbox (SIZE). It is the user's responsibility to check for the capability.
Some of these are easy to add, and many of them would be very useful. I placed them down here instead of prioritizing them above mostly due to a quick and unscientific sampling of email accounts and server capabilities.
We might want to remove obsolete authentication mechanisms from the default set of authenticators. For people who still need them, the code could be preserved in separate files, with explicit requires, e.g:
This is a meta-ticket to track support for IMAP capabilities. I'm also listing capabilities that are already supported by
Net::IMAPas well as extensions that are obsolete or unsupported by IMAP servers, so that (when completed) the list will be exhaustive. Later, we can copy the list of supported RFCs and extensions into the rdoc.This list hasn't been carefully audited yet. Some unchecked items can probably be checked off without any extra effort. As tickets and PRs are created for various features, I'll update this list to include them.
Basic protocol specifications
several extensions require this. e.g. non-synchronizing literals
AUTHENTICATEwithout matchingAUTH=#{mechanism}capability #48UTF-7should be automatically encoded/decoded #30this can be a client option, to preserve backwards compatibility
Only the relevant items are listed below. In some cases, all that we need do for Net::IMAP is add (or link to) documentation.
Net::IMAP doesn't validate number or number64 size, and thus automatically supports the larger 64-bit sizes
IDLERFC3516(2003):BINARYFETCHextensions (included inIMAP4rev2) #41 FETCH BINARYUNSELECT(included inIMAP4rev2) #40 UNSELECTRFC4315(2005):UIDPLUS(included inIMAP4rev2) #36 UIDPLUSESEARCH(included inIMAP4rev2) #44 ESEARCHSASL-IR(included inIMAP4rev2) #34 SASL-IRSEARCHRES(included inIMAP4rev2) #42 SEARCHRESENABLE(included inIMAP4rev2) #33 ENABLELIST-EXTENDED(mostly included inIMAP4rev2) #43 LIST-EXTENDEDLIST-STATUS(included inIMAP4rev2) #45 LIST-STATUSSPECIAL-USE(mailbox attributes are in IMAP4rev2) #108 SPECIAL-USEMOVELITERAL-(included inIMAP4rev2) #37 LITERAL-These are both numeric status attributes and thus were already implicitly supported.
⚡ Better Faster Cleaner
STATUSparsing #225 added explicit support and documented both.RFC4731 (2006):
ESEARCH(included inIMAP4rev2) #44Support
UIDPLUSextension #65RFC4466 (2006): Collected Extensions to IMAP4 ABNF #35
RFC6855(2013):UTF8=ACCEPT(recommended byIMAP4rev2for backward compatibility) #38Not applicable:
Net::IMAPdoes not interpret unsolicited responses, and leaves this up to the library users.OBJECTID(recommended by IMAP4rev2) #39CATENATECONDSTOREWITHINSEARCHRES(included inIMAP4rev2) #42UNAUTHENTICATEOBJECTID(recommended by IMAP4rev2) #39IANA registries
Commonly supported extensions
This is not an exhaustive list of all extensions, but an opinionated selection of the most important extensions that
Net::IMAPshould support. It is partially based onCAPABILITYdata for hundreds of thousands of IMAP4 accounts, and partially based on subjective judgement. Additionally, any RFCs we already support, even if only partially, have been promoted to this list. Some extension behaviors are out-of-scope forNet::IMAP, so "support" simply means parsing and adding the necessary documentation for users ofnet-imapto implement the extension bevavior. Please comment below if you think something should be promoted to this list!sorted by original RFC year
QUOTAIDLE(included inIMAP4rev2)NAMESPACE(included inIMAP4rev2)IDCHILDRENMailboxListpredicate methodsBINARYRFC3516(2003):BINARYFETCHextensions (included inIMAP4rev2) #41BINARYextension to#append(RFC3516, RFC4466) #535UNSELECT(included inIMAP4rev2) #40ACLRFC4315(2005):UIDPLUS(included inIMAP4rev2) #36COPYUIDdataAUTH=PLAINSORTESEARCH(included inIMAP4rev2) #44SASL-IR(included inIMAP4rev2) #34COMPRESS=DEFLATE#46AUTH=XOAUTH2X-GM-EXT-1XLISTX-GM-RAW,X-GM-MSGID,X-GM-THRID,X-GM-LABELSn.b. GMail's non-standard extensions can almost be obsoleted by a combination of
OBJECTID,SORT,THREAD,SEARCH=FUZZY,ESEARCH,ESORT, andAUTH=OAUTHBEARER. But GMail and other large email providers still haven't upgraded to use all of these new standards. Until such time as they are deprecated by GMail (andAUTH=XOAUTH2is used by many providers), I think it's useful to add these to the standard library instead of installing a separate gem.ENABLE(included inIMAP4rev2) #33SEARCHRES(included inIMAP4rev2) #42SORT=DISPLAY(only requires documentation)LIST-EXTENDED(mostly included inIMAP4rev2) #43IMAP4rev2)RFC6855(2013):UTF8=ACCEPT(recommended byIMAP4rev2for backward compatibility) #38AUTH=SCRAM-*SCRAM-SHA-1(-PLUS) + SCRAM-SHA-256(-PLUS) + SCRAM-SHA-512(-PLUS) + SCRAM-SHA3-512(-PLUS) supports #54
LIST-STATUS(included inIMAP4rev2) #45SPECIAL-USE(mailbox attributes are in IMAP4rev2) #108MOVE(included inIMAP4rev2)AUTH=OAUTHBEARER#47LITERAL+(obsoletes: RFC2088 1997) #537LITERAL-(included inIMAP4rev2) #37APPENDLIMITUNAUTHENTICATESTATUS=SIZE(included inIMAP4rev2)Net::IMAPimposes no restrictions onSTATUSattributes and can parse anyatom numberextension in the response, so it automatically supportsSTATUS mbox (SIZE). It is the user's responsibility to check for the capability.$Important\ImportantOBJECTID(recommended by IMAP4rev2) #39PREVIEW, Message Preview GenerationQUOTA(obsoletes RFC2087)PARTIAL, for Paged SEARCH and FETCH✨ Add support for
PARTIALextension (RFC9394) #367Additional standard recommendations
Other extensions
Some of these are easy to add, and many of them would be very useful. I placed them down here instead of prioritizing them above mostly due to a quick and unscientific sampling of email accounts and server capabilities.
sorted by estimated current server support
By my estimation, the following are currently supported by relatively few email addresses. They are sorted by RFC number.
MULTIAPPENDextension (also RFC4466) #536New specifications
Looking at recent standards and others that are still in draft form (as of 2021-10-19):
IETF "extra" WG (Email mailstore and eXtensions To Revise or Amend)
JMAPACCESSExtension for IMAPMESSAGELIMITExtensionDeprecations?
We might want to remove obsolete authentication mechanisms from the default set of authenticators. For people who still need them, the code could be preserved in separate files, with explicit
requires, e.g:LOGIN(only published as a draft. useAUTH PLAINorLOGINinstead)AUTH=CRAM-MD5AUTH=DIGEST-MD5- officially obsoleted by RFC6331 (2011)