transactional email only mode

[shleeable]

Hello mox team,

I run a mastodon / pixelfed instance and I pay a saas provider a few coins to send our transactional emails.

I'd love to move to mox or similar to connect my fediverse instance to a email server I control.

Once the domain is trusted, I could offer the free email hosting to other fediverse email providers.

Does that fit the mox model/usecase? I have no intention of ever receiving an email from this service.

[mjl-]

It will already work to some extent, but the current domain configuration settings are geared towards having regular accounts that also receive email. But I consider it part of mox goals to make it easy to run your own mail server for sending transactional email.

For what it's worth, I use mox to send transactional emails for https://www.gopherwatch.org. I created gopherwatch to get input on what transactional email needs, which helped design the simple webapi to send transactional emails (though regular SMTP works fine too, and that's probably the best way to keep sending email), and helped design the webhook callsbacks for delivery events (failed/succeeded). And I know of other people that use mox to send transactional email.

Mox doesn't have a high-level view of statistics for number of sent/delivered/bounces like shown in the screenshot. But mox does have queue management where you can see retired messages (sent/delivered). Mox may already have enough information in its database to render a similar page.

Mox doesn't have multitenancy at the moment. Will probably come in the future. But it means there is currently a single admin account that is making all the changes. You can't assign control over a domain to a user. This currently includes access to/control over the queue with messages coming from the domain.

About not receiving email. A typical way to send transactional emails is to send with a "message from"-address of something like noreply@$domain. In mox, you can only send email with a certain "msgfrom"-address if the address is configured in your account. And that means you will also get replies. For me this hasn't been troublesome, but perhaps at really high volumes of email it will be. Anyway, mox could get a config option to make this possible. It's already possible to get this effect: Add $domain to mox, also add somesubdomain.$domain to mox, create an account with two addresses, one at each domain, and send messages with an smtp mail from (envelope from) address of noreply@somesubdomain.$domain, and with a msgfrom address noreply@$domain, and just don't point the MX records for $domain to mox, but only point the MX records for subdomain.$domain to mox. Some email will have to be received by the mox instance: at least DSNs for undeliverable emails. Probably also dmarc/tls reporting emails. But I may be getting into too much detail now...

I'm interested in understanding exactly what you need/don't need. I can give pointers about setting up an instance. If you want to discuss more, we can also email/chat/call.

[shleeable]

Thanks for the reply. You've touched on most of the issues I'd imagine....

My requirements for my mastodon instance is sending the outbound messages for password resets/operational emails. These are sent from [email protected] etc. I don't receive any inbound email... and I think as mentioned, If I'm looking to offer this as a service to multiple different mastodon administrators.

I could setup mox as a single domain with a mailbox for each instance ([email protected])... or as mentioned, [email protected]

I'd require the admin portal to allow me to quickly spin up tenants with the username/password for their config.

Figure you disable the webmail/anti-spam and any other service only required by the inbound email.

finally, I'd be interesting in handling the reputation of the primary/subdomain and IPs attached to my outbound mail.

[mjl-]

I could setup mox as a single domain with a mailbox for each instance ([email protected])... or as mentioned, [email protected]
I'd require the admin portal to allow me to quickly spin up tenants with the username/password for their config.

I think you would set up a mox instance at mx1.fedimail.example.

You probably want the outgoing messages to have an "message from-headers address" that end with "@$tenantdomain", e.g. [email protected]. Because that's what recipients will look for to decide if they trust the message. To get such messages delivered, you need to ask the admin of $tenantdomain to make some DNS changes: add dkim records, modify their spf record, add an mx & spf record (details below). I suppose that's also in place the with the current mail setup?

For an example tenant domain pixelfed.example, you want the following email situation:

• Pixelfed uses authenticated submission (smtp, with username [email protected]) to send email to mx1.fedimail.example.
• Mox adds a dkim-signature to the message, for domain pixelfed.example (for "aligned dkim", since the domain for the signature is the same as the "message from-header address"), and mox puts it in the queue for delivery.
• Mox will try to deliver the message from the queue over smtp. Mox will send with "smtp mail from" address [email protected] (as how it was submitted). Using this "smtp mail from address" (which can be different than the "message 'from'-header address") means the message can pass "aligned spf" checks: The "smtp mail from domain" is a subdomain (or exact domain) of the "message from-header domain". By sending with this "smtp mail from address", any bounces (DSNs for undeliverable emails) will be sent back to [email protected], where mox will automatically process them (e.g. by adding addresses to the per-account suppression list (details below), or (optionally) by making webhook calls so applications can do custom followup, eg contacting user another way or unsubscribing them).

To get the above, the following dns records would be needed for each $tenantdomain:

• [...]._domainkey.$tenantdomain CNAME [...].$tenantname.fedimail.example. for a few values of [...], each for a key created by mox. You should create the actual dkim records at [...].$tenantname.fedimail.example with values provided by mox. The indirection allows you to update the records without involvement from the tenant.
• The current spf record for $tenantdomain should be changed. The fedimail IP addresses need to be allowlisted for sending messages with $tenantdomain in the "message from-header address". The tenant should add include:spf.fedimail.example to its current spf current, and you should create spf.fedimail.example TXT "v=spf1 ip4:127.0.0.1 ip6:::1 -all" (with the actual fedimail ips). Going through the fedimail spf record allows you to change/add ips later on without requiring involvement from the tenant.
• fedimail.$tenantdomain MX 10 mx1.fedimail.example, this causes the bounces (DSN messages) to noreply@fedimail.$tenantdomain to get delivered to the mox instance. Regular email users won't see this domain and won't send to this address. It's only other mail servers that send DSNs there.
• fedimail.$tenantdomain TXT "v=spf1 include:spf.fedimail.example ~all, for mail servers doing spf checks.
• More records could be added to $tenantdomain, depending on how far you want to go. eg for DMARC (reporting and even policy) for $tenantdomain.

Mox currently assumes any configured domain is for regular sending & receiving of email. Mox prints DNS records to add, and has a page to check if a domain is configured correctly. You'll have to do things slightly differently for now to get the setup described above:

• First, set up mox with hostname mx1.fedimail.example, as usual.
• Add domain fedimail.example, with a postmaster account.

For each tenant:

• Add domain $tenantdomain
• Add domain fedimail.$tenantdomain
• Add an account named $tenant with address noreply@fedimail.$tenantdomain, and set a password. The tenant will use this info to login.
• Add another address to the account, noreply@$tenantdomain. This makes mox allow the account to send messages with this address in the "message from-header".

I wrote down a todo for mox to add a config option to a domain, to indicate it is for transactional sending only. That option should trigger showing different dns records, and doing different dns self-checks. We'll have to be a bit careful for now, not following the instruction mox provides blindly. But don't wait for the change to be done, it's already possible to set mox up for transactional email. I'll gladly help set it up and resolve any issues that may arise.

Figure you disable the webmail/anti-spam and any other service only required by the inbound email.

Indeed, disabling webmail is easy. You should be able to access the messages to the postmaster account, to monitor for trouble. You can also do that over IMAP. You can also enable IMAP and webmail over only over internal IPs (eg behind vpn or an ssh tunnel).

Anti-spam won't kick in without messages going in, so there's nothing special to do.

finally, I'd be interesting in handling the reputation of the primary/subdomain and IPs attached to my outbound mail.

Yes! This is an important topic. Mox helps in various ways. Of course you don't have full control over what other mail servers think of you. E.g. your IP could be in a "bad neighbourhood". But you should make sure your mail server behaves properly. Mox has some monitoring and protection options:

• Mox can monitor DNSBLs (dns bloclists) for your IPs, with prometheus metrics lightning up if an IP is listed. Mox can also send outgoing messages through other machines that you have configured, but can't yet automatically route outgoing messages based on DNSBL listings. But for now a single machine may be enough?
• Mox can limit the rate of outgoing messages per account. So if an account is compromised, it can't send unlimited spam. This limits the potential reputation damage to your IPs. Mox can limit both number of outgoing messages per day and number of unique recipients per day (but these may well be equal for these tenants).
• Mox keeps a suppression list automatically. If several messages to a recipient cannot be delivered in succession, then (depending on error response) the recipient may be added to the suppression list. Further submissions to the queue for such recipients are immediately marked as failed and won't be delivered. The reason: doing repeated failing delivery attempts for an address is seen as bad behaviour by receiving mail servers, and they may hold it against you (i.e. it may damage your reputation). Tenants can login to the account page and remove addresses from the suppression list if needed, or use the API (if you make the "webaccount" and/or "webapi" endpoints available to them). Mox also allows configuring a webhook HTTP endpoint where delivery successes/failures are reported to. This can be used by tenants to automatically unsubscribe users, or contact them some other way, or to investigate why they are on the suppression list. Unfortunately, there is no standardized API for these webhooks, so mox has its own custom API... Using the webhooks API is optional, and I don't think you'll need it immediately. Tenant admins could also manually monitor the noreply@fedimail.$tenantdomain mailbox (over IMAP or webmail) for DSNs if they really want to look into deliverability issues. I think other transactional email systems may be forwarding these DSN to a configured address. Might be useful for mox too if you don't want tenants to look into accounts at mox.
• In mox, accounts can only send messages with a "message from-header address" that is explicitly configured in the account. This is needed to isolate accounts from each other (so one tenant doesn't send in name of another tenant). This is also the reason of the clumsy requirement to add $tenantdomain as domain to mox.

As the admin of fedimail.example, you probably want to see the percentage of successful/failed deliveries per tenant. If it gets too high, you want to start talking to the tenant. Mox could be changed to show per-account delivery rates. Mox has a per-account config option for how long to store information about outgoing deliveries. If you want long deliverability history, you would configure a longer period.

Mox does not yet have any integration with "feedback loops" (based on "marked as spam"-buttons at bigmail providers). I should look into this at some point. I don't think it'll be needed any time soon.

Mox does not have a spam filter for outgoing messages. The rate limit mentioned above is currently the only way to limit damage after an account compromise.

Mox does not add unsubscribe links to messages (body & headers). Mox just delivers whatever is being submitted. You should get the tenants to include such links in their messages. If their messages don't have unsubscribe links, this can be held against the fedimail reputation, especially when the messages are often marked as junk (which they will likely be at some point if there's no easy way to unsubscribe).

Mox does not do click tracking, or view tracking (by adding tracking pixels; as a user, I dislike tracking, as a postmaster sending automated messages, I don't need/want to know what recipients have read/clicked). Again, mox just delivers what is being submitted. If tenants want to send messages with click/view tracking links, mox doesn't have a way to stop that...

You may also want to sign up at some bigmail providers for monitoring the reputation of your IPs. You'll need quite a serious volume of daily messages before they show you anything though.

If you want to use a new domain, like fedimail.example, you should register it as soon as possible. Recently registered domains are treated with suspicion by some mail servers, and messages involving such domains are more likely to be marked as spam. If you register now, it may have "aged" enough for use by the time you're ready for it.