mox/testdata/smtp/domains.conf

Domains:
	mox.example:
		Aliases:
			public:
				Addresses:
					- mjl@mox.example
					- móx@mox.example
				PostPublic: true
				AllowMsgFrom: true
			private:
				Addresses:
					- mjl@mox.example
					- móx@mox.example
	mox2.example: nil
Accounts:
	mjl:
		Domain: mox.example
		Destinations:
			mjl@mox.example: nil
			mjl@mox2.example: nil
			""@mox.example: nil
			# ascii o, we'll check that greek & cyrillic lookalike isn't accepted
			o@mox.example: nil
			# ohm sign, \u2126
			Ω@mox.example: nil
			móx@mox.example: nil
		JunkFilter:
			Threshold: 0.9
			Params:
				Onegrams: true
				MaxPower: 0.01
				TopWords: 10
				IgnoreWords: 0.1
				RareWords: 2
	# not a member of an alias.
	☺:
		Domain: mox.example
		Destinations:
			☺@mox.example: nil
mox! 2023-01-30 16:27:06 +03:00			`Domains:`
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			`mox.example:`
			`Aliases:`
			`public:`
			`Addresses:`
			`- mjl@mox.example`
			`- móx@mox.example`
			`PostPublic: true`
			`AllowMsgFrom: true`
			`private:`
			`Addresses:`
			`- mjl@mox.example`
			`- móx@mox.example`
bugfix: when dkim-signing submitted messages, use the domain from the "message from header" instead of "smtp mail from" dmarc verifiers will only accept a dkim signature if the domain the message From header matches the domain of the signature (i.e. it is "aligned"). i hadn't run into this before and when testing because thunderbird sets the "smtp mail from" to the same address as a custom "message from" header. but other mail clients don't have to do that. should fix issue #22 2023-03-30 11:38:36 +03:00			`mox2.example: nil`
mox! 2023-01-30 16:27:06 +03:00			`Accounts:`
			`mjl:`
			`Domain: mox.example`
			`Destinations:`
deprecate having only localparts in an Account's Destinations, it should always be a full email address current behaviour isn't intuitive. it's not great to have to attempt parsing the strings as both localpart and email address. so we deprecate the localpart-only behaviour. when we load the config file, and it has localpart-only Destinations keys, we'll change them to full addresses in memory. when an admin causes a write of domains.conf, it'll automatically be fixed. we log an error with a deprecated notice for each localpart-only destinations key. sometime in the future, we can remove the old localpart-only destination support. will be in the release notes then. also start keeping track of update notes that need to make it in the release notes of the next release. for issue #18 2023-03-10 00:07:37 +03:00			`mjl@mox.example: nil`
bugfix: when dkim-signing submitted messages, use the domain from the "message from header" instead of "smtp mail from" dmarc verifiers will only accept a dkim signature if the domain the message From header matches the domain of the signature (i.e. it is "aligned"). i hadn't run into this before and when testing because thunderbird sets the "smtp mail from" to the same address as a custom "message from" header. but other mail clients don't have to do that. should fix issue #22 2023-03-30 11:38:36 +03:00			`mjl@mox2.example: nil`
fix delivery from/to smtp addresses with double quotes found while adding tests for smtp and imap for address with empty double (double quoted) localparts. 2023-06-03 16:29:18 +03:00			`""@mox.example: nil`
normalize localparts with unicode nfc when parsing both when parsing our configs, and for incoming on smtp or in messages. so we properly compare things like é and e+accent as equal, and accept the different encodings of that same address. 2024-03-08 23:08:40 +03:00			`# ascii o, we'll check that greek & cyrillic lookalike isn't accepted`
			`o@mox.example: nil`
			`# ohm sign, \u2126`
			`Ω@mox.example: nil`
prevent unicode-confusion in password by applying PRECIS, and username/email address by applying unicode NFC normalization an é (e with accent) can also be written as e+\u0301. the first form is NFC, the second NFD. when logging in, we transform usernames (email addresses) to NFC. so both forms will be accepted. if a client is using NFD, they can log in too. for passwords, we apply the PRECIS "opaquestring", which (despite the name) transforms the value too: unicode spaces are replaced with ascii spaces. the string is also normalized to NFC. PRECIS may reject confusing passwords when you set a password. 2024-03-09 01:29:15 +03:00			`móx@mox.example: nil`
mox! 2023-01-30 16:27:06 +03:00			`JunkFilter:`
			`Threshold: 0.9`
			`Params:`
			`Onegrams: true`
			`MaxPower: 0.01`
			`TopWords: 10`
			`IgnoreWords: 0.1`
			`RareWords: 2`
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			`# not a member of an alias.`
			`☺:`
			`Domain: mox.example`
			`Destinations:`
			`☺@mox.example: nil`