Icon legend

These docs use a small set of inline term icons — one glyph per recurring domain word, plus one per shipped GUI client — so a reader scanning a page can spot where a mailbox, a frombox, a stamp, a pin, a domain, or the postmaster is being discussed, and which client a passage applies to, without re-reading the sentence. The set is deliberately small: a term joins it either by recurring widely across the book or by a deliberate editorial call to mark it wherever it appears — the frequency data below is the ranking behind the first route, and the paragraphs beside it are the record of the second. Both routes are kept narrow, so the icons stay meaningful rather than becoming decoration.

An author drops an icon in Markdown with a single inline <span> — mdBook renders inline HTML as-is:

<span class="ticon ticon-mailbox" role="img" aria-label="mailbox"></span>

The base ticon class sizes and aligns the glyph; the ticon-<term> modifier picks which one. Always include role="img" and an aria-label so screen readers announce the term.

Legend

Every icon, its modifier class, and what the term means. (The first column shows the glyph as it renders on this page — in the surrounding text color.)

The GUI clients

The four shipped end-user clients. These are drawn in the same monochrome line style as the rest of the set rather than as vendor logos: the icons render as CSS masks in the surrounding text color (see How it renders), so a brand mark would lose the very colors that make it a brand — and a filled logo silhouette would sit oddly beside fifteen stroked glyphs. Each is an original mark evoking the client, used to refer to that product.

Why these terms

Most of the domain terms were picked from how often each word actually appears across the book, so the icons buy the most scanning value. The table below counts distinct Markdown pages (out of the 66 content pages measured when the set was chosen) that mention each term; the count also scoped the book-wide application sweep that followed — the higher the count, the more pages that sweep touched.

That table is a dated snapshot, and it is frozen on purpose. Its figures were measured when the set was chosen, and they landed with this page on 2026-07-12, at docs v0.2.1, against the book as it stood that day — the denominator its header states. No row of it has been re-measured since, and none is re-measured here: the book has grown a long way past that denominator, so refreshing some rows and not others would leave a table mixing two of them, which states nothing. Read it as evidence from that date for how the core of the set was fixed, not as a count of the book you are reading now. Terms measured after it was taken are stated separately, against the book of their own day instead — which is why the campaign and beacon figures below carry a date and a docs version of their own. This dating was recorded on 2026-08-16 at docs v0.73.16 and moved no figure: the date was what was missing, not the measurement.

Frequency is a reason to admit a term, not the only one. A term carries an icon because it recurs widely enough across the book to be worth marking, or because admitting it was a deliberate editorial call — and the paragraphs below are the record of the calls. There is no page count that cleanly separates the icons from every other word: the table’s own bottom rows sit below a third of the 66 pages — POP and IMAP at 19, SOL at 17, daemon at 12 — and carry icons regardless. Read the table as the ranking that fixed the core of the set, not as the rule that admits each member of it. It is not the membership list either: stamp, pin and IPFS were all measured after it was taken, and all three clear a third of the book when re-measured — stamp and pin on 40 of today’s 106 pages each, IPFS in the note below.

The client icons are the largest of the deliberate admissions. They enter as a complete set of four, not on frequency: webmail (28 pages), Thunderbird (24) and Outlook (23) would each qualify on their own, but Chrome (10) would not. Admitting three of four would be worse than admitting none, because the icons answer “which clients does this apply to?” — and a client that is silently unmarked reads as excluded rather than merely less common. The set is closed at the four clients that ship; a fifth would join only by shipping.

campaign and beacon are deliberate admissions as well, and no frequency argument is being made for either. Both post-date the table, so their figures are a measurement of their own, taken on 2026-08-16 at docs v0.73.15: campaign appeared on 13 content pages and beacon on 10, out of the 106 the book then held. Reproduce either term from the repository root with grep -rlwi <term> mail_docs/src --include='*.md' --exclude=SUMMARY.md | wc -l, and the denominator with find mail_docs/src -name '*.md' ! -name SUMMARY.md | wc -l — SUMMARY.md is excluded from both because it is a table of contents rather than a content page, which is the convention every count on this page is stated in. The -w is what makes those numbers mean what they say: it matches whole words only, so beacon does not match beacons and POP does not match POP3. Like the table, that is a snapshot rather than a live tally, and like the table it is not why either term carries an icon — both figures sit an order below the terms the table ranks. They carry icons because marking them was judged worth it wherever they appear, which is a call, not a count; this paragraph is where that call is recorded.

IPFS joined later, and on frequency — not as one of those calls. It is absent from the table above only because the table is that one snapshot: re-measuring it against a book that has since grown to 106 Markdown pages would move every row, and a table mixing two denominators states nothing. Measured on its own with the same command, IPFS appears on 47 of those 106 pages (44%) — a third again past the one-third mark, and squarely inside the range the terms above occupy when they are re-measured the same way. The glyph is drawn on the same terms as the client icons: a line trace of the mark’s isometric-cube hexagon rather than the real logo, whose several tones would flatten to one under the mask, and without the logo’s inner ring of cubes, which closes into a smudge at inline size.

How it renders

The icons are not <img> elements. Each icon-*.svg is used as a CSS mask-image, and the masked shape is painted with background-color: currentColor. Because the glyph takes the surrounding text color, it adapts to the light and dark mdBook themes automatically, with no per-page markup. Each icon is sized to roughly 1em and sits on the text baseline, so it flows inline with the words around it.