mox/testdata/ctl/domains.conf

Domains:
	mox.example: nil
Accounts:
	mjl:
		OutgoingWebhook:
			URL: http://localhost:1234
		KeepRetiredMessagePeriod: 1h0m0s
		KeepRetiredWebhookPeriod: 1h0m0s
		Domain: mox.example
		Destinations:
			mjl2@mox.example: nil
			mjl@mox.example: nil
add basic tests for the ctl subcommands, and fix two small bugs this doesn't really test the output of the ctl commands, just that they succeed without error. better than nothing... testing found two small bugs, that are not an issue in practice: 1. we were ack'ing streamed data from the other side of the ctl connection before having read it. when there is no buffer space on the connection (always the case for net.Pipe) that would cause a deadlock. only actually happened during the new tests. 2. the generated dkim keys are relatively to the directory of the dynamic config file. mox looked it up relative to the directory of the _static_ config file at startup. this directory is typicaly the same. users would have noticed if they had triggered this. 2023-07-02 14:53:34 +03:00			`Domains:`
			`mox.example: nil`
			`Accounts:`
			`mjl:`
add a webapi and webhooks for a simple http/json-based api 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 2024-04-15 22:49:02 +03:00			`OutgoingWebhook:`
			`URL: http://localhost:1234`
			`KeepRetiredMessagePeriod: 1h0m0s`
			`KeepRetiredWebhookPeriod: 1h0m0s`
add basic tests for the ctl subcommands, and fix two small bugs this doesn't really test the output of the ctl commands, just that they succeed without error. better than nothing... testing found two small bugs, that are not an issue in practice: 1. we were ack'ing streamed data from the other side of the ctl connection before having read it. when there is no buffer space on the connection (always the case for net.Pipe) that would cause a deadlock. only actually happened during the new tests. 2. the generated dkim keys are relatively to the directory of the dynamic config file. mox looked it up relative to the directory of the _static_ config file at startup. this directory is typicaly the same. users would have noticed if they had triggered this. 2023-07-02 14:53:34 +03:00			`Domain: mox.example`
			`Destinations:`
add aliases/lists: when sending to an alias, the message gets delivered to all members the members must currently all be addresses of local accounts. a message sent to an alias is accepted if at least one of the members accepts it. if no members accepts it (e.g. due to bad reputation of sender), the message is rejected. if a message is submitted to both an alias addresses and to recipients that are members of the alias in an smtp transaction, the message will be delivered to such members only once. the same applies if the address in the message from-header is the address of a member: that member won't receive the message (they sent it). this prevents duplicate messages. aliases have three configuration options: - PostPublic: whether anyone can send through the alias, or only members. members-only lists can be useful inside organizations for internal communication. public lists can be useful for support addresses. - ListMembers: whether members can see the addresses of other members. this can be seen in the account web interface. in the future, we could export this in other ways, so clients can expand the list. - AllowMsgFrom: whether messages can be sent through the alias with the alias address used in the message from-header. the webmail knows it can use that address, and will use it as from-address when replying to a message sent to that address. ideas for the future: - allow external addresses as members. still with some restrictions, such as requiring a valid dkim-signature so delivery has a chance to succeed. will also need configuration of an admin that can receive any bounces. - allow specifying specific members who can sent through the list (instead of all members). for github issue #57 by hmfaysal. also relevant for #99 by naturalethic. thanks to damir & marin from sartura for discussing requirements/features. 2024-04-24 20:15:30 +03:00			`mjl2@mox.example: nil`
add basic tests for the ctl subcommands, and fix two small bugs this doesn't really test the output of the ctl commands, just that they succeed without error. better than nothing... testing found two small bugs, that are not an issue in practice: 1. we were ack'ing streamed data from the other side of the ctl connection before having read it. when there is no buffer space on the connection (always the case for net.Pipe) that would cause a deadlock. only actually happened during the new tests. 2. the generated dkim keys are relatively to the directory of the dynamic config file. mox looked it up relative to the directory of the _static_ config file at startup. this directory is typicaly the same. users would have noticed if they had triggered this. 2023-07-02 14:53:34 +03:00			`mjl@mox.example: nil`