Imap - Learning Module | OneNoughtOne

Loading content...

0/240

Folders and Flags

Organizing the Digital Mailbox

Email has become the backbone of professional and personal communication, with many users receiving hundreds of messages daily. Without robust organizational tools, the inbox becomes an overwhelming river of information where important messages drown in noise. IMAP addresses this challenge through two complementary mechanisms: folders (called mailboxes in IMAP terminology) for organizing messages by location, and flags for marking message states and attributes.

Unlike local file organization where you alone decide the structure, IMAP folders exist on the server—visible and synchronized across all your devices. Mark a message as 'Flagged' on your phone, and it appears starred on your desktop. Move an email to 'Receipts' from webmail, and your email client on your laptop sees it there too.

This page provides a deep exploration of IMAP's organizational capabilities: how folder hierarchies work, the standardized special-use folders that every email system should provide, the semantics of system and custom flags, and real-world patterns for effective email organization.

What You Will Learn

This page covers: mailbox hierarchy structure and naming, special-use folder designations (Sent, Drafts, Trash, Archive), system flags and their precise meanings, custom keywords for extended workflows, subscription management, and strategies for email organization that leverage IMAP's capabilities effectively.

Mailbox Hierarchy Deep Dive

IMAP organizes messages into mailboxes (what users call folders). These mailboxes form a hierarchical namespace, similar to a file system's directory structure, but with protocol-specific rules and behaviors.

Hierarchy Separators

Unlike file systems that universally use / (Unix) or \ (Windows), IMAP allows servers to define their own hierarchy separator character. Common separators include:

. (period) — Dovecot, Cyrus, many Unix servers
/ (slash) — Gmail, some enterprise servers
\ (backslash) — Rare, some Windows-based servers

Clients discover the separator using the LIST command:

a001 LIST "" ""
* LIST (\Noselect) "." ""
a001 OK LIST completed

The separator . means mailbox paths like Archive.2024.ProjectA.

Mailbox Listing and Hierarchy
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# List all mailboxes showing hierarchy
a001 LIST "" "*"
 
* LIST (\HasNoChildren) "." "INBOX"
* LIST (\HasNoChildren \Drafts) "." "Drafts"
* LIST (\HasNoChildren \Sent) "." "Sent"
* LIST (\HasNoChildren \Trash) "." "Trash"
* LIST (\HasNoChildren \Junk) "." "Junk"
* LIST (\HasChildren) "." "Archive"
* LIST (\HasNoChildren) "." "Archive.2022"
* LIST (\HasNoChildren) "." "Archive.2023"
* LIST (\HasNoChildren) "." "Archive.2024"
* LIST (\HasChildren) "." "Projects"
* LIST (\HasNoChildren) "." "Projects.AlphaRelease"
* LIST (\HasNoChildren) "." "Projects.BetaTesting"
* LIST (\HasChildren) "." "Projects.ClientWork"
* LIST (\HasNoChildren) "." "Projects.ClientWork.ClientA"
* LIST (\HasNoChildren) "." "Projects.ClientWork.ClientB"
a001 OK LIST completed
 
# Visualization of this hierarchy:
#
# INBOX
# Drafts (\Drafts)
# Sent (\Sent)
# Trash (\Trash)
# Junk (\Junk)
# Archive
# ├── 2022
# ├── 2023
# └── 2024
# Projects
# ├── AlphaRelease
# ├── BetaTesting
# └── ClientWork
#     ├── ClientA
#     └── ClientB

Mailbox Attributes

Each mailbox in the LIST response includes attributes describing its properties:

Standard Mailbox Attributes

•\Noselect — Mailbox cannot be selected (it's a folder that only contains other mailboxes, like a directory that can't contain files)
•\Noinferiors — Mailbox cannot have child mailboxes (leaf node only)
•\HasChildren — Mailbox has child mailboxes beneath it
•\HasNoChildren — Mailbox has no children
•\Marked — Server considers this mailbox 'interesting' (usually has new messages)
•\Unmarked — No interesting status for this mailbox
•\NonExistent — Mailbox doesn't exist but is listed because it has children

Namespace Prefixes

Many servers organize mailboxes into namespaces, revealed by the NAMESPACE command:

a001 NAMESPACE
* NAMESPACE (("" ".")) (("#shared." ".")) (("#public." "."))
a001 OK NAMESPACE completed

This shows three namespaces:

Personal namespace ("") — User's own mailboxes
Other users' namespace (#shared.) — Mailboxes shared by other users
Shared namespace (#public.) — Organization-wide public folders

Mailbox Name Encoding

IMAP uses a modified UTF-7 encoding for mailbox names to support international characters. The folder 'Café Orders' would be encoded as 'Caf&AOk-_Orders'. Most email clients handle this automatically, but if you're debugging IMAP sessions or writing tools, be aware of this encoding requirement.

Special-Use Folders

Every email system needs certain standard folders: a place for drafts, for sent messages, for trash. But what should these folders be named? 'Sent' or 'Sent Items' or 'Sent Messages'? Different email systems historically used different names, causing interoperability problems.

The SPECIAL-USE extension (RFC 6154) solves this by assigning semantic attributes to folders, regardless of their display names. A folder can be named 'Envoyés' in French but carry the \Sent attribute that clients recognize.

Standard Special-Use Attributes
Attribute	Purpose	Typical Names
\All	Contains all user messages (virtual folder)	All Mail, All Messages
\Archive	Long-term storage of completed messages	Archive, Archives
\Drafts	Messages being composed but not yet sent	Drafts, Draft
\Flagged	Messages marked as important (virtual)	Starred, Flagged
\Important	Messages determined to be important	Important, Priority
\Junk	Spam or junk messages	Junk, Spam, Junk Email
\Sent	Copies of sent messages	Sent, Sent Items, Sent Mail
\Trash	Deleted messages awaiting permanent deletion	Trash, Deleted Items, Bin

Special-Use Folder Discovery
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# Check if server supports SPECIAL-USE
a001 CAPABILITY
* CAPABILITY IMAP4rev1 ... SPECIAL-USE ...
a001 OK CAPABILITY completed
 
# List mailboxes with special-use attributes
a001 LIST "" "*" RETURN (SPECIAL-USE)
 
* LIST (\HasNoChildren) "." "INBOX"
* LIST (\HasNoChildren \Drafts) "." "Drafts"
* LIST (\HasNoChildren \Sent) "." "Sent"
* LIST (\HasNoChildren \Trash) "." "Trash"
* LIST (\HasNoChildren \Junk) "." "Spam"
* LIST (\HasNoChildren \Archive) "." "Archive"
a001 OK LIST completed
 
# Gmail's special-use folders
a001 LIST "" "*"
* LIST (\HasNoChildren \All) "/" "[Gmail]/All Mail"
* LIST (\HasNoChildren \Drafts) "/" "[Gmail]/Drafts"
* LIST (\HasNoChildren \Important) "/" "[Gmail]/Important"
* LIST (\HasNoChildren \Sent) "/" "[Gmail]/Sent Mail"
* LIST (\HasNoChildren \Junk) "/" "[Gmail]/Spam"
* LIST (\HasNoChildren \Flagged) "/" "[Gmail]/Starred"
* LIST (\HasNoChildren \Trash) "/" "[Gmail]/Trash"
 
# Creating a folder with special-use attribute
a001 CREATE "Archives" (USE (\Archive))
a001 OK CREATE completed

How Email Clients Use Special-Use

When you click 'Send' in your email client, the client needs to know where to save the sent copy. Without special-use:

Look for a folder named 'Sent'
Try 'Sent Items', 'Sent Messages'
Prompt user to configure Sent folder
Possibly create a new 'Sent' folder

With special-use:

LIST with RETURN (SPECIAL-USE)
Find folder with \Sent attribute
Save message there, regardless of folder name

This works seamlessly across languages and email providers.

Virtual vs. Physical Special Folders

Some special-use folders are 'virtual'—they don't physically store messages but show views of messages stored elsewhere. Gmail's 'All Mail' (\All) contains every message in the account and is virtual; messages actually reside in specific labels/folders. The 'Starred' (\Flagged) folder shows all messages with the \Flagged flag from any folder.

System Flags Semantics

IMAP defines a set of system flags—standard markers that track message status. Unlike folder organization (where messages are), flags describe message state (what's been done with them). Understanding flag semantics is essential for proper email client behavior.

The Standard System Flags:

\Seen — The Read Flag

•Meaning: Message content has been viewed by the user
•Set automatically: When message body is fetched via FETCH (not BODY.PEEK)
•Set manually: Client can explicitly STORE +FLAGS (\Seen) when user opens message
•Visual representation: Unread messages shown in bold, unread count in folder list
•Syncs across devices: Read on phone → marked read on desktop

\Answered — The Reply Flag

•Meaning: User has composed a reply to this message
•Set when: Client successfully sends a reply and stores the flag
•Visual representation: Reply arrow icon beside message
•Note: Forwarding typically doesn't set \Answered (some clients use $Forwarded keyword instead)

\Flagged — The Important Flag

•Meaning: User has marked this message as important or for follow-up
•Set by: User action (clicking star/flag icon)
•Visual representation: Star, flag, or pin icon; often color-coded
•Use cases: Follow-up reminders, priority marking, quick reference

\Deleted — The Deletion Mark

•Meaning: Message is marked for deletion, awaiting EXPUNGE
•Not actually deleted: Message remains until EXPUNGE command executes
•Recoverable: Remove \Deleted flag to 'undelete' before expunge
•Visual representation: Many clients hide \Deleted messages or show them struck-through
•Batch efficiency: Mark multiple messages, then EXPUNGE once

Flag Operations in Practice
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# When user opens email (client fetches body, auto-sets \Seen)
a001 FETCH 47 (BODY[TEXT])
* 47 FETCH (BODY[TEXT] {1234}... FLAGS (\Seen))
 
# To preview without marking as read, use BODY.PEEK
a001 FETCH 47 (BODY.PEEK[TEXT])
* 47 FETCH (BODY[TEXT] {1234}...)
# \Seen flag NOT set
 
# User clicks star button
a001 STORE 47 +FLAGS (\Flagged)
* 47 FETCH (FLAGS (\Seen \Flagged))
 
# User clicks reply, then sends reply successfully
a002 STORE 47 +FLAGS (\Answered)
* 47 FETCH (FLAGS (\Seen \Flagged \Answered))
 
# User deletes message (two-step process typically)
# Step 1: Move to Trash
a003 MOVE 47 "Trash"
* OK [COPYUID 1704067200 47 892] MOVE completed
 
# Later: Empty Trash (mark all as \Deleted, then EXPUNGE)
a004 SELECT "Trash"
a005 STORE 1:* +FLAGS (\Deleted)
a006 EXPUNGE
* 1 EXPUNGE
* 1 EXPUNGE
...
a006 OK EXPUNGE completed

\Deleted Is Not Deletion

A common source of confusion: setting \Deleted doesn't delete the message! It marks it for future deletion. Until EXPUNGE runs, the message is still there and can be recovered. Some clients auto-expunge on folder close (CLOSE command), others require explicit action. Users who 'delete' but never empty trash may find their quota filled with 'deleted' messages.

Draft and Recent Flags

Two additional system flags—\Draft and \Recent—have distinct semantics worth detailed exploration.

\Draft — Work in Progress

The \Draft flag indicates a message is still being composed and hasn't been sent yet.

\Draft Flag Behavior

•Set when: Message is APPENDed to Drafts folder during composition
•Storage location: Typically \Drafts special-use folder, though flag can be set on any message
•Draft lifecycle: Create → Auto-save periodically → Update draft → Send → Delete draft from Drafts folder
•Client behavior: Email clients periodically save current composition to Drafts via APPEND, replacing the previous draft
•Visual representation: Draft icon, editable message in Drafts folder

Draft Message Workflow
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# User starts composing email
# Client saves draft immediately
a001 APPEND "Drafts" (\Draft \Seen) {523}
+ OK
From: alice@example.com
To: bob@example.com
Subject: Project Update
Content-Type: text/plain
 
Draft content here...
a001 OK [APPENDUID 1704067200 901] APPEND completed
# Draft saved with UID 901
 
# User continues editing, client auto-saves every 60 seconds
# Delete old draft
a002 UID STORE 901 +FLAGS (\Deleted)
a003 UID EXPUNGE 901
 
# Save new version
a004 APPEND "Drafts" (\Draft \Seen) {1047}
+ OK
[Updated message content]
a004 OK [APPENDUID 1704067200 902] APPEND completed
 
# User finishes and sends
# After successful SMTP send:
a005 UID STORE 902 +FLAGS (\Deleted)
a006 UID EXPUNGE 902
# Draft is gone; sent copy saved to Sent folder

\Recent — Session Freshness Indicator

The \Recent flag has unique semantics—it's controlled entirely by the server and cannot be set by clients.

\Recent Rules:

Set by server when a message is first delivered to the mailbox
Cleared when any client SELECTs the mailbox
Only one session can see a message as \Recent
If you open your email on your phone, your desktop won't see those messages as \Recent later

Practical Implications:

\Recent is essentially 'new since someone last looked'
Not useful for synchronization (use UIDNEXT and MODSEQ instead)
The RECENT count in SELECT response shows how many \Recent messages exist
Most modern clients ignore \Recent in favor of more reliable mechanisms

\Recent Is Largely Obsolete

The \Recent flag was designed for an era when users had a single email client. With multi-device access, \Recent became unreliable—whichever device connected first would clear it. Modern clients use UIDNEXT (the next UID to be assigned) to determine new messages: any message with UID >= last known UIDNEXT is new. This works reliably regardless of which device checked first.

Custom Keywords

Beyond system flags, IMAP supports keywords—custom flags defined by users or applications. Keywords enable workflows and organizational schemes not possible with system flags alone.

Keyword Capabilities:

The server's PERMANENTFLAGS response indicates keyword support:

* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)]

The \* indicates the server accepts new keywords. Without \*, only system flags can be stored.

Common IMAP Keywords
Keyword	Purpose	Used By
$Forwarded	Message has been forwarded	Thunderbird, Apple Mail, most clients
$MDNSent	Read receipt was sent	Various clients
$SubmitPending	Message submission pending	Some clients
$Submitted	Message has been submitted	Some clients
$Junk	Manually marked as junk	SpamAssassin integration
$NotJunk	Marked as not junk (ham)	SpamAssassin integration
$Phishing	Suspected phishing message	Security tools

Working with Keywords
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# Check PERMANENTFLAGS to see allowed flags/keywords
a001 SELECT INBOX
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft $Forwarded $MDNSent)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft $Forwarded $MDNSent \*)]
...
 
# User forwards a message
a002 STORE 47 +FLAGS ($Forwarded)
* 47 FETCH (FLAGS (\Seen \Answered $Forwarded))
 
# Custom workflow: Mark for follow-up tomorrow
a003 STORE 47 +FLAGS ($FollowUp $Tomorrow)
* 47 FETCH (FLAGS (\Seen \Answered $Forwarded $FollowUp $Tomorrow))
 
# Search by keyword
a004 SEARCH KEYWORD $FollowUp
* SEARCH 47 89 156
 
# Remove workflow keyword when complete
a005 STORE 47 -FLAGS ($FollowUp $Tomorrow)
* 47 FETCH (FLAGS (\Seen \Answered $Forwarded))
 
# Gmail labels exposed as keywords
# Note: Gmail's implementation is unique
a001 SELECT "[Gmail]/All Mail"
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft work personal $Important)
# Custom labels appear as keywords in some contexts

Keyword Naming Conventions:

Keywords starting with $ are non-standard but commonly used
Keywords starting with \ are reserved for system flags
Keyword names are case-insensitive (though convention varies)
Some servers limit keyword count per mailbox or account

Use Cases for Custom Keywords:

Workflow tracking: $Todo, $InProgress, $Waiting, $Done
Priority levels: $HighPriority, $LowPriority
Project organization: $ProjectX, $ClientY (though folders may be better)
Action indicators: $NeedsReply, $ActionRequired, $ForReference
Processing status: $Processed, $Archived, $Reviewed

Keywords vs. Folders

Keywords and folders solve different problems. A message can have multiple keywords but exists in only one folder. Use keywords for cross-cutting attributes (priority, status, action required) and folders for categorical organization (by project, sender, topic). Effective email organization often combines both.

Subscription Management

As mailbox hierarchies grow, users may not want to see every folder in their client. IMAP's subscription mechanism lets users choose which folders appear in their folder list without deleting them.

How Subscription Works:

Each mailbox can be subscribed or unsubscribed. The subscription state is stored on the server, synchronized across devices. Clients can show only subscribed mailboxes (LSUB command) or all mailboxes (LIST command).

Subscription Commands
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# Subscribe to a mailbox
a001 SUBSCRIBE "Archive/2024"
a001 OK SUBSCRIBE completed
 
# Unsubscribe from a mailbox
a002 UNSUBSCRIBE "Archive/2020"
a002 OK UNSUBSCRIBE completed
 
# List only subscribed mailboxes
a003 LSUB "" "*"
* LSUB () "." "INBOX"
* LSUB () "." "Drafts"
* LSUB () "." "Sent"
* LSUB () "." "Trash"
* LSUB () "." "Archive"
* LSUB () "." "Archive.2023"
* LSUB () "." "Archive.2024"
* LSUB () "." "Projects"
a003 OK LSUB completed
 
# Compare with full LIST to see unsubscribed folders
a004 LIST "" "*"
# Shows all mailboxes including unsubscribed like Archive.2020, Archive.2021
 
# Modern alternative: LIST-EXTENDED with SUBSCRIBED
a005 LIST "" "*" RETURN (SUBSCRIBED)
* LIST (\HasNoChildren \Subscribed) "." "INBOX"
* LIST (\HasNoChildren \Subscribed \Drafts) "." "Drafts"
* LIST (\HasNoChildren) "." "Archive.2019"     # Not subscribed
* LIST (\HasNoChildren \Subscribed) "." "Archive.2024"  # Subscribed
...

Subscription Strategies:

Subscribe to active folders: Current year's archive, active projects, inbox
Unsubscribe old archives: Previous years you rarely access
Keep system folders subscribed: Drafts, Sent, Trash, Junk always visible
Shared folders: Subscribe only to shared folders you actively use

Auto-Subscription Behavior:

When creating new mailboxes:

Some servers auto-subscribe new mailboxes
Some require explicit subscription after creation
Client behavior varies—check if your client auto-subscribes on CREATE

a001 CREATE "Projects/NewProject"
a001 OK CREATE completed
a002 SUBSCRIBE "Projects/NewProject"
a002 OK SUBSCRIBE completed

Subscription Doesn't Affect Mail Delivery

Unsubscribing from a folder doesn't prevent messages from being delivered there (via server-side rules) or stored there. It only hides the folder from LSUB listings. A server rule can continue filing messages into an unsubscribed folder; you just won't easily see them in your client.

Email Organization Best Practices

With IMAP's folder and flag capabilities understood, let's examine practical strategies for effective email organization. The goal is a system that reduces inbox overload, ensures important messages don't get lost, and enables efficient retrieval.

Folder Hierarchy Patterns:

Recommended Folder Structures
# Pattern 1: Role-Based Organization
INBOX
├── Action Required        # Needs your response/action
├── Waiting For           # Waiting for someone else
├── Reference             # Information you might need later
├── Archive               # Completed items
│   ├── 2024
│   ├── 2023
│   └── 2022
└── [System folders: Drafts, Sent, Trash, Junk]
 
# Pattern 2: Project-Based Organization
INBOX
├── Projects
│   ├── ProjectA
│   ├── ProjectB
│   └── ClientWork
│       ├── ClientX
│       └── ClientY
├── Admin                 # HR, facilities, etc.
├── Subscriptions         # Newsletters, updates
└── Archive
 
# Pattern 3: GTD (Getting Things Done) Style
INBOX                     # Collect everything here
├── @Action              # Requires your action
├── @Waiting             # Delegated, waiting for response
├── @Someday             # Maybe later
├── @Reference           # Information filing
└── Archive
 
# Pattern 4: Hybrid (Projects + Status)
INBOX
├── Active Projects
│   ├── ProjectA
│   └── ProjectB
├── Action Required      # Cross-project urgent items
├── Clients
│   ├── ClientX
│   └── ClientY
├── Reference
│   ├── Policies
│   └── Procedures
├── Receipts             # Financial records
└── Archive/YYYY

Flag Usage Patterns:

Purpose	Approach	Why
Need to reply	\Flagged + keep in INBOX	High visibility until handled
Important reference	\Flagged + file to Reference	Flagged items easy to find via SEARCH FLAGGED
Read for later	Mark unread (remove \Seen)	Appears bold, counts as unread
Processed	\Seen + archive to folder	Cleared from INBOX view
In-progress response	\Draft in Drafts folder	Standard draft handling

Inbox Zero Strategy with IMAP

•Process regularly: Check INBOX several times daily, process each message to a decision
•Two-minute rule: If response takes <2 minutes, reply immediately, then archive
•Defer with flags: Need more time? \Flagged + keep in INBOX, or move to Action Required
•File decisively: Once actioned, archive immediately—don't let 'done' items clutter INBOX
•Use server rules: Auto-file newsletters, notifications, and low-priority mail to folders
•Periodic review: Weekly review flagged items and Action Required folder

Search Is Your Friend

Don't over-organize into too many folders—you'll spend more time filing than working. IMAP's SEARCH is powerful: 'SEARCH FROM alice SUBJECT report' finds messages instantly across folders. Maintain a simple structure and rely on search for precise retrieval. Many productive users have just INBOX, Archive, and system folders.

Summary: Folders and Flags

IMAP's folder and flag system provides a robust foundation for email organization that scales from individuals to enterprises. Let's consolidate the key insights:

Key Takeaways

•Mailboxes form a hierarchy — Using a server-specific separator character, folders can be nested to any depth, visible and synchronized across all devices.
•SPECIAL-USE attributes identify purpose — \Sent, \Drafts, \Trash, \Junk, \Archive let clients reliably identify standard folders regardless of their display names.
•System flags track message state — \Seen, \Answered, \Flagged, \Deleted, \Draft provide standardized status marking across all IMAP clients.
•\Deleted is a two-phase deletion — Mark for deletion, then EXPUNGE to permanently remove; this enables batch operations and recovery before final deletion.
•Keywords extend flags — Custom keywords like $Forwarded, $Todo enable workflows beyond system flags; check PERMANENTFLAGS for server support.
•Subscription controls visibility — Use SUBSCRIBE/UNSUBSCRIBE to manage which folders appear in your client without deleting them.
•Simple structures beat complex hierarchies — Rely on SEARCH for retrieval; over-organization wastes time.

What's Next:

The final page of this module provides a comprehensive comparison: IMAP vs POP3. We'll systematically examine the differences between these two protocols, when to use each, and why IMAP has become the dominant choice for modern email access.

Page Complete

You now understand IMAP's organizational mechanisms: hierarchical mailbox structures, special-use folder identification, system and custom flags, and subscription management. These tools enable effective email organization that synchronizes across all your devices, from folder structure to message states.