Organising mail

Every change here is durable: the row moves at once and the daemon replays it to the server on its next pass. Offline changes queue.

Read, flag, delete

Key	Does
M	toggle read / unread
Shift+M	mark the whole listing read
Shift+F	toggle the flag (⚑)
D	move to trash

Shift+M marks the entire selected folder or search read, not just the visible rows. Opening a message marks it read.

Inside the trash folder, D deletes permanently, behind an explicit delete forever? y/n.

Archive

A sends the selected (or open) message to the account's archive folder. Change it from the default archive:

[account]
archive = "archive"

Move

Key	Does
C	open a folder picker
J / K, Enter	select, move
Esc	close

Or move by name (takes a folder alias, the real path, or inbox for the account root):

:move <folder>

The trash folder defaults to trash; change it per account:

[account]
trash = "trash"

Bulk actions

Four : commands act on every message the current search matches, not just the rows loaded into the view:

Command	Does
:archive-all	file every match to its account's archive folder
:trash-all	move every match to trash
:move-all <folder>	move every match to the named folder
:delete-all	delete every match permanently

<folder> takes the same names as :move: a folder alias, the real path, or inbox for the account root.

Nothing runs before a confirmation modal that states the exact count in its title and lists up to ten of the matched subjects (and N more beneath them), so what is about to happen is visible before it does. Y confirms; Esc or N cancels with nothing queued. Above a hundred matches the modal leads with a louder warning, since the sweep goes well beyond the visible list, and :delete-all always warns: it is permanent, cannot be undone, and unlike D it is not confined to the trash folder.

Confirming queues one durable op per message, the same ops as the single-message keys: the rows leave the listing at once and the daemon replays the changes to the servers on its next pass, offline included. A message present in two accounts is acted on in the account you are viewing (see below).

The natural rhythm is search, read the count, confirm. Archive an old newsletter in one pass:

/from:updates@example.com date:..2025
:archive-all

A search with no matches refuses with nothing matches this search. The query language does the aiming.

Delivery rules

Rules run in the daemon as mail arrives, first match wins:

[[rules]]
match_list = "~sircmpwn/aerc-devel"
move_to = "lists/aerc"

[[rules]]
match_sender = "billing@example.net"
tag = "invoices"

move_to files the message; tag adds a notmuch tag you can search and save. See accounts for the full rule shape.

Unsubscribe

:unsubscribe acts on the open message's List-Unsubscribe header:

• A one-click (RFC 8058) list asks for confirmation, then the daemon performs the POST off your machine.
• A mailto entry opens a prefilled compose.
• A web-only entry shows you the URL and touches nothing.

One message in two accounts

A message delivered to two synced accounts at once (sent from one, Bcc'd to another, say) is one search result with a copy under each account. Every action, bulk ones included, lands on the copy in the account you are viewing, and under the unified scope a received copy wins over a sent one, so archiving or deleting what you see never strands the copy on screen while acting on the other account's file.

Conflicts

The server wins. If a message you changed offline was deleted elsewhere first, the op is dropped and the log says so; a failed op never wedges the queue behind it.