Ask HN: The middle ground for email self-hosting?

FWIW, a $4/m Exchange Online Plan 1 is probably enough. Or even the $1/m Exchange Online Protection if you don't have any need for a hosted mailbox. Anything that'll get you ongoing access to the Exchange Admin Center.

I use a single M365 Business Basic account, as a conventional mailbox, for one of my domains. From within the Exchange Admin Center there's extensive control over mail flow -- domains to accept mail for, inbound and outbound connectors for routing mail between on-prem mail servers. Best as I can tell, literally ongoing any subscription that gets you an account with access to EAC ought be enough to route any or all of your email through EO in either direction.

https://www.microsoft.com/en-us/microsoft-365/exchange/compa...

https://www.microsoft.com/en-us/microsoft-365/exchange/excha...

https://docs.microsoft.com/en-us/exchange/standalone-eop/sta...

https://docs.microsoft.com/en-us/exchange/mail-flow-best-pra...

You could build one for SES. You'd need to write an Amazon CloudFormation template that configured all the things correctly.

The result would be a screen or two of auditable gobbledygook that took a week or so to write. Somewhere in there, there'd be a pointer to an EC2 or ECS image, among other things.

It'd be a learning experience, and very tied to AWS. I wonder if someone else already did this.

In my world (running a small digital agency), I've realised that even if I do all the things to reduce my data footprint (for instance, migrate all my docs to NextCloud, self host email, etc), it actually all breaks almost instantly - all it takes is a client to share a doc or folder with me where they use GDocs / Dropbox / whatever, and I'm effectively straight back in it.

My basic strategy is one of slight defeatism, I have to admit. I am 100% in to Google for their (really quite excellent) tools in Google Workspace: nothing is as good as GDocs, nothing is as good as Gmail, nothing is as good as Google Meet; but I do things to ensure I'm not utterly f**d if the Random Google AI Best happens to decide I'm some sort of unspecified menace. So for instance - I use Google Docs but only with .docx / .xlsx files rather than native .gdoc .gsheet files. I back this up automatically to my self-hosted NAS. I do this on a domain which I own, so can step away if things do happen to go south, or costs double or whatever.

Then I use kagi.com for search, and have a piHole / ublock / Brave to minimise footprint from a tracking POV.

I know, it's all probably moot given I just open up my inbox to Google, but I've tried and failed to find a provider that is even close to being the same balance of low price + utility. I got excited about Fastmail but turned out it was a combination of not very good AND really expensive once I factored in having several accounts on the same domain. I had a horrific experience with iCloud+ (they have a weird YEAR long account blocking issue thing that I won't go into now). M$ was awful and required me to send everything through GoDaddy's DNS. All the others were just underwhelming or expensive or both. So - sadly - I'm back in the G stable where I'll stay for the time being... :-)

I'm fairly sure they were abusing the standard with this particular technique. Deferred messages are OK if they can be retried later and that's what the MTA will try to do. Permanent deferral I suspect is really supposed to mean "we can't deliver right now and we don't know when but keep retrying".

What this does not do is trigger "undeliverable mail returned to sender" messages, so the end user has no idea their message is stuck in their own MTA's mailqueue until the MTA decides it has tried enough and gives up, and MTAs will usually persist for quite some time.

Spammers won't care what error code you send them or even worry about deferral messages, which is why the temporarily deferred spam trick works (first send is deferred for 1 hour, if you are a genuine MTA and you try again respecting this, it works). But permanent deferral, as I say, is very user hostile. The user thinks they've sent an email, but it isn't in the spam folder of the recipient. The sysadmin then has to go and dig to find out what exactly happened, and remove the mail from the mailqueue.

Luckily so far as I know we are only emailing a single yahoo address.

tl;dr the technique they are using is designed to handle the case where the receiving MTA is offline temporarily. There is a spam defence trick you can use and I don't object too much to that, but they used it to implement their block list rather than outright rejecting, and set the timeout to deferred indefinitely, which is just bad.

Im extremely curious the legal precedents you used to accomplish this, particularly around forcing certain providers to un-spam or un-block your emails. What was the condition your legals found in order to do that?