Current standard
What this RFC defines
RFC 5256 defines two IMAP extensions: SORT and THREAD. SORT allows the server to return message numbers (or UIDs, with UID SORT) sorted by specified criteria (date, subject, from, size, arrival) rather than sending all messages and letting the client sort locally. THREAD groups related messages into conversation trees server-side.
Where you see it in practice
When your email client displays messages grouped into conversation threads, sorted by date or sender, it may be using the server-side SORT and THREAD capabilities defined by RFC 5256. Without these extensions, the client must download all message headers and perform sorting and threading locally, which is expensive for large mailboxes. Not every server offers them: check the CAPABILITY response first.
SORT and THREAD extensions
RFC 5256 added the SORT and THREAD commands to IMAP. SORT lets a client request messages ordered by a specific field (date, subject, from, size) with the server doing the sort, rather than the client fetching all message headers and sorting locally. THREAD requests messages grouped into conversation threads using the References and In-Reply-To headers, or using the ORDEREDSUBJECT heuristic. Both commands significantly reduce the data a client needs to fetch to display a sorted or threaded inbox.
Threading algorithms
The RFC 5256 THREAD command supports two algorithms: ORDEREDSUBJECT (thread by matching normalized subject lines) and REFERENCES (thread by walking the References header chain). REFERENCES is the better choice when available because it correctly identifies threads even when subjects change (Re: Fw: Re: chains) and correctly separates unrelated conversations that happen to share a subject. ORDEREDSUBJECT is a simpler fallback for servers that cannot afford the compute cost of full References chain analysis.
Client-side alternatives
Some IMAP clients (particularly older or lightweight ones) implement sort and thread client-side by fetching all message envelopes and applying the algorithm locally. This works but is slow for large mailboxes and produces inconsistent behavior across devices. Server-side SORT and THREAD via RFC 5256 give consistent results for the same query regardless of which client is asking. If your IMAP client shows different sorted or threaded views on different devices, it is likely doing client-side sorting; enabling server-side sort in the client typically resolves this.
RFC 5256 (June 2008) defines two IMAP extensions: SORT (server-side message sorting by From, To, Subject, Date, Size, Cc) and THREAD (server-side conversation threading using ORDEREDSUBJECT or REFERENCES algorithm). Lets clients request sorted or threaded views without downloading all message headers to sort locally. Critical for large mailboxes; without SORT, clients must fetch all envelopes to render a sorted list. Advertised as SORT and THREAD=<algorithm> in CAPABILITY.
RFC 5256 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Server-side sorting and threading for IMAP mailboxes |
| SORT keys | ARRIVAL, CC, DATE, FROM, REVERSE, SIZE, SUBJECT, TO |
| THREAD algorithms | ORDEREDSUBJECT (subject-based) and REFERENCES (In-Reply-To/References header) |
| Advertised as | SORT, THREAD=ORDEREDSUBJECT, THREAD=REFERENCES |
| String comparison | Follows the I18NLEVEL rules of RFC 5255 (level 1 at minimum) |
| Extension | RFC 5957 adds SORT=DISPLAY: DISPLAYFROM and DISPLAYTO keys that sort on the display name rather than the address |
| IMAP4rev2 | Not part of RFC 9051; SORT and THREAD remain separate extensions |
| Published | June 2008 |
SORT command usage
Sort by Date, oldest first:
C: A001 SORT (DATE) UTF-8 ALL
S: * SORT 5 12 23 34 45 78 100
S: A001 OK SORT completed
(returns sequence numbers in sorted order)
Sort by Date descending (newest first):
C: A002 SORT (REVERSE DATE) UTF-8 ALL
S: * SORT 100 78 45 34 23 12 5
S: A002 OK SORT completed
Sort by Subject then Date (secondary key):
C: A003 SORT (SUBJECT DATE) UTF-8 ALL
Sort with search criteria:
C: A004 SORT (REVERSE DATE) UTF-8 UNSEEN
(returns unread messages sorted newest first)
Sort by size, largest first:
C: A005 SORT (REVERSE SIZE) UTF-8 ALL
The charset (UTF-8 above) declares how string values are interpreted
for FROM, TO, CC, SUBJECT keys. Modern usage: always UTF-8.
RFC 5957 SORT=DISPLAY adds DISPLAYFROM and DISPLAYTO keys, which sort
on the name shown to the user (“Alice Martin”) instead of the address:
C: A006 SORT (DISPLAYFROM) UTF-8 ALL
Use UID SORT to get UIDs instead of message sequence numbers:
C: A007 UID SORT (REVERSE ARRIVAL) UTF-8 ALL
THREAD command usage
Thread by REFERENCES (most accurate, uses In-Reply-To and References headers):
C: A001 THREAD REFERENCES UTF-8 ALL
S: * THREAD (5)(6 (7)(8))(9 10 11)
S: A001 OK THREAD completed
The response is a nested list where each parenthesized group is a thread:
(5) Message 5, standalone thread
(6 (7)(8)) Message 6 has replies 7 and 8
(9 10 11) Messages 9, 10, 11 form a chain (9 → 10 → 11)
Thread by ORDEREDSUBJECT (subject-based, simpler and less accurate):
C: A002 THREAD ORDEREDSUBJECT UTF-8 ALL
Groups messages by normalized subject (stripping Re:, Fwd:).
Less reliable than REFERENCES; used when message headers lack
In-Reply-To/References chains.
REFERENCES vs ORDEREDSUBJECT:
REFERENCES Uses header chain; accurate; slower to compute
ORDEREDSUBJECT Uses subject; fast; fooled by subject reuse
Modern clients prefer REFERENCES when available; fall back to
ORDEREDSUBJECT for legacy interoperability.
Common SORT/THREAD mistakes
SORT and THREAD=algorithm in CAPABILITY. Clients that assume support and fail gracelessly on unsupported servers produce poor user experience. Check CAPABILITY; fall back to client-side sorting if extensions are unavailable.Related standards and further reading
- RFC 3501: IMAP4rev1 (base protocol)
- RFC 9051: IMAP4rev2 (2021; does not include SORT or THREAD)
- RFC 5957: SORT=DISPLAY (sort by display name)
- RFC 5255: IMAP internationalization (I18NLEVEL comparators)
- RFC 7162: CONDSTORE and QRESYNC (replaces RFC 4551)
- RFC 2177: IDLE (real-time notifications)
- RFC 6851: MOVE (atomic message move)
- RFC 3501 IMAP Guide: base IMAP protocol
Frequently asked questions
Should I use SORT or sort client-side?
Server-side SORT when available. Advantages: reduced bandwidth (only sorted result IDs transferred, not full envelopes), faster rendering (no client-side sort needed), consistent across devices (all clients see same order for the same key). Fall back to client-side sort only when the server lacks SORT support. Check CAPABILITY for SORT; nearly all modern servers advertise it.
What is the difference between ORDEREDSUBJECT and REFERENCES threading?
REFERENCES uses the In-Reply-To and References headers to build accurate reply chains. Correctly threads conversations regardless of subject changes (“subject changed” replies). ORDEREDSUBJECT groups by normalized subject (stripping Re:, Fwd:). Fast but fooled by subject reuse (unrelated messages with the same subject get grouped). Modern usage: REFERENCES for accuracy; ORDEREDSUBJECT for legacy fallback.
Why do different devices show different sort orders?
Usually because at least one device uses client-side sorting with a different secondary key or different handling of ties. Fix: enable “server-side sort” in all clients so they all delegate to the server, guaranteeing consistent ordering. Alternatively, ensure all clients use the same client-side sort algorithm (identical primary and secondary keys, identical tiebreaking rules).
Does SORT support Unicode?
Yes. Clients pass a charset (UTF-8 in practice) and servers compare strings following the I18NLEVEL rules of RFC 5255, level 1 at minimum, which is Unicode-aware for case but not tailored to one language’s alphabet. Servers that advertise I18NLEVEL=2 can apply language-specific comparators. SORT=DISPLAY (RFC 5957) is a different feature: it sorts on display names instead of addresses.
Are SORT and THREAD still separate in IMAP4rev2?
Yes. RFC 9051 (IMAP4rev2, 2021) merged several extensions into the base protocol, such as IDLE, MOVE and NAMESPACE, but not SORT or THREAD. Servers still advertise them separately (SORT, THREAD=REFERENCES), and RFC 5256 remains their specification for both IMAP4rev1 and IMAP4rev2.
Did this guide save you time?
SMTPedia is free and independent. A coffee helps keep every guide accurate.
Buy SMTPedia a coffeeAbout the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.