What this RFC defines
RFC 5256 defines two IMAP extensions: SORT and THREAD. SORT allows the server to return message UIDs 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. Server-side threading is also more accurate because the server has access to all headers.
How it connects to other RFCs
RFC 5256 extends RFC 9051 (IMAP). It builds on RFC 5322 (message format), which defines the In-Reply-To and References headers used to construct conversation threads. It works alongside RFC 2177 (IDLE) and RFC 4551 (CONDSTORE) as part of the IMAP extension ecosystem.
Current status
RFC 5256 is a current standard, published June 2008. SORT is supported by most major IMAP servers. THREAD support is less universal but available in Dovecot and Cyrus. Email clients that support server-side threading use RFC 5256 to offload the computation-intensive threading operation to the server.
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 standard used by every modern mail client 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 |
| Extension | RFC 5957 adds SORT=DISPLAY (locale-aware sorting) |
| Published | June 2008 |
SORT command usage
THREAD command usage
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 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?
Basic SORT sorts by Unicode codepoint (charset UTF-8 argument). This produces incorrect ordering for locale-sensitive text (accented characters, non-Latin scripts). RFC 5957 SORT=DISPLAY adds locale-aware collation. Check CAPABILITY for SORT=DISPLAY; if supported, prefer it for user-visible sorted lists. Servers without SORT=DISPLAY fall back to codepoint ordering, which may be acceptable for ASCII-heavy mailboxes but incorrect for international users.
Are SORT and THREAD still separate in IMAP4rev2?
Integrated in RFC 9051 (IMAP4rev2, 2021). No separate CAPABILITY advertisement needed for IMAP4rev2 servers; SORT and THREAD are part of the base protocol. RFC 5256 remains the reference for SORT/THREAD semantics on IMAP4rev1 servers, which remain dominant in 2026.
About 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.
