New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
I love the idea, and it definitely takes some weight off of you as a provider offering this, but this quoted text is where I disagree. I've had mails returned to Mandrill repeatedly due to poor IP reputation on their side. Yahoo blocked the hell out of them last week. These providers are not a guarantee around it.
I'm surprised that you think that hundreds of hours of development is a "quick buck".
Regardless, you've made your singular point clear. If you have any additional input, please feel free to chime in. If you don't, I don't think it's necessary to repeat yourself.
I was not aware of the difficulties they've been having. I do know that all of them have API endpoints that return deliverability information.
One of the things I was planning to do is make it so customers who enter their DNS provider API key could enter the information for multiple providers. If one provider is having difficulty, I should see it pretty quickly with the deliverability statistics and I could change those customers delivery methods to a different provider that they've configured.
For delivery with multiple providers, you just have to make sure that all of them are included in the SPF record. In fact, in most cases you can find out from the provider if each message was delivered or not. If the message wasn't delivered from their Mandrill account, then I could resend from the users Mailgun account. This is assuming, of course, that the destination like Yahoo actually tells Mandrill if the message was rejected instead of sending it into a blackhole... But all email senders face this problem.
I get to see a lot of it first hand but yeah, overall the idea isn't bad at all. Personally speaking, I welcome any competition to MXroute with open arms. I need a decent competitor. It challenges me, it benefits the industry
Look into things like MailChannels too as you build up the underlying idea for this. That's what I'm using for MXroute now, so that if an IP has a bad reputation they resend it and the client never has to deal with it. There are other services like that too, maybe you could widen the potential SMTP provider possibilities by searching that kind of market as well.
Actually, it's MXRoute that inspired me.
I've seen all the difficulties you face with IP blacklists, fending off spammers, DDOS attacks, and architecting a strong and resilient infrastructure. It's an insane amount of work for one person to handle and yet you somehow manage to do it with expertise and grace.
It made me realize why there were thousands of shared web hosts and hundreds of VPS providers, but only a handful of email providers. Email is hard and only a crazy person (no offense) would try to get into that industry unless they could hire lots of employees (like FastMail). It made me run through a thought exercise of how it could be done differently where a single person could do it and not spend hours a day dealing with it.
This is the setup I came with:
Offloading the actual sending to the transactional email provider the user chooses saves a lot of headache.
Storing emails as JSON documents in a distributed and replicated RethinkDB database, API written in Go on each database machine, behind a cloudflare protected URL that round-robin connects to the different API endpoints.
Web frontend static hosted on S3 behind cloudflare that just talks to the API with something like react.js.
All the tasks (emails to send and receive, status checks, etc) will be jobs in a replicated RabbitMQ queue with a few workers in different regions taking messages and passing them to the transactional email providers or checking with the providers for message statuses, etc.
It's a good architecture that should be resilient to attack or hardware/network failure. Using the transactional email providers means that support issues around "My email wasn't received" will be fewer.
Support issues regarding setting everything up might be higher if I don't do my job right with the user onboarding wizard.
Regardless, I'm certainly including a link to MXRoute on my site for any users that want a traditional IMAP/POP/SMTP provider. I might not even support IMAP... not sure yet.
Just to add, it's refreshing to see an idea so well thought out and laid out clearly (not that others haven't), and any decently thought out and set up system/provider is a big asset to the industry.
And it would be cool to see some sort of partnership/integration between @Jar/MXRoute and this, just because MXRoute is awesome, and this seems like a good idea, and could probably help them both, but two separate awesome things isn't bad either...
Good luck @DeftNerd, looking forward to see where this ends up!
I haven't seen any comments on my pricing yet. I take it that $7 a year + $2 each additional gig of storage is not offensive to anyone?
Back of the envelope math makes me think that a user with 1 gig of email will cost me 40c a year in storage costs, but 1 gig of email storage might be far more than 1 gig in traffic allotment if they're sending and receiving a lot and just routinely out their saved messages. Assuming turnover of email storage is at least 5x, the bandwidth would cost about 50c per user.
So, each user would cost up to $1 in variable costs. Each additional gig of space sold would be up to a $1 cost in storage and bandwidth.
The actual infrastructure required to run everything would be a flat cost of about $300 a year for up to 1000 users (at best guess). That primarily consists of at least 2 decent VPS's or older dedicated servers and object storage for emails and attachments, s3 static site, backups to s3, etc.
Once I have at least 50 users (the break-even point), I could set up affiliate programs, run coupon codes, specials on LET, etc.
Even at 100 users, I'm making a profit of just $25 a month, so this won't pay a lot of bills or anything. Maybe my prices are too low since I don't break $100 a month profit until 250 users.
I just have no idea how many users I would get. I'm targeting a pretty niche market.
Plot twist:
MXRoute buys out all the competition before they get too big, that's why he welcomes competitors
lol
I build things that I believe in and am passionate about. If I manage to pull something off that is good, I wouldn't mind selling it as long as it kept on being run to the ideals I envision with the quality I require.
If someone ever wanted to buy something I made just to shut it down, I would say no.
I can't help but think - if you can, in 2 months, single handedly write a webmail service (regardless of underlying mail handling) with a UI that is seriously on a par with Google/round cube then you are a very talented guy and wasting your time chasing people for $7/year. Write the damn thing, show it around and you'll find yourself in a very well paid role in no time.
To me, this sounds like a creative idea that could even work well (for a while)... but not viable as a long-term business for all the reasons mentioned before.
@DeftNerd Nothing yet?
@DeftNerd
People will need IMAP access, how will you build IMAP access for your custom storage.
If you plan to use mandrill by letting people use their own mandrill / sendgrid account also consider the cost of incoming spam which comes in thousands everyday and will exhaust their free limit in less than a week. Beyond that it will become considerable charge for running it. Slowly, the most abusive users can destroy your reputation around it.
I had thought about the similar service pretty widely and that is why I am asking you this.
Also understand to route incoming email every provider has its own ways but almost all are charging for Routes ( a concept for them to find the right mail and forward to your webhook )
I am already having a similar setup by configuring my cpanel server to send all its mails via sendgrid etc., and the mx records specify how i get emails for my domain. just you need to push outgoing emails to the server. which will deliver it via transactional mail providers. I have this setup running for over an year now with 0 issues.
why i did this? i tried this to get emails from some cheap servers which were running on the infamous colocrossing spamhaus ip ranges.. and then pushed the setup to my email server (over cpanel)
i think @jarland can also configure his setup to support this spending some minutes.. if this really brings out the advantages you mention.
Anyway i can assure you this works solving the issues you were saying. And its easy to implement on a personal level. As a service you have to figure out with the api - user account - smtp connections - server ip reputation/rate limiting to their api's etc.,