mailpace-rails VS burner-email-providers

I run a small transactional email provider (https://mailpace.com), our IPs are very rarely added to blocklists- but we are very strict on what we allow through our service, and surprisingly we’ve had no long term delivery issues with any of the big providers.

So thanks to the federated/decentralized design of email, is totally possible to be part of the network without any special privileges.

We are sending millions of emails every day though, which is quite different to sending a couple hundred personal emails a week. If you’re running this on a cloud host, expect to be blocked by default. However if you can find a small vps provider you’ll have better luck on sending yourself.

If you’re going to learn anything, email is a good bet. It’s barely changed in 30 years, and I suspect it will not change much for a long time.

I built my own transactional email provider (https://mailpace.com), I wish I had found this link before I started.

I would also recommend reading the email RFCs, they’re not that difficult to understand and the history explains a lot. Email aside we can learn a lot from this kind of distributed, decentralised system design in the future.

Their website at https://mailpace.com/ says that it's only intended for transactional mails however

Give MailPace a try [0]. The creator seems like a great guy, and the service does what it says without any bs. I've been using it for a while now for side projects, and can only recommmend it.

0: https://mailpace.com/

I agree that this is a challenge! If you want to use the hosted version, it's impossible to avoid the need for that trust. I'm working on making self-hosting easier for this reason.

Some other services (like Firefox Relay) will use AWS' Simple Email Service for everything. I opted to go for [MailPace](https://mailpace.com/), an independent, privacy-focused provider instead, which is an improvement but still not ideal. I believe that SimpleLogin lets you self-host your email, which is best from a privacy perspective, but I'm slightly concerned about the UX of having to think about email deliverability. Still experimenting with that!

You could use an SMTP relay service and not worry about deliverability while still self hosting your email. I don't self host email anyway but for other things I use https://mailpace.com/ - it's has probably the best pricing in the market and works very well. Emails are delivered very quickly.

When I was launching my new website, I was looking for an email provider. That's when I came across OhMySMTP, a simple and privacy-friendly transactional email service. My web framework of choice, Laravel, unfortunately doesn't support OhMySMTP by default. Luckily, OhMySMTP does provide a swiftmailer transport plugin! This can be installed in any Laravel project, and can be configured like official transports.

For an example of that, see here: https://github.com/wesbos/burner-email-providers/pull/339

But yes, definitely a concern that is constantly on our radar.

We're actively reaching out to maintainers of such lists (see e.g. [1]) to get us removed, and take a number of measures to make that more palatable (see also [1]). And of course Relay is a bit different from services like Mailinator, where email addresses are usually actually single-use: Relay addresses remain active until their owner actively disables them. Possibly in the future it might also be possible to bring your own domain, but I don't think we have any concrete plans for that that we can share.

That said, no solution is perfect, and I expect that there will likely always be situations where you will be forced to fall back to a regular email address.

[1] https://github.com/wesbos/burner-email-providers/pull/339