Support for IMAP4rev2 and modern extensions

まず、このチェックリストにある未チェックのRFCエントリとリンクされたissue番号を確認し、次にスコープが定義された1つの機能を特定します。選択したIMAP機能が適切に実装または文書化され、そのチェックリスト項目と関連するissueのステータスが更新されれば完了です。

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
  • support all basic IMAP4rev1 commands
  • #50
  • #49
    several extensions require this. e.g. non-synchronizing literals
  • #48
  • #30
    this can be a client option, to preserve backwards compatibility
• #35
• RFC9051 (2021): IMAP4rev2
  • 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
    • 2. Folded in:
      • RFC2177 (1997): IDLE
      • #5 NAMESPACE
      • #41 FETCH BINARY
      • #40 UNSELECT
      • #36 UIDPLUS
      • #35 RFC4466 ABNF extensions
      • #44 ESEARCH
      • #34 SASL-IR
      • #42 SEARCHRES
      • #33 ENABLE
      • #43 LIST-EXTENDED
      • RFC5530 (2009): response codes (simply update documentation)
      • #45 LIST-STATUS
      • #108 SPECIAL-USE
      • RFC6851 (2013) MOVE
      • #37 LITERAL-
    • 3. Added STATUS SIZE RFC8438 and STATUS DELETED.
      These are both numeric status attributes and thus were already implicitly supported.
      #225 added explicit support and documented both.
    • 4. SEARCH command now requires to return the ESEARCH response (SEARCH response is now deprecated)
      #44
    • 7. Clarified that the COPYUID response code is returned for both MOVE and UID MOVE.
      #65
    • 14. For future extensibility, extended ABNF for tagged-ext-simple to allow for bare number64
      #35
    • 16. Mailbox names and message headers now allow for UTF-8. Support for modified UTF-7 in mailbox names is not required, unless compatibility with IMAP4rev1 is desired.
      #38
    • 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.)
    • 23. #110
    • 24. #109
    • #118
    • 26. Added warnings about use of ALERT response codes and PREAUTH response.
    • 27. Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256. DIGEST-MD5 was deprecated.
      • #54
  • Appendix F. Other Recommended IMAP Extensions
    • #106
    • #107
    • #39
• RFC3501's official "updated by" RFCs:
  • #35
  • RFC4469 (2006): CATENATE
  • RFC4551 (2006): obsoleted by RFC7162 (2014): CONDSTORE
  • RFC5032 (2007): WITHIN
  • #42
  • 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
  • RFC8437 (2018): UNAUTHENTICATE
  • #39

IANA registries

Registry	references
Capabilities	RFC3501
Mailbox attributes	RFC3501
SASL Mechanisms	RFC4422
LIST EXTENDED	RFC5258
Response codes	RFC5530
Keywords	RFC5788, RFC8621

Commonly supported extensions

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!

sorted by original RFC year

• RFC2087 (1997): QUOTA
• RFC2177 (1997): IDLE (included in IMAP4rev2)
• RFC2342 (1998): #5 NAMESPACE (included in IMAP4rev2)
• RFC2971 (2000): #4 ID
• RFC3348 (2002): CHILDREN
  • MailboxList predicate methods
• RFC3516 (2003): BINARY
  • #41
  • #535
• #40
• RFC4314 (2005): ACL
  • commands: GETACL, SETACL
  • response: ACL
  • commands: DELETEACL, LISTRIGHTS, MYRIGHTS
  • response: LISTRIGHTS, MYRIGHTS
• #36
  • it is possible to manually extract the raw COPYUID data
• #35
• RFC4616 (2006): AUTH=PLAIN
• RFC5256 (2008): SORT
• #44
• #34
• #46
• XOAUTH2 (2007): AUTH=XOAUTH2
• GMAILext (2007): X-GM-EXT-1
  • XLIST deprecated for SPECIAL-USE
  • 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.
• #33
• #42
• RFC5957 (2010): SORT=DISPLAY (only requires documentation)
• #43
• RFC5530 (2009): Response Codes (IANA registry) (included in IMAP4rev2)
• #38
• RFC5802 (2010): AUTH=SCRAM-*
  #54
• #45
• #108
  • Constants for the mailbox name attributes are added by #28
• RFC6851 (2013): MOVE (included in IMAP4rev2)
• #106 (obsoletes: RFC4551 2006)
• #107 (obsoletes: RFC5162 2008)
• #47
• #537
• #37
• RFC7889 (2016): APPENDLIMIT
• RFC8437 (2018): UNAUTHENTICATE
• 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.
• RFC8457 (2018): Keyword: $Important
  • n.b. Net::IMAP ignores keyword semantics, leaving that to the user. So "support" simply means that the attributes are parsed correctly.
• RFC8457 (2018): Special-use attribute: \Important
• #39
• RFC8970 (2020): PREVIEW, Message Preview Generation
• RFC9208 (2022): QUOTA (obsoletes RFC2087)
• RFC9394 (2023): PARTIAL, for Paged SEARCH and FETCH
  #367
• #366

Additional standard recommendations

• RFC2180 - IMAP4 Multi-Accessed Mailbox Practice
• RFC2595 - Using TLS with IMAP, POP3 and ACAP
• RFC2683 (1999): IMAP4 Implementation Recommendations
  • mailbox listing, heirarchy, delimiters, NAMESPACE, etc
  • mailbox "\Noselect", "\Noinferiors", "[TRYCREATE]", "[READ-ONLY]"
  • UIDs and UIDVALIDITY
  • FETCH (any order, extra information, unsolicited)
  • "Clients must present ALERT text clearly to the user."
• RFC4549 (2006): Synchronization Operations for Disconnected IMAP4 Clients
• RFC5550 (2009): The Internet Email to Support Diverse Service Environments (Lemonade) Profile
  • obsoletes: [RFC4550] (2006)
• RFC5598 (2009): Internet Email Architecture (Errata Exist)

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

• RFC2221 - LOGIN-REFERRALS
• RFC5032 - WITHIN
• RFC4469 - CATENATE
• RFC5256 - THREAD=ORDEREDSUBJECT
• RFC5267 - ESORT
• RFC5256 - THREAD=REFERENCES
• RFC5267 - CONTEXT=SEARCH
• RFC5267 - CONTEXT=SORT
• RFC5550 - URL-PARTIAL
• RFC5092 - imap:// URL Scheme
• RFC5593 - URL Access Identifier Extension

By my estimation, the following are currently supported by relatively few email addresses. They are sorted by RFC number.

• #536
• RFC4467 - URLAUTH
• RFC5255 - I18NLEVEL=1
• RFC5255 - I18NLEVEL=2
• RFC5255 - LANGUAGE
• RFC5257 - ANNOTATE-EXPERIMENT-1
• RFC5464 - METADATA
• RFC5464 - METADATA-SERVER
• RFC5465 - NOTIFY
• RFC5466 - FILTERS
• RFC5524 - URLFETCH
• RFC6154 - CREATE-SPECIAL-USE
• RFC6203 - SEARCH=FUZZY
• RFC6785 - IMAPSIEVE=
• RFC6785 - UTF8=ONLY
• RFC7377 - MULTISEARCH
• RFC8437 - UNAUTHENTICATE
• RFC8440 - LIST-MYRIGHTS
• RFC8508 - REPLACE
• RFC8514 - SAVEDATE

New 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)

• The JMAPACCESS Extension for IMAP
• IMAP MESSAGELIMIT Extension
• IMAP Paged SEARCH & FETCH Extension
• IMAP Extension for only using and returning UIDs

Deprecations?

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:

require "net/imap/sasl/cram-md5_authenticator"
require "net/imap/sasl/digest-md5_authenticator"
require "net/imap/sasl/login_authenticator"

• #55
• #62
  • LOGIN (only published as a draft. use AUTH PLAIN or LOGIN instead)
  • AUTH=CRAM-MD5
  • AUTH=DIGEST-MD5 - officially obsoleted by RFC6331 (2011)