Closed runningman84 closed 1 year ago
Thanks for the report @runningman84!
Had a quick look at AWS SES just now. It indeed looks like it can be used to receive email for a domain, where it stores the messages in an s3 bucket.
I don't think mox is currently the right tool to integrate with AWS SES: One of the goals of mox is to let users run their own email infrastructure, and to keep email decentralized. Letting AWS handle incoming email is counter to that goal.
Mox can already be used to deliver through 3rd parties, by using an authenticated submission (smtp) account. But I think AWS SES has some limitations in supported features that may not make it work for all cases (from memory, they don't support SMTPUTF8).
But I can understand that users don't want to run email infrastructure entirely at home. There's a good chance that a home internet connection isn't allowed to make SMTP connections to the outside world (ISPs are afraid of spamming customer, mostly through compromised home machines). And users may experience delivery issues because they cannot change the reverse DNS of their home IP. These limitations don't usually apply for "business" home connections though.
Anyway, most people set up a virtual machine/VPS somewhere in the cloud
A setup I would like to experiment with in the future: Setup a cloud VM that forwards traffic to a home machine that's connected with wireguard. The home machine would have the cloud IPs configured directly, so no special configuration hacks required. Storage of the emails would be local, and the home internet connection could even change (e.g. with IPs that change once in a while).
Are there more reasons not to want a public mail server at home?
The vps solution would work but imagine the vps breaks when you are on a business trip you cannot fix it.
Running the smtp server at home with a public up exposes your domain or server name.
Ses would be very reliable and any outage or home would be buffered…
I think there could also be an independent program which just pull messages and send them locally via smtp. Here is some lambda code which could be used in a docker container too https://medium.com/naukri-engineering/use-amazon-ses-to-receive-emails-in-s3-and-forward-incoming-email-to-any-external-email-id-84ffb394c70e
Thanks for the info. Aside from the mismatch in goals for mox, there are also more technical/practical reasons not to let another service handle incoming mail. One is junk filtering. Mox does that based on classifications the user of the account makes. The reputation of IPs/address/domains is build per account, applied when email is delivered. With another service (SES) accepting incoming email, this is pretty much impossible for mox to do, and would have to be done by SES. I'm starting to think that if you want SES to handle incoming and outgoing mail, the value-add of mox will be relatively limited and it may be better to keep all email handling at SES/AWS.
Users might not want to have a public mailserver in their home.
One way to make the mail server private could be that users would setup ses inbound and outbound. In this case mox would have to download messages from a private s3 bucket… for outbound delivery ses could also be used…