mox/testdata/queue/mox.conf

DataDir: data
LogLevel: trace
User: 1000
Hostname: mox.example
Listeners:
	local: nil
Postmaster:
	Account: mjl
	Mailbox: postmaster
Transports:
	submit:
		Submission:
			# Dial of host is intercepted in tests.
			Host: submission.example
			NoSTARTTLS: true
			Auth:
				Username: test
				Password: test1234
				Mechanisms:
					- PLAIN
	submittls:
		Submissions:
			# Dial of host is intercepted in tests.
			Host: submission.example
			Auth:
				Username: test
				Password: test1234
				Mechanisms:
					- PLAIN
	socks:
		Socks:
			# Address is replaced during tests.
			Address: localhost:1234
			RemoteIPs:
				- 127.0.0.1
			RemoteHostname: localhost
mox! 2023-01-30 16:27:06 +03:00			`DataDir: data`
			`LogLevel: trace`
do not require a user "mox" to be present for tests uid 1000 doesn't actually have to be present (except for the special imaptest), but this prevents looking up the user named mox. 2023-02-27 16:54:16 +03:00			`User: 1000`
mox! 2023-01-30 16:27:06 +03:00			`Hostname: mox.example`
			`Listeners:`
			`local: nil`
			`Postmaster:`
			`Account: mjl`
			`Mailbox: postmaster`
new feature: when delivering messages from the queue, make it possible to use a "transport" the default transport is still just "direct delivery", where we connect to the destination domain's MX servers. other transports are: - regular smtp without authentication, this is relaying to a smarthost. - submission with authentication, e.g. to a third party email sending service. - direct delivery, but with with connections going through a socks proxy. this can be helpful if your ip is blocked, you need to get email out, and you have another IP that isn't blocked. keep in mind that for all of the above, appropriate SPF/DKIM settings have to be configured. the "dnscheck" for a domain does a check for any SOCKS IP in the SPF record. SPF for smtp/submission (ranges? includes?) and any DKIM requirements cannot really be checked. which transport is used can be configured through routes. routes can be set on an account, a domain, or globally. the routes are evaluated in that order, with the first match selecting the transport. these routes are evaluated for each delivery attempt. common selection criteria are recipient domain and sender domain, but also which delivery attempt this is. you could configured mox to attempt sending through a 3rd party from the 4th attempt onwards. routes and transports are optional. if no route matches, or an empty/zero transport is selected, normal direct delivery is done. we could already "submit" emails with 3rd party accounts with "sendmail". but we now support more SASL authentication mechanisms with SMTP (not only PLAIN, but also SCRAM-SHA-256, SCRAM-SHA-1 and CRAM-MD5), which sendmail now also supports. sendmail will use the most secure mechanism supported by the server, or the explicitly configured mechanism. for issue #36 by dmikushin. also based on earlier discussion on hackernews. 2023-06-16 19:38:28 +03:00			`Transports:`
			`submit:`
			`Submission:`
			`# Dial of host is intercepted in tests.`
			`Host: submission.example`
			`NoSTARTTLS: true`
			`Auth:`
			`Username: test`
			`Password: test1234`
			`Mechanisms:`
			`- PLAIN`
			`submittls:`
			`Submissions:`
			`# Dial of host is intercepted in tests.`
			`Host: submission.example`
			`Auth:`
			`Username: test`
			`Password: test1234`
			`Mechanisms:`
			`- PLAIN`
			`socks:`
			`Socks:`
			`# Address is replaced during tests.`
			`Address: localhost:1234`
			`RemoteIPs:`
			`- 127.0.0.1`
			`RemoteHostname: localhost`