[Feature]: Integrated IMAP server mode (read-only archive access)

[Setya17]

Is your feature request related to a problem?

Browsing large archives through the web UI becomes cumbersome for end users who are used to their regular mail client (Outlook, Thunderbird, Apple Mail, mobile). There is no way to access the archive from a familiar email client — every access requires logging into the web interface, which hurts adoption for non-technical users and makes offline / multi-device use awkward.

Describe the solution you'd like

Add a built-in, read-only IMAP server that exposes the archive to any standard IMAP client, alongside the existing web UI (not replacing it).
Scope for v1 — minimal read-only command set only: LOGIN, CAPABILITY, LIST, SELECT/EXAMINE, FETCH, LOGOUT, NOOP. No write operations whatsoever (APPEND, STORE, EXPUNGE, DELETE, etc.). SEARCH and more advanced commands could come in later iterations.
Benefits:

• Native UX — users browse the archive in the mail client they already know
• Offline access and multi-device support — the client handles caching
• Much better experience for large archives than paging through a browser
• Compliance-friendly — read-only guarantees the archive cannot be modified from the client side
• Offboarding / mailbox handover — a former employee's archive can be made available to their successor as a regular IMAP account

Additional context

This is a well-established enterprise pattern:

• MailStore Server — "Integrated IMAP Server"
• GFI Archiver — "IMAP Client Access"

On the open-source side, no actively maintained project currently offers this. Enkive used to, but has been abandoned for years. Implementing it would make Mail-Archiver a real differentiator in the self-hosted open-source email archiving space.
I have notes on the technical details (folder mapping, auth, TLS, UID stability, phased scope) and would be happy to share them in follow-up comments if there is interest in pursuing this.

[Setya17]

[Design Notes]: Integrated IMAP Server Mode (read-only)

Several of my clients and acquaintances have mentioned they would like to keep accessing their archived emails from their familiar Outlook client, typically over LAN — this feedback was the original motivation behind the request.

I'd be happy to contribute to the implementation under the coordination described in CONTRIBUTING.md, if we can align on the direction. Before any code is written, let me outline how I'm thinking about it — so we can work through the important decisions up front.

Scope

The bare minimum only, read-only. No write operations whatsoever. Goal: an average user running Thunderbird / Outlook / iPhone Mail can connect to their own archive and browse it.

Protocol subset

• CAPABILITY, LOGIN, LOGOUT, NOOP
• LIST, LSUB, STATUS
• SELECT / EXAMINE (both with read-only semantics)
• FETCH, UID FETCH — FLAGS, INTERNALDATE, RFC822.SIZE, ENVELOPE, BODY, BODYSTRUCTURE, BODY[HEADER], BODY[TEXT], BODY[], BODY.PEEK[...]
• UID SEARCH — at least ALL, SINCE, BEFORE, FROM, TO, SUBJECT
• CLOSE

Explicitly out of scope: APPEND, STORE, EXPUNGE, DELETE, RENAME, CREATE, COPY, MOVE.

Folder hierarchy

For users with multiple accounts, the simplest layout is an account-prefixed form with / as separator:

{MailAccount.Name}/INBOX
{MailAccount.Name}/Sent
{MailAccount.Name}/Archive/2025
...

Based on the UserMailAccount table, each user only sees their own accounts. Admin users see all of them. Modified UTF-7 encoding for special characters (folder names with accents).

The natural source for folder mapping is the ArchivedEmail.FolderName field.

UID stability

RFC 3501 requires UIDs within a folder to be strictly monotonically increasing and never change.

Proposal: use ArchivedEmail.Id directly as the IMAP UID. Auto-increment → monotonically increasing per folder as well (with gaps, which is RFC-compliant). int range (~2.1 billion) stays under the uint32 limit. No new table, no mapping overhead.

UIDVALIDITY: deterministic per folder — e.g., hash(MailAccountId + FolderName) truncated to uint32.

Authentication

The challenge: the existing user system includes both 2FA (TOTP) and OIDC users, which are not natively compatible with IMAP LOGIN.

Proposal — minimal approach: a user can generate a single dedicated IMAP password in their profile. This is enough to let every user (classic, 2FA, OIDC) connect uniformly.

Schema change needed: two new fields on the Users table (ImapPasswordHash, ImapPasswordCreatedAt). A "Generate IMAP password" button in the user profile, which shows the password once.

If reusing the web password directly is feasible on your side, that would be even simpler — but the 2FA/OIDC users would raise compatibility questions there.

TLS and networking

• Port 993, implicit TLS — default
• The existing Kestrel cert configuration can be reused (Kestrel__Endpoints__Https__Certificate__*)
• Plain (non-TLS) IMAP: disabled in production mode

Implementation

• New namespace: MailArchiver.Services.Imap
• In-process IHostedService, shared MailArchiverDbContext and DI
• Custom minimal RFC 3501 parser (manageable size given read-only scope)
• TcpListener + SslStream, async state machine
• MIME response assembly from ArchivedEmail.RawHeaders + Body/HtmlBody + Attachments, using MimeKit (already a dependency)

No new NuGet dependencies.

Suggested configuration keys

json

"Imap": {
  "Enabled": false,
  "Port": 993,
  "MaxConcurrentConnections": 50,
  "IdleTimeoutMinutes": 30
}

Open questions

1. Is the "one IMAP password per user" approach OK, or do you have a simpler idea for reusing the web password?
2. TLS: can the same cert source as Kestrel be used, or would you prefer a separate one?
3. DB migration: is it OK to add the two new User fields following the usual migration pattern (MigrateVYYMM_Z.cs)?

Looking forward to your feedback.

[kben]

Sounds good, when do you plan to implement this feature?