2Command mox is a modern, secure, full-featured, open source mail server for

5Mox is started with the "serve" subcommand, but mox also has many other

8Many of those commands talk to a running mox instance, through the ctl file in

9the data directory. Specify the configuration file (that holds the path to the

10data directory) through the -config flag or MOXCONF environment variable.

12Commands that don't talk to a running mox instance are often for

13testing/debugging email functionality. For example for parsing an email message,

16Below is the usage information as printed by the command when started without

17any parameters. Followed by the help and usage information for each command.

21 mox [-config config/mox.conf] [-pedantic] ...

23 mox quickstart [-existing-webserver] [-hostname host] user@domain [user | uid]

29 mox queue kick [-id id] [-todomain domain] [-recipient address] [-transport transport]

30 mox queue drop [-id id] [-todomain domain] [-recipient address]

32 mox import maildir accountname mailboxname maildir

33 mox import mbox accountname mailboxname mbox

34 mox export maildir dst-dir account-path [mailbox]

35 mox export mbox dst-dir account-path [mailbox]

43 mox config describe-domains >domains.conf

49 mox config domain add domain account [localpart]

51 mox config describe-sendmail >/etc/moxsubmit.conf

59 mox dane dialmx domain [destination-host]

60 mox dane makerecord usage selector matchtype [certificate.pem | publickey.pem | privatekey.pem]

61 mox dns lookup [ptr | mx | cname | ips | a | aaaa | ns | txt | srv | tlsa] name

62 mox dkim gened25519 >$selector._domainkey.$domain.ed25519.privatekey.pkcs8.pem

63 mox dkim genrsa >$selector._domainkey.$domain.rsa2048.privatekey.pkcs8.pem

65 mox dkim txt <$selector._domainkey.$domain.key.pkcs8.pem

70 mox dmarc verify remoteip mailfromaddress helodomain < message

76 mox sendmail [-Fname] [ignoredflags] [-t] [<message]

97Incoming email is accepted over SMTP. Email can be retrieved by users using

98IMAP. HTTP listeners are started for the admin/account web interfaces, and for

99automated TLS configuration. Missing essential TLS certificates are immediately

100requested, other TLS certificates are requested on demand.

102Only implemented on unix systems, not Windows.

108Quickstart generates configuration files and prints instructions to quickly set up a mox instance.

110Quickstart writes configuration files, prints initial admin and account

111passwords, DNS records you should create. If you run it on Linux it writes a

112systemd service file and prints commands to enable and start mox as service.

114The user or uid is optional, defaults to "mox", and is the user or uid/gid mox

117Quickstart assumes mox will run on the machine you run quickstart on and uses

118its host name and public IPs. On many systems the hostname is not a fully

119qualified domain name, but only the first dns "label", e.g. "mail" in case of

120"mail.example.org". If so, quickstart does a reverse DNS lookup to find the

121hostname, and as fallback uses the label plus the domain of the email address

122you specified. Use flag -hostname to explicitly specify the hostname mox will

125Mox is by far easiest to operate if you let it listen on port 443 (HTTPS) and

12680 (HTTP). TLS will be fully automatic with ACME with Let's Encrypt.

128You can run mox along with an existing webserver, but because of MTA-STS and

129autoconfig, you'll need to forward HTTPS traffic for two domains to mox. Run

130"mox quickstart -existing-webserver ..." to generate configuration files and

131instructions for configuring mox along with an existing webserver.

133But please first consider configuring mox on port 443. It can itself serve

134domains with HTTP/HTTPS, including with automatic TLS with ACME, is easily

135configured through both configuration files and admin web interface, and can act

136as a reverse proxy (and static file server for that matter), so you can forward

137traffic to your existing backend applications. Look for "WebHandlers:" in the

138output of "mox config describe-domains" and see the output of "mox example

141 usage: mox quickstart [-existing-webserver] [-hostname host] user@domain [user | uid]

143 use if a webserver is already running, so mox won't listen on port 80 and 443; you'll have to provide tls certificates/keys, and configure the existing webserver as reverse proxy, forwarding requests to mox.

145 hostname mox will run on, by default the hostname of the machine quickstart runs on; if specified, the IPs for the hostname are configured for the public listener

149Shut mox down, giving connections maximum 3 seconds to stop before closing them.

151While shutting down, new IMAP and SMTP connections will get a status response

152indicating temporary unavailability. Existing connections will get a 3 second

153period to finish their transaction and shut down. Under normal circumstances,

154only IMAP has long-living connections, with the IDLE command to get notified of

163The password is read from stdin. Secrets derived from the password, but not the

164password itself, are stored in the account database. The stored secrets are for

165authentication with: scram-sha-256, scram-sha-1, cram-md5, plain text (bcrypt

168The parameter is an account name, as configured under Accounts in domains.conf

169and as present in the data/accounts/ directory, not a configured email address

176Set a new admin password, for the web interface.

178The password is read from stdin. Its bcrypt hash is stored in a file named

179"adminpasswd" in the configuration directory.

185Print the log levels, or set a new default log level, or a level for the given package.

187By default, a single log level applies to all logging in mox. But for each

188"pkg", an overriding log level can be configured. Examples of packages:

189smtpserver, smtpclient, queue, imapserver, spf, dkim, dmarc, junk, message,

192Specify a pkg and an empty level to clear the configured level for a package.

194Valid labels: error, info, debug, trace, traceauth, tracedata.

202This prints the message with its ID, last and next delivery attempts, last

209Schedule matching messages in the queue for immediate delivery.

211Messages deliveries are normally attempted with exponential backoff. The first

212retry after 7.5 minutes, and doubling each time. Kicking messages sets their

213next scheduled attempt to now, it can cause delivery to fail earlier than

216With the -transport flag, future delivery attempts are done using the specified

217transport. Transports can be configured in mox.conf, e.g. to submit to a remote

220 usage: mox queue kick [-id id] [-todomain domain] [-recipient address] [-transport transport]

228 transport to use for the next delivery

232Remove matching messages from the queue.

234Dangerous operation, this completely removes the message. If you want to store

235the message, use "queue dump" before removing.

237 usage: mox queue drop [-id id] [-todomain domain] [-recipient address]

249The message is printed to stdout and is in standard internet mail format.

257The mbox/maildir archive is accessed and imported by the running mox process, so

258it must have access to the archive files. The default suggested systemd service

259file isolates mox from most of the file system, with only the "data/" directory

260accessible, so you may want to put the mbox/maildir archive files in a

261directory like "data/import/" to make it available to mox.

263By default, messages will train the junk filter based on their flags and, if

264"automatic junk flags" configuration is set, based on mailbox naming.

266If the destination mailbox is the Sent mailbox, the recipients of the messages

267are added to the message metadata, causing later incoming messages from these

268recipients to be accepted, unless other reputation signals prevent that.

270Users can also import mailboxes/messages through the account web page by

271uploading a zip or tgz file with mbox and/or maildirs.

273Mailbox flags, like "seen", "answered", will be imported. An optional

274dovecot-keywords file can specify additional flags, like Forwarded/Junk/NotJunk.

276 usage: mox import maildir accountname mailboxname maildir

282Using mbox is not recommended, maildir is a better defined format.

284The mbox/maildir archive is accessed and imported by the running mox process, so

285it must have access to the archive files. The default suggested systemd service

286file isolates mox from most of the file system, with only the "data/" directory

287accessible, so you may want to put the mbox/maildir archive files in a

288directory like "data/import/" to make it available to mox.

290By default, messages will train the junk filter based on their flags and, if

291"automatic junk flags" configuration is set, based on mailbox naming.

293If the destination mailbox is the Sent mailbox, the recipients of the messages

294are added to the message metadata, causing later incoming messages from these

295recipients to be accepted, unless other reputation signals prevent that.

297Users can also import mailboxes/messages through the account web page by

298uploading a zip or tgz file with mbox and/or maildirs.

300 usage: mox import mbox accountname mailboxname mbox

304Export one or all mailboxes from an account in maildir format.

306Export bypasses a running mox instance. It opens the account mailbox/message

307database file directly. This may block if a running mox instance also has the

308database open, e.g. for IMAP connections. To export from a running instance, use

311 usage: mox export maildir dst-dir account-path [mailbox]

315Export messages from one or all mailboxes in an account in mbox format.

317Using mbox is not recommended. Maildir is a better format.

319Export bypasses a running mox instance. It opens the account mailbox/message

320database file directly. This may block if a running mox instance also has the

321database open, e.g. for IMAP connections. To export from a running instance, use

324For mbox export, "mboxrd" is used where message lines starting with the magic

325"From " string are escaped by prepending a >. All ">*From " are escaped,

326otherwise reconstructing the original could lose a ">".

328 usage: mox export mbox dst-dir account-path [mailbox]

332Start a local SMTP/IMAP server that accepts all messages, useful when testing/developing software that sends email.

334Localserve starts mox with a configuration suitable for local email-related

335software development/testing. It listens for SMTP/Submission(s), IMAP(s) and

336HTTP(s), on the regular port numbers + 1000.

338Data is stored in the system user's configuration directory under

339"mox-localserve", e.g. $HOME/.config/mox-localserve/ on linux, but can be

340overridden with the -dir flag. If the directory does not yet exist, it is

341automatically initialized with configuration files, an account with email

342address mox@localhost and password moxmoxmox, and a newly generated self-signed

345All incoming email to any address is accepted (if checks pass), unless the

348- "temperror": fail with a temporary error code

349- "permerror": fail with a permanent error code

350- [45][0-9][0-9]: fail with the specific error code

353If the localpart begins with "mailfrom" or "rcptto", the error is returned

354during those commands instead of during "data".

358 configuration storage directory (default "$userconfigdir/mox-localserve")

362 serve on this ip instead of default 127.0.0.1 and ::1. only used when writing configuration, at first launch.

368If multiple commands match, they are listed along with the first line of their help text.

369If a single command matches, its usage and full help text is printed.

375Creates a backup of the data directory.

377Backup creates consistent snapshots of the databases and message files and

378copies other files in the data directory. Empty directories are not copied.

379These files can then be stored elsewhere for long-term storage, or used to fall

380back to should an upgrade fail. Simply copying files in the data directory

381while mox is running can result in unusable database files.

383Message files never change (they are read-only, though can be removed) and are

384hard-linked so they don't consume additional space. If hardlinking fails, for

385example when the backup destination directory is on a different file system, a

386regular copy is made. Using a destination directory like "data/tmp/backup"

387increases the odds hardlinking succeeds: the default systemd service file

388specifically mounts the data directory, causing attempts to hardlink outside it

389to fail with an error about cross-device linking.

391All files in the data directory that aren't recognized (i.e. other than known

392database files, message files, an acme directory, the "tmp" directory, etc),

395A clean successful backup does not print any output by default. Use the

396-verbose flag for details, including timing.

398To restore a backup, first shut down mox, move away the old data directory and

399move an earlier backed up directory in its place, run "mox verifydata",

400possibly with the "-fix" option, and restart mox. After the restore, you may

401also want to run "mox bumpuidvalidity" for each account for which messages in a

402mailbox changed, to force IMAP clients to synchronize mailbox state.

404Before upgrading, to check if the upgrade will likely succeed, first make a

405backup, then use the new mox binary to run "mox verifydata" on the backup. This

406can change the backup files (e.g. upgrade database files, move away

407unrecognized message files), so you should make a new backup before actually

416Verify the contents of a data directory, typically of a backup.

418Verifydata checks all database files to see if they are valid BoltDB/bstore

419databases. It checks that all messages in the database have a corresponding

420on-disk message file and there are no unrecognized files. If option -fix is

421specified, unrecognized message files are moved away. This may be needed after

422a restore, because messages enqueued or delivered in the future may get those

423message sequence numbers assigned and writing the message file would fail.

424Consistency of message/mailbox UID, UIDNEXT and UIDVALIDITY is verified as

427Because verifydata opens the database files, schema upgrades may automatically

428be applied. This can happen if you use a new mox release. It is useful to run

429"mox verifydata" with a new binary before attempting an upgrade, but only on a

430copy of the database files, as made with "mox backup". Before upgrading, make a

431new backup again since "mox verifydata" may have upgraded the database files,

432possibly making them potentially no longer readable by the previous version.

436 fix fixable problems, such as moving away message files not referenced by their database

442Parses and validates the configuration files.

444If valid, the command exits with status 0. If not valid, all errors encountered

451Check the DNS records with the configuration for the domain, and print any errors/warnings.

457Prints annotated DNS records as zone file that should be created for the domain.

459The zone file can be imported into existing DNS software. You should review the

460DNS records, especially if your domain previously/currently has email

467Prints an annotated empty configuration for use as domains.conf.

469The domains configuration file contains the domains and their configuration,

470and accounts and their configuration. This includes the configured email

471addresses. The mox admin web interface, and the mox command line interface, can

472make changes to this file. Mox automatically reloads this file when it changes.

474Like the static configuration, the example domains.conf printed by this command

477 usage: mox config describe-domains >domains.conf

481Prints an annotated empty configuration for use as mox.conf.

483The static configuration file cannot be reloaded while mox is running. Mox has

484to be restarted for changes to the static configuration file to take effect.

486This configuration file needs modifications to make it valid. For example, it

489 usage: mox config describe-static >mox.conf

493Add an account with an email address and reload the configuration.

495Email can be delivered to this address/account. A password has to be configured

496explicitly, see the setaccountpassword command.

498 usage: mox config account add account address

502Remove an account and reload the configuration.

504Email addresses for this account will also be removed, and incoming email for

511Adds an address to an account and reloads the configuration.

513If address starts with a @ (i.e. a missing localpart), this is a catchall

516 usage: mox config address add address account

520Remove an address and reload the configuration.

522Incoming email for this address will be rejected after removing an address.

528Adds a new domain to the configuration and reloads the configuration.

530The account is used for the postmaster mailboxes the domain, including as DMARC and

531TLS reporting. Localpart is the "username" at the domain for this account. If

532must be set if and only if account does not yet exist.

534 usage: mox config domain add domain account [localpart]

538Remove a domain from the configuration and reload the configuration.

540This is a dangerous operation. Incoming email delivery for this domain will be

547Describe configuration for mox when invoked as sendmail.

549 usage: mox config describe-sendmail >/etc/moxsubmit.conf

553Prints a systemd unit service file for mox.

555This is the same file as generated using quickstart. If the systemd service file

556has changed with a newer version of mox, use this command to generate an up to

559 usage: mox config printservice >mox.service

563Ensure host private keys exist for TLS listeners with ACME.

565In mox.conf, each listener can have TLS configured. Long-lived private key files

566can be specified, which will be used when requesting ACME certificates.

567Configuring these private keys makes it feasible to publish DANE TLSA records

568for the corresponding public keys in DNS, protected with DNSSEC, allowing TLS

569certificate verification without depending on a list of Certificate Authorities

570(CAs). Previous versions of mox did not pre-generate private keys for use with

571ACME certificates, but would generate private keys on-demand. By explicitly

572configuring private keys, they will not change automatedly with new

573certificates, and the DNS TLSA records stay valid.

575This command looks for listeners in mox.conf with TLS with ACME configured. For

576each missing host private key (of type rsa-2048 and ecdsa-p256) a key is written

577to config/hostkeys/. If a certificate exists in the ACME "cache", its private

578key is copied. Otherwise a new private key is generated. Snippets for manually

581After running this command, and updating mox.conf, run "mox config dnsrecords"

582for a domain and create the TLSA DNS records it suggests to enable DANE.

584 usage: mox config ensureacmehostprivatekeys

588List available examples, or print a specific example.

594Check if a newer version of mox is available.

596A single DNS TXT lookup to _updates.xmox.nl tells if a new version is

597available. If so, a changelog is fetched from https://updates.xmox.nl, and the

598individual entries verified with a builtin public key. The changelog is

605Turn an ID from a Received header into a cid, for looking up in logs.

607A cid is essentially a connection counter initialized when mox starts. Each log

608line contains a cid. Received headers added by mox contain a unique ID that can

609be decrypted to a cid by admin of a mox instance only.

615Print the configuration for email clients for a domain.

617Sending email is typically not done on the SMTP port 25, but on submission

618ports 465 (with TLS) and 587 (without initial TLS, but usually added to the

619connection with STARTTLS). For IMAP, the port with TLS is 993 and without is

622Without TLS/STARTTLS, passwords are sent in clear text, which should only be

623configured over otherwise secured connections, like a VPN.

629Dial the address using TLS with certificate verification using DANE.

631Data is copied between connection and stdin/stdout until either side closes the

636 allowed usages for dane, comma-separated list (default "pkix-ta,pkix-ee,dane-ta,dane-ee")

640Connect to MX server for domain using STARTTLS verified with DANE.

642If no destination host is specified, regular delivery logic is used to find the

643hosts to attempt delivery too. This involves following CNAMEs for the domain,

644looking up MX records, and possibly falling back to the domain name itself as

647If a destination host is specified, that is the only candidate host considered

650With a list of destinations gathered, each is dialed until a successful SMTP

651session verified with DANE has been initialized, including EHLO and STARTTLS

654Once connected, data is copied between connection and stdin/stdout, until

657This command follows the same logic as delivery attempts made from the queue,

660 usage: mox dane dialmx domain [destination-host]

662 hostname to send in smtp ehlo command (default "localhost")

666Print TLSA record for given certificate/key and parameters.

669- usage: pkix-ta (0), pkix-ee (1), dane-ta (2), dane-ee (3)

671- matchtype: full (0), sha2-256 (1), sha2-512 (2)

673Common DANE TLSA record parameters are: dane-ee spki sha2-256, or 3 1 1,

674followed by a sha2-256 hash of the DER-encoded "SPKI" (subject public key info)

675from the certificate. An example DNS zone file entry:

677 _25._tcp.example.com. TLSA 3 1 1 133b919c9d65d8b1488157315327334ead8d83372db57465ecabf53ee5748aee

679The first usable information from the pem file is used to compose the TLSA

680record. In case of selector "cert", a certificate is required. Otherwise the

681"subject public key info" (spki) of the first certificate or public or private

682key (pkcs#8, pkcs#1 or ec private key) is used.

684 usage: mox dane makerecord usage selector matchtype [certificate.pem | publickey.pem | privatekey.pem]

690Lookup always prints whether the response was DNSSEC-protected.

699 usage: mox dns lookup [ptr | mx | cname | ips | a | aaaa | ns | txt | srv | tlsa] name

703Generate a new ed25519 key for use with DKIM.

705Ed25519 keys are much smaller than RSA keys of comparable cryptographic

706strength. This is convenient because of maximum DNS message sizes. At the time

707of writing, not many mail servers appear to support ed25519 DKIM keys though,

708so it is recommended to sign messages with both RSA and ed25519 keys.

710 usage: mox dkim gened25519 >$selector._domainkey.$domain.ed25519.privatekey.pkcs8.pem

714Generate a new 2048 bit RSA private key for use with DKIM.

716The generated file is in PEM format, and has a comment it is generated for use

719 usage: mox dkim genrsa >$selector._domainkey.$domain.rsa2048.privatekey.pkcs8.pem

723Lookup and print the DKIM record for the selector at the domain.

725 usage: mox dkim lookup selector domain

729Print a DKIM DNS TXT record with the public key derived from the private key read from stdin.

731The DNS should be configured as a TXT record at $selector._domainkey.$domain.

733 usage: mox dkim txt <$selector._domainkey.$domain.key.pkcs8.pem

737Verify the DKIM signatures in a message and print the results.

739The message is parsed, and the DKIM-Signature headers are validated. Validation

740of older messages may fail because the DNS records have been removed or changed

741by now, or because the signature header may have specified an expiration time

748Sign a message, adding DKIM-Signature headers based on the domain in the From header.

750The message is parsed, the domain looked up in the configuration files, and

751DKIM-Signature headers generated. The message is printed with the DKIM-Signature

758Lookup dmarc policy for domain, a DNS TXT record at _dmarc.<domain>, validate and print it.

764Parse a DMARC report from an email message, and print its extracted details.

766DMARC reports are periodically mailed, if requested in the DMARC DNS record of

767a domain. Reports are sent by mail servers that received messages with our

768domain in a From header. This may or may not be legatimate email. DMARC reports

769contain summaries of evaluations of DMARC and DKIM/SPF, which can help

770understand email deliverability problems.

772 usage: mox dmarc parsereportmsg message ...

776Parse an email message and evaluate it against the DMARC policy of the domain in the From-header.

778mailfromaddress and helodomain are used for SPF validation. If both are empty,

781mailfromaddress should be the address used as MAIL FROM in the SMTP session.

782For DSN messages, that address may be empty. The helo domain was specified at

783the beginning of the SMTP transaction that delivered the message. These values

786 usage: mox dmarc verify remoteip mailfromaddress helodomain < message

790For each reporting address in the domain's DMARC record, check if it has opted into receiving reports (if needed).

792A DMARC record can request reports about DMARC evaluations to be sent to an

793email/http address. If the organizational domains of that of the DMARC record

794and that of the report destination address do not match, the destination

795address must opt-in to receiving DMARC reports by creating a DMARC record at

796<dmarcdomain>._report._dmarc.<reportdestdomain>.

798 usage: mox dmarc checkreportaddrs domain

802Test if IP is in the DNS blocklist of the zone, e.g. bl.spamcop.net.

804If the IP is in the blocklist, an explanation is printed. This is typically a

811Check the health of the DNS blocklist represented by zone, e.g. bl.spamcop.net.

813The health of a DNS blocklist can be checked by querying for 127.0.0.1 and

814127.0.0.2. The second must and the first must not be present.

820Lookup the MTASTS record and policy for the domain.

822MTA-STS is a mechanism for a domain to specify if it requires TLS connections

823for delivering email. If a domain has a valid MTA-STS DNS TXT record at

824_mta-sts.<domain> it signals it implements MTA-STS. A policy can then be

825fetched at https://mta-sts.<domain>/.well-known/mta-sts.txt. The policy

826specifies the mode (enforce, testing, none), which MX servers support TLS and

827should be used, and how long the policy can be cached.

833Recreate and retrain the junk filter for the account.

835Useful after having made changes to the junk filter configuration, or if the

842Sendmail is a drop-in replacement for /usr/sbin/sendmail to deliver emails sent by unix processes like cron.

844If invoked as "sendmail", it will act as sendmail for sending messages. Its

845intention is to let processes like cron send emails. Messages are submitted to

846an actual mail server over SMTP. The destination mail server and credentials are

847configured in /etc/moxsubmit.conf, see mox config describe-sendmail. The From

848message header is rewritten to the configured address. When the addressee

849appears to be a local user, because without @, the message is sent to the

852If submitting an email fails, it is added to a directory moxsubmit.failures in

855Most flags are ignored to fake compatibility with other sendmail

856implementations. A single recipient or the -t flag with a To-header is required.

857With the -t flag, Cc and Bcc headers are not handled specially, so Bcc is not

858removed and the addresses do not receive the email.

860/etc/moxsubmit.conf should be group-readable and not readable by others and this

864 install -m 2755 -o root -g moxsubmit mox /usr/sbin/sendmail

866 chown root:moxsubmit /etc/moxsubmit.conf

871 usage: mox sendmail [-Fname] [ignoredflags] [-t] [<message]

875Check the status of IP for the policy published in DNS for the domain.

877IPs may be allowed to send for a domain, or disallowed, and several shades in

878between. If not allowed, an explanation may be provided by the policy. If so,

879the explanation is printed. The SPF mechanism that matched (if any) is also

886Lookup the SPF record for the domain and print it.

892Parse the record as SPF record. If valid, nothing is printed.

898Lookup the TLSRPT record for the domain.

900A TLSRPT record typically contains an email address where reports about TLS

901connectivity should be sent. Mail servers attempting delivery to our domain

902should attempt to use TLS. TLSRPT lets them report how many connection

903successfully used TLS, and how what kind of errors occurred otherwise.

909Parse and print the TLSRPT in the message.

911The report is printed in formatted JSON.

913 usage: mox tlsrpt parsereportmsg message ...

923Change the IMAP UID validity of the mailbox, causing IMAP clients to refetch messages.

925This can be useful after manually repairing metadata about the account/mailbox.

927Opens account database file directly. Ensure mox does not have the account

930 usage: mox bumpuidvalidity account [mailbox]

934Reassign UIDs in one mailbox or all mailboxes in an account and bump UID validity, causing IMAP clients to refetch messages.

936Opens account database file directly. Ensure mox does not have the account

939 usage: mox reassignuids account [mailboxid]

943Fix inconsistent UIDVALIDITY and UIDNEXT in messages/mailboxes/account.

945The next UID to use for a message in a mailbox should always be higher than any

946existing message UID in the mailbox. If it is not, the mailbox UIDNEXT is

949Each mailbox has a UIDVALIDITY sequence number, which should always be lower

950than the per-account next UIDVALIDITY to use. If it is not, the account next

953Opens account database file directly. Ensure mox does not have the account

960Ensure message sizes in the database matching the sum of the message prefix length and on-disk file size.

962Messages with an inconsistent size are also parsed again.

964If an inconsistency is found, you should probably also run "mox

965bumpuidvalidity" on the mailboxes or entire account to force IMAP clients to

972# Parse all messages in the account or all accounts again

974Can be useful after upgrading mox with improved message parsing. Messages are

975parsed in batches, so other access to the mailboxes/messages are not blocked

982Ensure messages in the database have a pre-parsed MIME form in the database.

986 store new parsed message for all messages

990Recalculate message counts for all mailboxes in the account, and total message size for quota.

992When a message is added to/removed from a mailbox, or when message flags change,

993the total, unread, unseen and deleted messages are accounted, the total size of

994the mailbox, and the total message size for the account. In case of a bug in

995this accounting, the numbers could become incorrect. This command will find, fix

998 usage: mox recalculatemailboxcounts account

1002Parse message, print JSON representation.

1010For all accounts, or optionally only the specified account.

1012Threading for all messages in an account is first reset, and new base subject

1013and normalized message-id saved with the message. Then all messages are

1014evaluated and matched against their parents/ancestors.

1016Messages are matched based on the References header, with a fall-back to an

1017In-Reply-To header, and if neither is present/valid, based only on base

1020A References header typically points to multiple previous messages in a

1021hierarchy. From oldest ancestor to most recent parent. An In-Reply-To header

1022would have only a message-id of the parent message.

1024A message is only linked to a parent/ancestor if their base subject is the

1025same. This ensures unrelated replies, with a new subject, are placed in their

1028The base subject is lower cased, has whitespace collapsed to a single

1029space, and some components removed: leading "Re:", "Fwd:", "Fw:", or bracketed

1030tag (that mailing lists often add, e.g. "[listname]"), trailing "(fwd)", or

1033Messages are linked to all their ancestors. If an intermediate parent/ancestor

1034message is deleted in the future, the message can still be linked to the earlier

1035ancestors. If the direct parent already wasn't available while matching, this is

1036stored as the message having a "missing link" to its stored ancestors.

1042// NOTE: DO NOT EDIT, this file is generated by gendoc.sh.