I mean… you can, but beyond the technical aspect of setting up the hardware/services/DNS, you also have to deal with the unknowable black boxes that are the major email services. As a very small server, you’re gonna run into deliverability issues and have absolutely no feedback or recourse from the giants. There’s a decent chance that you’ll end up with a perfectly configured mail server that, through no fault of your own, fails to actually get your messages to their recipients.

(Sorry to be a bummer here! If you do go this route, I hope that everything works out well for you.)

Just passing along what I’ve read many times: that self hosting email can be difficult. Particularly sending, because the large providers tend to treat email from less known sources with more skepticism (such as by marking as spam), even with properly configured SPF and DKIM.

And if your server is down, you may miss any incoming mail for the duration. I don’t know if other providers would try resending after a period of time if the receiver is unreachable, but I doubt it (just an educated guess).

I love self hosting services but email is something I’ve decided not to touch with a ten foot pole.

I’ve been running my own email server for years, and while it’s indeed difficult at first, it is possible and you don’t have much to do to maintain it when it works. All the horror stories you hear come from the fact it’s difficult to get right, and even when you get it right, you will have deliverability problems the first year, until your domain name gets established (and provided you don’t use it for spam, obviously - and yes, marketing is spam).

What you need :

• being willing and serious about reading lot of documentation
• an IP that is not recognized as a home IP. So you’ll need a “business ISP”, or one that is not well known. You bypass this problem by using AWS.
• choosing a well recognized TLD for your domain name, like .com, .org, .net, etc. Don’t use one of those fancy new extensions (.shop, .biz, etc), they are associated with spammers.
• learning how SPF works and getting it right (there are plenty of documentation and test tools for that)
• same for DKIM
• same for DMARC

Start using that for a year without making it your main address. Best is to use it for things not too mainstream, like FOSS mailing lists, discussing with people having their own mailserver, etc, those will not drop your mails randomly. When a year has gone with frequent usage, you can migrate to that email address or domain.

Regarding the architecture of your network : do you read your emails on several machines (like, on mobile and laptop)? If not, you can dramatically simplify your design by using pop3 instead of imap, connecting your client to the AWS server, downloading all your emails to computer and removing them from the server at the same time. There, you have all your mails locally and you don’t need dovecot. :)

Awesome talk about selfhosting email from someone doing it professionally for decades:

Email vs Capitalism, or, Why We Can’t Have Nice Things - Dylan Beattie - NDC Oslo 2023

https://youtube.com/watch?v=mrGfahzt-4Q

I self host everything except maps and email. Maps because it’s just not there and email because even if you set it up perfectly with DKIM and everything your IP can still land on a blacklist. You will spend more time doing blacklist appeals then it’s worth.

I will echo many others here: It’s going to be rough getting good deliveries. While you are planning on running a proxy, that is basically the same as running an open port where your server is. While it may seem to be a good idea to send email from a random AWS address, it really isn’t. Unless you are behind an IP that is specifically trusted as an email source, your traffic has a higher probability of getting dropped. (Many dynamic IP ranges for home internet connections are marked as invalid or untrusted sources, btw.)

Additionally, email servers are a hot commodity, especially if they are not blocked (yet) by the larger filter providers. All it takes is one or two reports or a poorly configured firewall/IDS to auto-trigger a submission of your IP address as “bad”. By hot commodity, I mean you are going to get fuck tons of vulnerability scans. It’s not the end of the world, but it’s super annoying.

If I was operating as a Jr. Security Analyst again and saw and sus traffic coming from your address, I would submit a block and not think twice about it. Hell, most of those types of blocks are automated anyway.

However, if you do set one up and all is golden, great! It’s worth the experience but something I won’t ever do again. (Yes I did run my own email server before.)

Been using mail cow for the past 5 years. It’s great.

If inbound port 25 is blocked you simply cannot run a mail server, it would just be a mailbox.

If it’s just outbound 25 blocked, pay a few bucks for a relay service and send mail to the relay on the submission port or over SSL.

If you are saying you can’t because your ISP blocks port 25 there are a few solutions that you can use that are free as long as you don’t send or receive over 2000 emails a month or something like that. I have used both of these solutions with my last ISP since they blocked port 25. I used http://ghettosmtp.com as a relay server. Wesley, the provider of the service is a pretty neat guy. I used https://www.smtp2go.com as my external outbound relay. They both worked great as a work around. I have ATT fiber now and 25 was blocked until I called in and requested it to be unblocked.

Anyways, I hope that helps. Let me know if you have any questions!

you have the main problem in hand. You’ll still need to do all the DKIM / rDNS stuff to be certain your mail is accepted, but using SES as the source gives you a significant leg up vs originating locally. I don’t see why you can’t run dovecot and postfix on separate systems, but a single VM isn’t bad if it’s properly secured. Hosting SMTP/IMAP is not that difficult but you need to make sure you don’t accidentally misconfigure things and become an open relay - as with all internet facing systems, mail services are targeted constantly so you should use fail2ban to deter them.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

5 acronyms in this thread; the most compressed thread commented on today has 14 acronyms.

[Thread #20 for this sub, first seen 10th Aug 2023, 23:35] [FAQ] [Full list] [Contact] [Source code]