[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-71463":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":16,"forks30d":16,"starsTrendScore":16,"compositeScore":19,"rankGlobal":10,"rankLanguage":10,"license":20,"archived":21,"fork":21,"defaultBranch":22,"hasWiki":21,"hasPages":21,"topics":23,"createdAt":10,"pushedAt":10,"updatedAt":24,"readmeContent":25,"aiSummary":26,"trendingCount":16,"starSnapshotCount":16,"syncStatus":27,"lastSyncTime":28,"discoverSource":29},71463,"mox","mjl-\u002Fmox","mjl-","modern full-featured open source secure mail server for low-maintenance self-hosted email","https:\u002F\u002Fwww.xmox.nl",null,"Go",5708,195,41,184,0,4,30,37.88,"MIT License",false,"main",[],"2026-06-12 02:02:52","Mox is a modern full-featured open source secure mail server for low-maintenance self-hosted email.\n\nFor more details, see the mox website, https:\u002F\u002Fwww.xmox.nl.\n\nSee Quickstart below to get started.\n\n## Features\n\n- Quick and easy to start\u002Fmaintain mail server, for your own domain(s).\n- SMTP (with extensions) for receiving, submitting and delivering email.\n- IMAP4 (with extensions) for giving email clients access to email.\n- Webmail for reading\u002Fsending email from the browser.\n- SPF\u002FDKIM\u002FDMARC for authenticating messages\u002Fdelivery, also DMARC aggregate\n  reports.\n- Reputation tracking, learning (per user) host-, domain- and\n  sender address-based reputation from (Non-)Junk email classification.\n- Bayesian spam filtering that learns (per user) from (Non-)Junk email.\n- Slowing down senders with no\u002Flow reputation or questionable email content\n  (similar to greylisting). Rejected emails are stored in a mailbox called Rejects\n  for a short period, helping with misclassified legitimate synchronous\n  signup\u002Flogin\u002Ftransactional emails.\n- Internationalized email (EIA), with unicode in email address usernames\n  (\"localparts\"), and in domain names (IDNA).\n- Automatic TLS with ACME, for use with Let's Encrypt and other CA's.\n- DANE and MTA-STS for inbound and outbound delivery over SMTP with STARTTLS,\n  including REQUIRETLS and with incoming\u002Foutgoing TLSRPT reporting.\n- Web admin interface that helps you set up your domains, accounts and list\n  aliases (instructions to create DNS records, configure\n  SPF\u002FDKIM\u002FDMARC\u002FTLSRPT\u002FMTA-STS), for status information, and modifying the\n  configuration file.\n- Account autodiscovery (with SRV records, Microsoft-style, Thunderbird-style,\n  and Apple device management profiles) for easy account setup (though client\n  support is limited).\n- Webserver with serving static files and forwarding requests (reverse\n  proxy), so port 443 can also be used to serve websites.\n- Simple HTTP\u002FJSON API for sending transaction email and receiving delivery\n  events and incoming messages (webapi and webhooks).\n- Prometheus metrics and structured logging for operational insight.\n- \"mox localserve\" subcommand for running mox locally for email-related\n  testing\u002Fdeveloping, including pedantic mode.\n- Most non-server Go packages mox consists of are written to be reusable.\n\nMox is available under the MIT-license and was created by Mechiel Lukkien,\nmechiel@ueber.net. Mox includes BSD-3-claused code from the Go Authors, and the\nPublic Suffix List by Mozilla under Mozilla Public License, v2.0.\n\nMox has automated tests, including for interoperability with Postfix for SMTP.\nMox is manually tested with email clients: Mozilla Thunderbird, mutt, iOS Mail,\nmacOS Mail, Android Mail, Microsoft Outlook. Mox is also manually tested to\ninteroperate with popular cloud providers: gmail.com, outlook.com, yahoo.com,\nproton.me.\n\nThe code is heavily cross-referenced with the RFCs for readability\u002Fmaintainability.\n\n# Quickstart\n\nThe easiest way to get started with serving email for your domain is to get a\n(virtual) machine dedicated to serving email, name it `[host].[domain]` (e.g.\nmail.example.com). Having a DNSSEC-verifying resolver installed, such as\nunbound, is highly recommended. Run as root:\n\n\t# Create mox user and homedir (or pick another name or homedir):\n\tuseradd -m -d \u002Fhome\u002Fmox mox\n\n\tcd \u002Fhome\u002Fmox\n\t... compile or download mox to this directory, see below ...\n\n\t# Generate config files for your address\u002Fdomain:\n\t.\u002Fmox quickstart you@example.com\n\nThe quickstart:\n\n- Creates configuration files mox.conf and domains.conf.\n- Adds the domain and an account for the email address to domains.conf\n- Generates an admin and account password.\n- Prints the DNS records you need to add, for the machine and domain.\n- Prints commands to start mox, and optionally install mox as a service.\n\nA machine that doesn't already run a webserver is highly recommended because\nmodern email requires HTTPS, and mox currently needs to run a webserver for\nautomatic TLS with ACME.  You could combine mox with an existing webserver, but\nit requires a lot more configuration. If you want to serve websites on the same\nmachine, consider using the webserver built into mox. It's pretty good! If you\nwant to run an existing webserver on port 443\u002F80, see `mox help quickstart`.\n\nAfter starting, you can access the admin web interface on internal IPs.\n\n# Download\n\nDownload a mox binary from\nhttps:\u002F\u002Fbeta.gobuilds.org\u002Fgithub.com\u002Fmjl-\u002Fmox@latest\u002Flinux-amd64-latest\u002F.\n\nSymlink or rename it to \"mox\".\n\nThe URL above always resolves to the latest release for linux\u002Famd64 built with\nthe latest Go toolchain.  See the links at the bottom of that page for binaries\nfor other platforms.\n\n# Compiling\n\nYou can easily (cross) compile mox yourself. You need a recent Go toolchain\ninstalled.  Run `go version`, it must be >= 1.24. Download the latest version\nfrom https:\u002F\u002Fgo.dev\u002Fdl\u002F or see https:\u002F\u002Fgo.dev\u002Fdoc\u002Fmanage-install.\n\nTo download the source code of the latest release, and compile it to binary \"mox\":\n\n\tGOBIN=$PWD CGO_ENABLED=0 go install github.com\u002Fmjl-\u002Fmox@latest\n\nMox only compiles for and fully works on unix systems. Mox also compiles for\nWindows, but \"mox serve\" does not yet work, though \"mox localserve\" (for a\nlocal test instance) and most other subcommands do. Mox does not compile for\nPlan 9.\n\n# Docker\n\nAlthough not recommended, you can also run mox with docker image\n`r.xmox.nl\u002Fmox`, with tags like `v0.0.1` and `v0.0.1-go1.20.1-alpine3.17.2`, see\nhttps:\u002F\u002Fr.xmox.nl\u002Fr\u002Fmox\u002F.  See\nhttps:\u002F\u002Fgithub.com\u002Fmjl-\u002Fmox\u002Fblob\u002Fmain\u002Fdocker-compose.yml to get started.\n\nNew docker images aren't (automatically) generated for new Go runtime\u002Fcompile\nreleases.\n\nIt is important to run with docker host networking, so mox can use the public\nIPs and has correct remote IP information for incoming connections (important\nfor junk filtering and rate-limiting).\n\n# Development\n\nSee develop.txt for instructions\u002Ftips for developing on mox.\n\n# Sponsors\n\nThanks to NLnet foundation, the European Commission's NGI programme, and the\nNetherlands Ministry of the Interior and Kingdom Relations for financial\nsupport:\n\n- 2024\u002F2025, NLnet NGI0 Zero Core, https:\u002F\u002Fnlnet.nl\u002Fproject\u002FMox-Automation\u002F\n- 2024, NLnet e-Commons Fund, https:\u002F\u002Fnlnet.nl\u002Fproject\u002FMox-API\u002F\n- 2023\u002F2024, NLnet NGI0 Entrust, https:\u002F\u002Fnlnet.nl\u002Fproject\u002FMox\u002F\n\n# Roadmap\n\n- \"mox setup\" command, using admin web interface for interactive setup\n- Automate DNS management, for setup and maintenance, such as DANE\u002FDKIM key rotation\n- Config options for \"transactional email domains\", for which mox will only\n  send messages\n- Encrypted storage of files (email messages, TLS keys), also with per account keys\n- Recognize common deliverability issues and help postmasters solve them\n- JMAP, IMAP OBJECTID extension, IMAP JMAPACCESS extension\n- Calendaring with CalDAV\u002FiCal\n- Introbox, to which first-time senders are delivered\n- Add special IMAP mailbox (\"Queue?\") that contains queued but\n  undelivered messages, updated with IMAP flags\u002Fkeywords\u002Ftags and message headers.\n- External addresses in aliases\u002Flists.\n- Autoresponder (out of office\u002Fvacation)\n- Mailing list manager\n- IMAP extensions for \"online\"\u002Fnon-syncing\u002Fwebmail clients (SORT (including\n  DISPLAYFROM, DISPLAYTO), THREAD, PARTIAL, CONTEXT=SEARCH CONTEXT=SORT ESORT,\n  FILTERS)\n- IMAP ACL support, for account sharing (interacts with many extensions and code)\n- Improve support for mobile clients with extensions: IMAP URLAUTH, SMTP\n  CHUNKING and BINARYMIME, IMAP CATENATE\n- Privilege separation, isolating parts of the application to more restricted\n  sandbox (e.g. new unauthenticated connections)\n- Using mox as backup MX\n- Sieve for filtering (for now see Rulesets in the account config)\n- ARC, with forwarded email from trusted source\n- Milter support, for integration with external tools\n- SMTP DSN extension\n- IMAP Sieve extension, to run Sieve scripts after message changes (not only\n  new deliveries)\n- OAUTH2 support, for single sign on\n- Forwarding (to an external address)\n\nThere are many smaller improvements to make as well, search for \"todo\" in the code.\n\n## Not supported\u002Fplanned\n\nThere is currently no plan to implement the following. Though this may\nchange in the future.\n\n- Functioning as an SMTP relay without authentication\n- POP3\n- Delivery to (unix) OS system users (mbox\u002FMaildir)\n- Support for pluggable delivery mechanisms\n\n\n# FAQ - Frequently Asked Questions\n\n## Why a new mail server implementation?\n\nMox aims to make \"running a mail server\" easy and nearly effortless. Excellent\nquality (open source) mail server software exists, but getting a working setup\ntypically requires you configure half a dozen services (SMTP, IMAP,\nSPF\u002FDKIM\u002FDMARC, spam filtering), which are often written in C (where small bugs\noften have large consequences). That seems to lead to people no longer running\ntheir own mail servers, instead switching to one of the few centralized email\nproviders. Email with SMTP is a long-time decentralized messaging protocol. To\nkeep it decentralized, people need to run their own mail server. Mox aims to\nmake that easy.\n\n## Where is the documentation?\n\nTo keep mox as a project maintainable, documentation is integrated into, and\ngenerated from the code.\n\nA list of mox commands, and their help output, are at\nhttps:\u002F\u002Fwww.xmox.nl\u002Fcommands\u002F.\n\nMox is configured through configuration files, and each field comes with\ndocumentation. See https:\u002F\u002Fwww.xmox.nl\u002Fconfig\u002F for config files containing all\nfields and their documentation.\n\nYou can get the same information by running \"mox\" without arguments to list its\nsubcommands and usage, and \"mox help [subcommand]\" for more details.\n\nThe example config files are printed by \"mox config describe-static\" and \"mox\nconfig describe-dynamic\".\n\nIf you're missing some documentation, please create an issue describing what is\nunclear or confusing, and we'll try to improve the documentation.\n\n## Is Mox affected by SMTP smuggling?\n\nMox itself is not affected: it only treats \"\\r\\n.\\r\\n\" as SMTP end-of-message.\nBut read on for caveats.\n\nSMTP smuggling exploits differences in handling by SMTP servers of: carriage\nreturns (CR, or \"\\r\"), newlines (line feeds, LF, \"\\n\") in the context of \"dot\nstuffing\".  SMTP is a text-based protocol. An SMTP transaction to send a\nmessage is finalized with a \"\\r\\n.\\r\\n\" sequence. This sequence could occur in\nthe message being transferred, so any verbatim \".\" at the start of a line in a\nmessage is \"escaped\" with another dot (\"dot stuffing\"), to not trigger the SMTP\nend-of-message. SMTP smuggling takes advantage of bugs in some mail servers\nthat interpret other sequences than \"\\r\\n.\\r\\n\" as SMTP end-of-message. For\nexample \"\\n.\\n\" or even \"\\r.\\r\", and perhaps even other magic character\ncombinations.\n\nBefore v0.0.9, mox accepted SMTP transactions with bare carriage returns\n(without newline) for compatibility with real-world email messages, considering\nthem meaningless and therefore innocuous.\n\nSince v0.0.9, SMTP transactions with bare carriage returns are rejected.\nSending messages with bare carriage returns to buggy mail servers can cause\nthose mail servers to materialize non-existent messages. Now that mox rejects\nmessages with bare carriage returns, sending a message through mox can no\nlonger be used to trigger those bugs.\n\nMox can still handle bare carriage returns in email messages, e.g. those\nimported from mbox files or Maildirs, or from messages added over IMAP. Mox\nstill fixes up messages with bare newlines by adding the missing carriage\nreturns.\n\nBefore v0.0.9, an SMTP transaction for a message containing \"\\n.\\n\" would\nresult in a non-specific error message, and \"\\r\\n.\\n\" would result in the dot\nbeing dropped. Since v0.0.9, these sequences are rejected with a message\nmentioning SMTP smuggling.\n\n## How do I import\u002Fexport email?\n\nUse the import functionality on the accounts web page to import a zip\u002Ftgz with\nmaildirs\u002Fmbox files, or use the \"mox import maildir\" or \"mox import mbox\"\nsubcommands. You could also use your IMAP email client, add your mox account,\nand copy or move messages from one account to the other.\n\nSimilarly, see the export functionality on the accounts web page and the \"mox\nexport maildir\" and \"mox export mbox\" subcommands to export email.\n\nImporting large mailboxes may require a lot of memory (a limitation of the\ncurrent database). Splitting up mailboxes in smaller parts (e.g. 100k messages)\nwould help.\n\n## How can I help?\n\nMox needs users and testing in real-life setups! So just give it a try, send\nand receive emails through it with your favourite email clients, and file an\nissue if you encounter a problem or would like to see a feature\u002Ffunctionality\nimplemented.\n\nInstead of switching email for your domain over to mox, you could simply\nconfigure mox for a subdomain, e.g. [you]@moxtest.[yourdomain].\n\nIf you have experience with how the email protocols are used in the wild, e.g.\ncompatibility issues, limitations, anti-spam measures, specification\nviolations, that would be interesting to hear about.\n\nPull requests for bug fixes and new code are welcome too. If the changes are\nlarge, it helps to start a discussion (create an \"issue\") before doing all the\nwork. In practice, starting with a small contribution and growing from there has\nthe highest chance of success.\n\nBy contributing (e.g. code), you agree your contributions are licensed under the\nMIT license (like mox), and have the rights to do so.\n\n## Where can I discuss mox?\n\nJoin #mox on irc.oftc.net, or #mox:matrix.org (https:\u002F\u002Fmatrix.to\u002F#\u002F#mox:matrix.org),\nor #mox on the \"Gopher slack\".\n\nFor bug reports, please file an issue at https:\u002F\u002Fgithub.com\u002Fmjl-\u002Fmox\u002Fissues\u002Fnew.\n\n## How do I change my password?\n\nRegular users (doing IMAP\u002FSMTP with authentication) can change their password\nat the account page, e.g. `http:\u002F\u002Flocalhost\u002F`. Or you can set a password with \"mox\nsetaccountpassword\".\n\nThe admin can change the password of any account through the admin page, at\n`http:\u002F\u002Flocalhost\u002Fadmin\u002F` by default (leave username empty when logging in).\n\nThe account and admin pages are served on localhost for configs created with\nthe quickstart.  To access these from your browser, run\n`ssh -L 8080:localhost:80 you@yourmachine` locally and open\n`http:\u002F\u002Flocalhost:8080\u002F[...]`.\n\nThe admin password can be changed with \"mox setadminpassword\".\n\n## How do I configure a second mox instance as a backup MX?\n\nUnfortunately, mox does not yet provide an option for that. Mox does spam\nfiltering based on reputation of received messages. It will take a good amount\nof work to share that information with a backup MX. Without that information,\nspammers could use a backup MX to get their spam accepted.\n\nUntil mox has a proper solution, you can simply run a single SMTP server. The\nauthor has run a single mail server for over a decade without issues. Machines\nand network connectivity are stable nowadays, and email delivery will be\nretried for many hours during temporary errors (e.g. when rebooting a machine\nafter updates).\n\n## How do I stay up to date?\n\nPlease set \"CheckUpdates: true\" in mox.conf. Mox will check for a new version\nthrough a DNS TXT request for `_updates.xmox.nl` once per 24h. Only if a new\nversion is published will the changelog be fetched and delivered to the\npostmaster mailbox.\n\nThe changelog, including latest update instructions, is at\nhttps:\u002F\u002Fupdates.xmox.nl\u002Fchangelog.\n\nYou can also monitor newly added releases on this repository with the github\n\"watch\" feature, or use the github RSS feed for tags\n(https:\u002F\u002Fgithub.com\u002Fmjl-\u002Fmox\u002Ftags.atom) or releases\n(https:\u002F\u002Fgithub.com\u002Fmjl-\u002Fmox\u002Freleases.atom), or monitor the docker images.\n\nKeep in mind you have a responsibility to keep the internet-connected software\nyou run up to date and secure.\n\n## How do I upgrade my mox installation?\n\nWe try to make upgrades effortless and you can typically just put a new binary\nin place and restart. If manual actions are required, the release notes mention\nthem. Check the release notes of all version between your current installation\nand the release you're upgrading to.\n\nBefore upgrading, make a backup of the config & data directory with `mox backup\n\u003Cdestdir>`. This copies all files from the config directory to\n`\u003Cdestdir>\u002Fconfig`, and creates `\u003Cdestdir>\u002Fdata` with a consistent snapshots of\nthe database files, and message files from the outgoing queue and accounts.\nUsing the new mox binary, run `mox verifydata \u003Cdestdir>\u002Fdata` (do NOT use the\n\"live\" data directory!) for a dry run. If this fails, an upgrade will probably\nfail too.\n\nImportant: verifydata with the new mox binary can modify the database files\n(due to automatic schema upgrades). So make a fresh backup again before the\nactual upgrade. See the help output of the \"backup\" and \"verifydata\" commands\nfor more details.\n\nDuring backup, message files are hardlinked if possible, and copied otherwise.\nUsing a destination directory like `data\u002Ftmp\u002Fbackup` increases the odds\nhardlinking succeeds: the default mox systemd service file mounts\nthe data directory separately, so hardlinks to outside the data directory are\ncross-device and will fail.\n\nIf an upgrade fails and you have to restore (parts) of the data directory, you\nshould run `mox verifydata \u003Cdatadir>` (with the original binary) on the\nrestored directory before starting mox again. If problematic files are found,\nfor example queue or account message files that are not in the database, run\n`mox verifydata -fix \u003Cdatadir>` to move away those files. After a restore, you may\nalso want to run `mox bumpuidvalidity \u003Caccount>` for each account for which\nmessages in a mailbox changed, to force IMAP clients to synchronize mailbox\nstate.\n\n## How secure is mox?\n\nSecurity is high on the priority list for mox. Mox is young, so don't expect no\nbugs at all. Mox does have automated tests for some security aspects, e.g. for\nlogin, and uses fuzzing. Mox is written in Go, so some classes of bugs such as\nbuffer mishandling do not typically result in privilege escalation.  Of course\nlogic bugs will still exist. If you find any security issues, please email them\nto mechiel@ueber.net.\n\n## I'm now running an email server, but how does email work?\n\nCongrats and welcome to the club! Running an email server on the internet comes\nwith some responsibilities so you should understand how it works. See\nhttps:\u002F\u002Fexplained-from-first-principles.com\u002Femail\u002F for a thorough explanation.\n\n## What are the minimum requirements to run mox?\n\nMox does not need much. Nowadays most machines are larger than mox needs. You\ncan start with a machine with 512MB RAM, any CPU will do. For storage you\nshould account for the size of the email messages (no compression currently),\nan additional 15% overhead for the meta data, and add some more headroom.\nExpand as necessary.\n\n## Won't the big email providers block my email?\n\nIt is a common misconception that it is impossible to run your own email server\nnowadays. The claim is that the handful big email providers will simply block\nyour email. However, you can run your own email server just fine, and your\nemail will be accepted, provided you are doing it right.\n\nIf your email is rejected, it is often because your IP address has a bad email\nsending reputation. Email servers often use IP blocklists to reject email\nnetworks with a bad email sending reputation. These blocklists often work at\nthe level of whole network ranges. So if you try to run an email server from a\nhosting provider with a bad reputation (which happens if they don't monitor\ntheir network or don't act on abuse\u002Fspam reports), your IP too will have a bad\nreputation and other mail servers (both large and small) may reject messages\ncoming from you. During the quickstart, mox checks if your IPs are on a few\noften-used blocklists. It's typically not a good idea to host an email server\non the cheapest or largest cloud providers: They often don't spend the\nresources necessary for a good reputation, or they simply block all outgoing\nSMTP traffic. It's better to look for a technically-focused local provider.\nThey too may initially block outgoing SMTP connections on new machines to\nprevent spam from their networks. But they will either automatically open up\noutgoing SMTP traffic after a cool down period (e.g. 24 hours), or after you've\ncontacted their support.\n\nAfter you get past the IP blocklist checks, email servers use many more signals\nto determine if your email message could be spam and should be rejected. Mox\nhelps you set up a system that doesn't trigger most of the technical signals\n(e.g. with SPF\u002FDKIM\u002FDMARC). But there are more signals, for example: Sending to\na mail server or address for the first time. Sending from a newly registered\ndomain (especially if you're sending automated messages, and if you send more\nmessages after previous messages were rejected), domains that existed for a few\nweeks to a month are treated more friendly. Sending messages with content that\nresembles known spam messages.\n\nShould your email be rejected, you will typically get an error message during\nthe SMTP transaction that explains why. In the case of big email providers the\nerror message often has instructions on how to prove to them you are a\nlegitimate sender.\n\n## Can mox deliver through a smarthost?\n\nYes, you can configure a \"Transport\" in mox.conf and configure \"Routes\" in\ndomains.conf to send some or all messages through the transport. A transport\ncan be an SMTP relay or authenticated submission, or making mox make outgoing\nconnections through a SOCKS proxy.\n\nFor an example, see https:\u002F\u002Fwww.xmox.nl\u002Fconfig\u002F#hdr-example-transport. For\ndetails about Transports and Routes, see\nhttps:\u002F\u002Fwww.xmox.nl\u002Fconfig\u002F#cfg-mox-conf-Transports and\nhttps:\u002F\u002Fwww.xmox.nl\u002Fconfig\u002F#cfg-domains-conf-Routes.\n\nRemember to add the IP addresses of the transport to the SPF records of your\ndomains. Keep in mind some 3rd party submission servers may mishandle your\nmessages, for example by replacing your Message-Id header and thereby\ninvalidating your DKIM-signatures, or rejecting messages with more than one\nDKIM-signature.\n\n## Can I use mox to send transactional email?\n\nYes. While you can use SMTP submission to send messages you've composed\nyourself, and monitor a mailbox for DSNs, a more convenient option is to use\nthe mox HTTP\u002FJSON-based webapi and webhooks.\n\nThe mox webapi can be used to send outgoing messages that mox composes. The web\napi can also be used to deal with messages stored in an account, like changing\nmessage flags, retrieving messages in parsed form or individual parts of\nmultipart messages, or moving messages to another mailbox or deleting messages\naltogether.\n\nMox webhooks can be used to receive updates about incoming and outgoing\ndeliveries. Mox can automatically manage per account suppression lists.\n\nSee https:\u002F\u002Fwww.xmox.nl\u002Ffeatures\u002F#hdr-webapi-and-webhooks for details.\n\n## Can I use existing TLS certificates\u002Fkeys?\n\nYes. The quickstart command creates a config that uses ACME with Let's Encrypt,\nbut you can change the config file to use existing certificate and key files.\n\nYou'll see \"ACME: letsencrypt\" in the \"TLS\" section of the \"public\" Listener.\nRemove or comment out the ACME-line, and add a \"KeyCerts\" section, see\nhttps:\u002F\u002Fwww.xmox.nl\u002Fconfig\u002F#cfg-mox-conf-Listeners-x-TLS-KeyCerts\n\nYou can have multiple certificates and keys: The line with the \"-\" (dash) is\nthe start of a list item. Duplicate that line up to and including the line with\nKeyFile for each certificate\u002Fkey you have. Mox makes a TLS config that holds\nall specified certificates\u002Fkeys, and uses it for all services for that Listener\n(including a webserver), choosing the correct certificate for incoming\nrequests.\n\nKeep in mind that for each email domain you host, you will need a certificate\nfor `mta-sts.\u003Cdomain>`, `autoconfig.\u003Cdomain>` and `mail.\u003Cdomain>`, unless you\ndisable MTA-STS, autoconfig and the client-settings-domain for that domain.\n\nMox opens the key and certificate files during initial startup, as root (and\npasses file descriptors to the unprivileged process).  No special permissions\nare needed on the key and certificate files.\n\n## Can I directly access mailboxes through the file system?\n\nNo, mox only provides access to email through protocols like IMAP.\n\nWhile it can be convenient for users\u002Femail clients to access email through\nconventions like Maildir, providing such access puts quite a burden on the\nserver: The server has to continuously watch for changes made to the mail store\nby external programs, and sync its internal state. By only providing access to\nemails through mox, the storage\u002Fstate management is simpler and easier to\nimplement reliably.\n\nNot providing direct file system access also allows future improvements in the\nstorage mechanism. Such as encryption of all stored messages. Programs won't be\nable to access such messages directly.\n\nMox stores metadata about delivered messages in its per-account message index\ndatabase, more than fits in a simple (filename-based) format like Maildir. The\nIP address of the remote SMTP server during delivery, SPF\u002FDKIM\u002FDMARC domains\nand validation status, and more...\n\nFor efficiency, mox doesn't prepend message headers generated during delivery\n(e.g. Authentication-Results) to the on-disk message file, but only stores it\nin the database. This prevents a rewrite of the entire message file. When\nreading a message, mox combines the prepended headers from the database with\nthe message file.\n\nMox user accounts have no relation to operating system user accounts. Multiple\nsystem users reading their email on a single machine is not very common\nanymore. All data (for all accounts) stored by mox is accessible only by the\nmox process.  Messages are currently stored as individual files in standard\nInternet Message Format (IMF), at `data\u002Faccounts\u002F\u003Caccount>\u002Fmsg\u002F\u003Cdir>\u002F\u003Cmsgid>`:\n`msgid` is a consecutive unique integer id assigned by the per-account message\nindex database; `dir` groups 8k consecutive message ids into a directory,\nensuring they don't become too large.  The message index database file for an\naccount is at `data\u002Faccounts\u002F\u003Caccount>\u002Findex.db`, accessed with the bstore\ndatabase library, which uses bbolt (formerly BoltDB) for storage, a\ntransactional key\u002Fvalue library\u002Ffile format inspired by LMDB.\n\n## How do I block IPs with authentication failures with fail2ban?\n\nMox includes a rate limiter for IPs\u002Fnetworks that cause too many authentication\nfailures. It automatically unblocks such IPs\u002Fnetworks after a while. So you may\nnot need fail2ban. If you want to use fail2ban, you could use this snippet:\n\n\t[Definition]\n\tfailregex = .*failed authentication attempt.*remote=\u003CHOST>\n\tignoreregex =\n","Mox 是一个现代化的全功能开源安全邮件服务器，旨在为自托管电子邮件提供低维护成本的服务。它支持SMTP和IMAP4协议来接收、提交及交付邮件，并提供Webmail服务，方便用户通过浏览器访问邮件。Mox还集成了SPF\u002FDKIM\u002FDMARC等技术以确保邮件的真实性和安全性，同时具备贝叶斯垃圾邮件过滤功能以及基于声誉的发件人控制机制。此外，Mox支持国际化邮件地址、自动TLS证书管理、DANE与MTA-STS增强的安全性配置等功能。该邮件服务器非常适合需要在自己的域名下建立稳定且安全的电子邮件服务的企业或个人使用。",2,"2026-06-11 03:37:52","high_star"]