skobkin/docker-stacks
skobkin/docker-stacks
2
2
Fork 0
Code Issues 67 Pull requests 3 Releases Wiki Activity

Mail server #93

New issue
Open
opened 2024-03-26 21:24:59 +03:00 by skobkin · 7 comments
skobkin commented 2024-03-26 21:24:59 +03:00
Owner
Copy link

Some options:

UPD:

UPD:

Some options: - https://www.iredmail.org - https://mailcow.email - https://modoboa.org - https://maddy.email - https://mailinabox.email - https://mailu.io UPD: - https://www.xmox.nl UPD: - https://stalw.art
skobkin self-assigned this 2024-03-26 21:24:59 +03:00
skobkin commented 2024-09-13 02:00:19 +03:00
Author
Owner
Copy link

❌ MailInABox: It's a script to install on the host system.
☑️ iRedMail is an old package with decent reputation. It's development is paid by sustainable business model. But it's complicated and it's default method is installation onto the host OS.
☑️ mailcow: Looks interesting and targeted at Docker setups. But it's kind of amateur project. Not sure how stable it's future will be.
☑️ Modoboa: Looks decent and simple enough. But it uses custom web interfaces for admin and web mail. It's demo mailbox shows erorrs.
☑️ Maddy: Looks quite simple. Targets Docker. But seems like it has no webmail included (could be solved externally).
☑️ Mailu: Looks rather nice and simple. Worth further research.

❌ MailInABox: It's a script to install on the host system. ☑️ iRedMail is an old package with decent reputation. It's development is paid by sustainable business model. But it's complicated and it's default method is installation onto the host OS. ☑️ mailcow: Looks interesting and targeted at Docker setups. But it's kind of amateur project. Not sure how stable it's future will be. ☑️ Modoboa: Looks decent and simple enough. But it uses custom web interfaces for admin and web mail. It's demo mailbox shows erorrs. ☑️ Maddy: Looks quite simple. Targets Docker. But seems like it has no webmail included (could be solved externally). ☑️ Mailu: Looks rather nice and simple. Worth further research.
skobkin commented 2025-04-07 11:29:48 +03:00
Author
Owner
Copy link

To check:

  • Stalwart
To check: - Stalwart
skobkin commented 2025-07-23 01:11:55 +03:00
Author
Owner
Copy link

The most promising:

  • mailu - fully open source, but less features
  • stalwart - open source core with enterprise version with a lot of features
The most promising: - mailu - fully open source, but less features - stalwart - open source core with enterprise version with a lot of features
skobkin commented 2026-01-04 19:53:48 +03:00
Author
Owner
Copy link

Related to #4.

Related to #4.
skobkin commented 2026-01-05 01:10:17 +03:00
Author
Owner
Copy link

Narrowing down to Go and Rust servers.

Comparison table from ChatGPT Deep Research

Feature / Trait Mox Stalwart maddy
Lightweight / architecture Single Go binary; mostly self-contained; minimal deps; built-in store/filtering. Good fit for tiny VPS. Single Rust server; feature-rich but still “one product”; can be self-contained (embedded storage) or use external backends. Typically heavier than Mox/maddy due to more features. Single Go binary; minimal by design; no DB required by default; very low overhead.
Typical RAM for 1–10 accounts Very low (often ~0.5 GB VPS is workable, depending on usage). Low-to-moderate (often ~1 GB+ comfortable; depends on enabled modules and storage backend). Very low (often ~0.5 GB VPS workable; depends on IMAP usage).
External dependencies None required (no Postgres/Redis mandatory). Optional (can use SQLite/RocksDB; or external SQL/LDAP if you want). None required by default; optional integrations (e.g., Rspamd).
Docker deployment Available; also easy to run directly as a binary. Quickstart focuses on simple setup. Available; usually configured via files + web admin; more knobs. Official Docker image; config mounted as a single file.
Ease of deployment Very easy (quickstart guides DNS + config). Moderate (more features = more config choices). Moderate (simple conceptually, but you hand-config domains/users).
Web admin UI Yes (built-in). Yes (web admin + user portal/self-service). No (CLI/config-file based).
Webmail Yes (built-in, but intentionally basic). No built-in webmail (use external webmail via IMAP/JMAP). No (use external webmail via IMAP/SMTP).
Mail protocols SMTP (incl. submission) + IMAP. SMTP + IMAP + POP3 + JMAP. SMTP + IMAP (no POP3).
Calendar / contacts No (email-focused). Yes: CalDAV + CardDAV (and more collaboration features). No (email-focused).
Multi-domain Yes (straightforward). Yes (strong multi-domain; also domain aliases). Yes (via config).
Aliases / catch-all / plus-addressing Yes (aliases, plus-addressing; some edge-case limitations depending on alias chaining). Yes (aliases, lists, catch-all, plus-addressing). Yes (aliases/catch-all via lookup tables and rules; plus-addressing via config patterns).
Disposable / one-time addresses Best handled via plus-addressing and aliases (manual lifecycle). Same: plus-addressing + aliases (very flexible). Same: rules/aliases/plus-addressing (manual).
Deliverability tooling Strong defaults: DKIM, SPF/DMARC checks, MTA-STS/DANE support; setup helps you get DNS right. Very strong: DKIM/SPF/DMARC/ARC, MTA-STS/DANE, TLS reporting; lots of policy/rate-limit options. Strong fundamentals: built-in DKIM/SPF/DMARC; transport security features configurable.
Anti-spam Built-in junk filtering (learning/reputation-style; “batteries included”). Built-in filtering stack (DNSBL/heuristics/Bayes; can integrate with external systems too). Minimal by default (basic checks); typically pair with Rspamd for full content filtering.
Anti-malware Not a built-in AV suite. Not “all-in-one AV” by default; can integrate external AV/milters if desired. Not built-in; integrate external tools if needed.
Stability / maturity Newer project; core mail is solid; webmail/UI still evolving. Newer but very actively developed; broader scope means more moving parts. Core SMTP solid; IMAP/storage maturity varies (some IMAP aspects historically marked “beta”); minimalist scope reduces complexity.
Community / user base Smaller, growing; active dev. Smaller-to-midsize, active; more “early adopter” vibe. Small but focused; good docs; fewer “how-to” posts vs big stacks.
Free to use Yes, fully free/open-source. Yes (community edition fully usable; optional paid enterprise features). Yes, fully free/open-source.
Roadmap / planned features Setup wizard via admin UI; DNS automation (e.g., DANE/DKIM rotation); JMAP + related IMAP extensions; CalDAV/iCal calendaring; more IMAP extensions (SORT/THREAD/etc); Sieve; mailing lists; OAuth2 2025: JMAP for calendars/contacts/files + push to v1.0 (stable DB schema, perf work); built-in webmail SPA planned after v1.0 (likely 2026, Rust/Dioxus) 0.9.0 milestone: imapsql2 storage rewrite (go-imap v2 / maddy-storage) + configuration reload / module lifecycle refactor
Notable issues / caveats • IMAP edge-case bug: SEARCH responses may be split in a way that breaks some clients (e.g., aerc/go-imap).
• Client compatibility: Outlook/Office 365 has IMAP quirks (UIDONLY) → may need per-account capability workarounds (planned).
• No built-in “save sent mail server-side” for SMTP submissions (bots/automations must save their own copy).
• Big-provider interop can bite: Microsoft STARTTLS delivery breakage happened; fixed in newer releases → staying updated matters.		 • Upgrades/migrations can be brittle: a v0.13 migration bug could leave data in an outdated format; may require forced migration/manual cleanup.
• Some upgrades can hang on “accounts locked by another node” during migration (reported even on single-node), esp. with MySQL/MariaDB → may require FORCE_LOCK/patching.
• IMAP edge cases: APPEND can hang on some mailbox names (quotes + non-ASCII); mailbox-tree corruption/circular refs can also cause IMAP clients to hang after renames/migrations; avoid dangerous permissions (e.g., don’t use admin-capable accounts as IMAP users; don’t allow delete-system-folders).
• “Data corruption detected” errors have been reported (e.g., reports page 500s on some setups/versions) → test + keep backups.		 • Outlook/Microsoft interop: reports of Outlook→maddy inbound failing with TLS/renegotiation/handshake errors (fix was staged/“ready for release” in dev/next release).
• Go TLS defaults: building with Go 1.22+ can break delivery to legacy servers that only support RSA key-exchange suites; needs workaround/config tweaks.
• IMAP storage reliability concern: reports of mail delivery succeeding but messages not being saved into imapsql mailboxes.
• IMAP quirks: APPENDLIMIT can be misreported (0 instead of NIL), which can make clients think uploads are forbidden.
Best fit “I want email done right with minimal fuss, tiny VPS, and a built-in UI/webmail.” “I want modern protocols + groupware (CalDAV/CardDAV/JMAP) in one server.” “I want the smallest, simplest mail backend and I’m fine doing admin via config/CLI.”
Narrowing down to **Go** and **Rust** servers. ## Comparison table from ChatGPT Deep Research | Feature / Trait | **Mox** | **Stalwart** | **maddy** | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | **Lightweight / architecture** | Single Go binary; mostly self-contained; minimal deps; built-in store/filtering. Good fit for tiny VPS. | Single Rust server; feature-rich but still “one product”; can be self-contained (embedded storage) or use external backends. Typically heavier than Mox/maddy due to more features. | Single Go binary; minimal by design; no DB required by default; very low overhead. | | **Typical RAM for 1–10 accounts** | Very low (often ~0.5 GB VPS is workable, depending on usage). | Low-to-moderate (often ~1 GB+ comfortable; depends on enabled modules and storage backend). | Very low (often ~0.5 GB VPS workable; depends on IMAP usage). | | **External dependencies** | None required (no Postgres/Redis mandatory). | Optional (can use SQLite/RocksDB; or external SQL/LDAP if you want). | None required by default; optional integrations (e.g., Rspamd). | | **Docker deployment** | Available; also easy to run directly as a binary. Quickstart focuses on simple setup. | Available; usually configured via files + web admin; more knobs. | Official Docker image; config mounted as a single file. | | **Ease of deployment** | Very easy (quickstart guides DNS + config). | Moderate (more features = more config choices). | Moderate (simple conceptually, but you hand-config domains/users). | | **Web admin UI** | Yes (built-in). | Yes (web admin + user portal/self-service). | No (CLI/config-file based). | | **Webmail** | Yes (built-in, but intentionally basic). | No built-in webmail (use external webmail via IMAP/JMAP). | No (use external webmail via IMAP/SMTP). | | **Mail protocols** | SMTP (incl. submission) + IMAP. | SMTP + IMAP + POP3 + JMAP. | SMTP + IMAP (no POP3). | | **Calendar / contacts** | No (email-focused). | Yes: CalDAV + CardDAV (and more collaboration features). | No (email-focused). | | **Multi-domain** | Yes (straightforward). | Yes (strong multi-domain; also domain aliases). | Yes (via config). | | **Aliases / catch-all / plus-addressing** | Yes (aliases, plus-addressing; some edge-case limitations depending on alias chaining). | Yes (aliases, lists, catch-all, plus-addressing). | Yes (aliases/catch-all via lookup tables and rules; plus-addressing via config patterns). | | **Disposable / one-time addresses** | Best handled via plus-addressing and aliases (manual lifecycle). | Same: plus-addressing + aliases (very flexible). | Same: rules/aliases/plus-addressing (manual). | | **Deliverability tooling** | Strong defaults: DKIM, SPF/DMARC checks, MTA-STS/DANE support; setup helps you get DNS right. | Very strong: DKIM/SPF/DMARC/ARC, MTA-STS/DANE, TLS reporting; lots of policy/rate-limit options. | Strong fundamentals: built-in DKIM/SPF/DMARC; transport security features configurable. | | **Anti-spam** | Built-in junk filtering (learning/reputation-style; “batteries included”). | Built-in filtering stack (DNSBL/heuristics/Bayes; can integrate with external systems too). | Minimal by default (basic checks); typically pair with Rspamd for full content filtering. | | **Anti-malware** | Not a built-in AV suite. | Not “all-in-one AV” by default; can integrate external AV/milters if desired. | Not built-in; integrate external tools if needed. | | **Stability / maturity** | Newer project; core mail is solid; webmail/UI still evolving. | Newer but very actively developed; broader scope means more moving parts. | Core SMTP solid; IMAP/storage maturity varies (some IMAP aspects historically marked “beta”); minimalist scope reduces complexity. | | **Community / user base** | Smaller, growing; active dev. | Smaller-to-midsize, active; more “early adopter” vibe. | Small but focused; good docs; fewer “how-to” posts vs big stacks. | | **Free to use** | Yes, fully free/open-source. | Yes (community edition fully usable; optional paid enterprise features). | Yes, fully free/open-source. | | Roadmap / planned features | Setup wizard via admin UI; DNS automation (e.g., DANE/DKIM rotation); JMAP + related IMAP extensions; CalDAV/iCal calendaring; more IMAP extensions (SORT/THREAD/etc); Sieve; mailing lists; OAuth2 | 2025: JMAP for calendars/contacts/files + push to v1.0 (stable DB schema, perf work); built-in webmail SPA planned after v1.0 (likely 2026, Rust/Dioxus) | 0.9.0 milestone: imapsql2 storage rewrite (go-imap v2 / maddy-storage) + configuration reload / module lifecycle refactor | | Notable issues / caveats | • IMAP edge-case bug: SEARCH responses may be split in a way that breaks some clients (e.g., aerc/go-imap).<br>• Client compatibility: Outlook/Office 365 has IMAP quirks (UIDONLY) → may need per-account capability workarounds (planned).<br>• No built-in “save sent mail server-side” for SMTP submissions (bots/automations must save their own copy).<br>• Big-provider interop can bite: Microsoft STARTTLS delivery breakage happened; fixed in newer releases → staying updated matters. | • Upgrades/migrations can be brittle: a v0.13 migration bug could leave data in an outdated format; may require forced migration/manual cleanup.<br>• Some upgrades can hang on “accounts locked by another node” during migration (reported even on single-node), esp. with MySQL/MariaDB → may require FORCE_LOCK/patching.<br>• IMAP edge cases: APPEND can hang on some mailbox names (quotes + non-ASCII); mailbox-tree corruption/circular refs can also cause IMAP clients to hang after renames/migrations; avoid dangerous permissions (e.g., don’t use admin-capable accounts as IMAP users; don’t allow delete-system-folders).<br>• “Data corruption detected” errors have been reported (e.g., reports page 500s on some setups/versions) → test + keep backups. | • Outlook/Microsoft interop: reports of Outlook→maddy inbound failing with TLS/renegotiation/handshake errors (fix was staged/“ready for release” in dev/next release).<br>• Go TLS defaults: building with Go 1.22+ can break delivery to legacy servers that only support RSA key-exchange suites; needs workaround/config tweaks.<br>• IMAP storage reliability concern: reports of mail delivery succeeding but messages not being saved into `imapsql` mailboxes.<br>• IMAP quirks: APPENDLIMIT can be misreported (0 instead of NIL), which can make clients think uploads are forbidden. | | **Best fit** | “I want email done right with minimal fuss, tiny VPS, and a built-in UI/webmail.” | “I want modern protocols + groupware (CalDAV/CardDAV/JMAP) in one server.” | “I want the smallest, simplest mail backend and I’m fine doing admin via config/CLI.” |
skobkin commented 2026-01-05 01:11:11 +03:00
Author
Owner
Copy link

I'm personally inclined to try Mox considering all known facts.

I'm personally inclined to try Mox considering all known facts.
skobkin commented 2026-01-05 01:22:47 +03:00
Author
Owner
Copy link

Mox

It is important to run with docker host networking, so mox can use the public IPs and has correct remote IP information for incoming connections (important for junk filtering and rate-limiting).

Probably some research on Nginx mail proxying is needed.

## Mox - [Docker installation](https://www.xmox.nl/install/#hdr-docker) - [Docker registry](https://r.xmox.nl/r/mox/) (available images) - [`docker-compose.yml` example](https://raw.githubusercontent.com/mjl-/mox/refs/heads/main/docker-compose.yml) > It is important to run with docker host networking, so mox can use the public IPs and has correct remote IP information for incoming connections (important for junk filtering and rate-limiting). Probably some research on Nginx mail proxying is needed.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
immich_stack_update
mox
element-call
No results found.
Labels
Clear labels   
WIP
Work in progress

  
bug
Something is not working

  
duplicate

   
enhancement
New feature

  
new stack
Request for a new stack

  
security
Security-related changes

  
to be researched
Proposals for checking.

  
won't fix
Will not be fixed or implemented for some reason.

No labels
WIP
bug
duplicate
enhancement
new stack
security
to be researched
won't fix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
skobkin
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
skobkin/docker-stacks#93
No description provided.