Building imux.email Part 1: Forwarding Emails

I had a project idea a month or so ago when I was part of a group planning some holidays. We were booking flights and accomodations, but the confirmation emails only went to the account of the person that actually made the booking. So I thought, wouldn’t it be nice if we could all get those emails? Well, some services do allow submitting multiple contact email addresses or adding “guests” to a booking, but not all of them do. I figured it would be cool to make a service that gave you a temporary email address which automatically forwarded all received email to addresses that you specified. Then you could use that single address as the contact for these bookings, and everyone would stay in the loop.

Because the service would accept one email and fan it out to multiple addresses, I was thinking of branding it as a “multiplexer for email”.¹ Then I realized that multiplexers actually go from multiple inputs to a single output, and an inverse multiplexer, or IMUX, was more what I was imagining. After a bit of searching, I found the domain name imux.email, and knew it wasn’t going to get better than that. Determined to not let such a perfect domain name go to waste, I started planning.

For a while, I looked into what it would take to provision my own email infrastructure in a way that could be reliably automated. It turns out that email servers are very complex, so then I looked for email providers that I could use to create a bunch of addresses for a low cost. The “low cost” bit immediately eliminated pay-per-seat options like G Suite, but I found MXroute, a budget service that offers unlimited addresses for a flat yearly rate. It looked fairly promising so I signed up.

MXroute offers a simple dashboard to manage users, but there was sparse documentation on doing so outside of a web browser. I managed to find out that they were using DirectAdmin under the covers, so I only needed to look through their API docs to find out how to create accounts and forwarders. Their documentation was only slightly better, and I found most of what I needed in an existing PHP wrapper of the API. It turns out that they don’t really have a “conventional” JSON API—they’ve basically just set up their existing form handlers on another path. So instead of sending JSON, you send a form, which is not ideal but works fine when things are easily stringifiable. You also don’t get JSON back from the server, which is more annoying—you get some other plaintext serialization format that I’m not familiar with. The API documenation suggested to use a specific PHP function to parse it, and I was not willing to build my application in PHP. I was getting ready to flex my regex muscles when, in the process of inspecting some browser requests to figure out which endpoint was being hit by creating a forwarder, I saw a json=yes field in a form being sent. So it turns out you can get JSON back from the server, alleviating a lot of headaches. You still have to send your requests as forms though. Once I had the request format filled out, figuring out how to create accounts and forwarders was not very hard.

At this point, I was programmatically creating email accounts and forwarders, which was basically the point of the service. Yay! I set up a forwarder to my own Gmail account, fired off a test email, and… nothing. I never received a reply.n And that is when I learned how much large email providers hate forwarders.
MXroute has posted their own article about how difficult it is to reliably forward email which explains their efforts in more detail. But for me, that basically means that my service is guaranteed to be unreliable. Bummer, right?

I’m pretty doubtful about my own ability to host email infrastructure with a better reputation than MXroute’s, and I would spend way too much money if I were to use G Suite accounts or similar, so I’m kind of dead in the water. I looked into a few budget per-seat options like Rackspace, but they have a low limit on the number of recipients you can forward to. All that being said, I haven’t really done much testing on forwarding real emails, so maybe it’ll just work.

I’m planning to still build this out for fun and educational purposes, even if it can’t be used reliably. I’ve never actually built a web app before, and I feel like that’s something I should know how to do. I originally started building the server with Elixir, but ran into some weird issues when sending requests to the DirectAdmin API. The connection was being closed early and I was getting no responses, with no info on what I was doing wrong. The same requests worked fine in Python and Go, so I decided to proceed with Go. I was originally planning on doing the frontend with React, but I think I’m going to stick with a more traditional approach for now and learn one thing at a time.

Anyways, this has been kind of rambly. I’ll keep posting as I build different parts of the service with anything that I find interesting enough to share. If there’s anything that you take from this post, let it be:

• Forwarding email is hard because large providers don’t like spam
• Public APIs should be documented but often are not