mirror of
https://github.com/mjl-/mox.git
synced 2024-12-26 16:33:47 +03:00
09fcc49223
for applications to compose/send messages, receive delivery feedback, and maintain suppression lists. this is an alternative to applications using a library to compose messages, submitting those messages using smtp, and monitoring a mailbox with imap for DSNs, which can be processed into the equivalent of suppression lists. but you need to know about all these standards/protocols and find libraries. by using the webapi & webhooks, you just need a http & json library. unfortunately, there is no standard for these kinds of api, so mox has made up yet another one... matching incoming DSNs about deliveries to original outgoing messages requires keeping history of "retired" messages (delivered from the queue, either successfully or failed). this can be enabled per account. history is also useful for debugging deliveries. we now also keep history of each delivery attempt, accessible while still in the queue, and kept when a message is retired. the queue webadmin pages now also have pagination, to show potentially large history. a queue of webhook calls is now managed too. failures are retried similar to message deliveries. webhooks can also be saved to the retired list after completing. also configurable per account. messages can be sent with a "unique smtp mail from" address. this can only be used if the domain is configured with a localpart catchall separator such as "+". when enabled, a queued message gets assigned a random "fromid", which is added after the separator when sending. when DSNs are returned, they can be related to previously sent messages based on this fromid. in the future, we can implement matching on the "envid" used in the smtp dsn extension, or on the "message-id" of the message. using a fromid can be triggered by authenticating with a login email address that is configured as enabling fromid. suppression lists are automatically managed per account. if a delivery attempt results in certain smtp errors, the destination address is added to the suppression list. future messages queued for that recipient will immediately fail without a delivery attempt. suppression lists protect your mail server reputation. submitted messages can carry "extra" data through the queue and webhooks for outgoing deliveries. through webapi as a json object, through smtp submission as message headers of the form "x-mox-extra-<key>: value". to make it easy to test webapi/webhooks locally, the "localserve" mode actually puts messages in the queue. when it's time to deliver, it still won't do a full delivery attempt, but just delivers to the sender account. unless the recipient address has a special form, simulating a failure to deliver. admins now have more control over the queue. "hold rules" can be added to mark newly queued messages as "on hold", pausing delivery. rules can be about certain sender or recipient domains/addresses, or apply to all messages pausing the entire queue. also useful for (local) testing. new config options have been introduced. they are editable through the admin and/or account web interfaces. the webapi http endpoints are enabled for newly generated configs with the quickstart, and in localserve. existing configurations must explicitly enable the webapi in mox.conf. gopherwatch.org was created to dogfood this code. it initially used just the compose/smtpclient/imapclient mox packages to send messages and process delivery feedback. it will get a config option to use the mox webapi/webhooks instead. the gopherwatch code to use webapi/webhook is smaller and simpler, and developing that shaped development of the mox webapi/webhooks. for issue #31 by cuu508
120 lines
3 KiB
Bash
Executable file
120 lines
3 KiB
Bash
Executable file
#!/usr/bin/env sh
|
|
|
|
# ./doc.go
|
|
(
|
|
cat <<EOF
|
|
/*
|
|
Command mox is a modern, secure, full-featured, open source mail server for
|
|
low-maintenance self-hosted email.
|
|
|
|
Mox is started with the "serve" subcommand, but mox also has many other
|
|
subcommands.
|
|
|
|
Many of those commands talk to a running mox instance, through the ctl file in
|
|
the data directory. Specify the configuration file (that holds the path to the
|
|
data directory) through the -config flag or MOXCONF environment variable.
|
|
|
|
Commands that don't talk to a running mox instance are often for
|
|
testing/debugging email functionality. For example for parsing an email message,
|
|
or looking up SPF/DKIM/DMARC records.
|
|
|
|
Below is the usage information as printed by the command when started without
|
|
any parameters. Followed by the help and usage information for each command.
|
|
|
|
|
|
# Usage
|
|
|
|
EOF
|
|
|
|
./mox 2>&1 | sed -e 's/^usage: */\t/' -e 's/^ */\t/'
|
|
echo
|
|
./mox helpall 2>&1
|
|
|
|
cat <<EOF
|
|
*/
|
|
package main
|
|
|
|
// NOTE: DO NOT EDIT, this file is generated by gendoc.sh.
|
|
EOF
|
|
)>doc.go
|
|
gofmt -w doc.go
|
|
|
|
# ./config/doc.go
|
|
(
|
|
cat <<EOF
|
|
/*
|
|
Package config holds the configuration file definitions.
|
|
|
|
Mox uses two config files:
|
|
|
|
1. mox.conf, also called the static configuration file.
|
|
2. domains.conf, also called the dynamic configuration file.
|
|
|
|
The static configuration file is never reloaded during the lifetime of a
|
|
running mox instance. After changes to mox.conf, mox must be restarted for the
|
|
changes to take effect.
|
|
|
|
The dynamic configuration file is reloaded automatically when it changes.
|
|
If the file contains an error after the change, the reload is aborted and the
|
|
previous version remains active.
|
|
|
|
Below are "empty" config files, generated from the config file definitions in
|
|
the source code, along with comments explaining the fields. Fields named "x" are
|
|
placeholders for user-chosen map keys.
|
|
|
|
# sconf
|
|
|
|
The config files are in "sconf" format. Properties of sconf files:
|
|
|
|
- Indentation with tabs only.
|
|
- "#" as first non-whitespace character makes the line a comment. Lines with a
|
|
value cannot also have a comment.
|
|
- Values don't have syntax indicating their type. For example, strings are
|
|
not quoted/escaped and can never span multiple lines.
|
|
- Fields that are optional can be left out completely. But the value of an
|
|
optional field may itself have required fields.
|
|
|
|
See https://pkg.go.dev/github.com/mjl-/sconf for details.
|
|
|
|
|
|
# mox.conf
|
|
|
|
EOF
|
|
./mox config describe-static | sed 's/^/\t/'
|
|
|
|
cat <<EOF
|
|
|
|
# domains.conf
|
|
|
|
EOF
|
|
./mox config describe-domains | sed 's/^/\t/'
|
|
|
|
cat <<EOF
|
|
|
|
# Examples
|
|
|
|
Mox includes configuration files to illustrate common setups. You can see these
|
|
examples with "mox config example", and print a specific example with "mox
|
|
config example <name>". Below are all examples included in mox.
|
|
|
|
EOF
|
|
|
|
for ex in $(./mox config example); do
|
|
echo '# Example '$ex
|
|
echo
|
|
./mox config example $ex | sed 's/^/\t/'
|
|
echo
|
|
done
|
|
|
|
cat <<EOF
|
|
*/
|
|
package config
|
|
|
|
// NOTE: DO NOT EDIT, this file is generated by ../gendoc.sh.
|
|
EOF
|
|
)>config/doc.go
|
|
gofmt -w config/doc.go
|
|
|
|
# ./webapi/doc.go
|
|
./webapi/gendoc.sh >webapi/doc.go
|
|
gofmt -w webapi/doc.go
|