All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Would you be interested in an email provider (with a twist)
MXRoute is awesome and they hit the LowEndBudget nicely, but I have an idea that might fit another use case for people.
As you might be aware, there are companies known as Transactional Email Providers that let you send email through them. Several of them (Mailgun, Mailjet, Sendgrid, Mandrill, and Postmark) even offer a significant number of free email deliveries. What you might not be aware of is that all of those providers can also be configured to to receive email and forward it to a webhook.
These transactional email providers aren't catering to people with their own domain who want a webmail interface. They don't even offer webmail. They're catering to companies or startups that need to send emails to users.
I'm planning on building a webmail provider with a very low yearly price that doesn't send or receive emails itself. Instead, you sign up at one of those transactional email providers and get an API key and enter it into my webmail system.
Then you can send and receive emails to your hearts content through a beautiful webmail interface.
Providers like LunaNode or MXRoute work hard to provide good service but are always fighting their IP from being blacklisted because of bad users on their system that send spam. My service will not have that problem since the actual email sending is through another provider.
Building the webmail interface around API clients will allow me to offer some things no other providers offer, such as user aliases applying to all domains in the account, being able to share mailboxes with multiple logins, and more.
I'm not going to charge per user, per domain, per email, or anything like that. It'll be a flat yearly fee with included storage space to store emails and attachments, with space upgrades available. The actual email sending and receiving will likely be free for most users. 3 of the providers let you send and receive between 6k and 12k emails every month for free.
I'm about to dedicate at least a month or two to write this and I want to get some feedback to make sure I'm not wasting my time.
Questions:
- Does this interest you?
- Do you think $7 a year for 1gb of storage is fair? Do you think I could/should ask for more?
- Do you think each additional gig of storage being another $2 is fair? Do you think I could/should ask for more?
- Are you OK with a mobile responsive webmail interface or is an Android/IOS client required for you?
- What are the most important features to you (especially obscure ones nobody else has cared about)
- Which domain do you prefer? domainmailbox.com or frugalmail.com? If neither, would you prefer something nonsensical and generic, like vizby.com?
- Any other comments or ideas?
Thanks!
Comments
Some more notes:
To make it as easy as possible, I'm planning on using integration with the most common DNS providers so all you have to do is sign up at one of the transactional email providers and get an API key and enter it into my service. When that happens, my service will ask a few questions and then handle your DNS changes for you and configure the transactional email provider for you.
Offhand, I'm planning to support Cloudflare, GoDaddy, NameCheap, and NameSilo. For the transactional email providers, I'll start with Mailgun, Mailjet, and Sendgrid. I'll add Mandrill and Postmark if there is significant demand.
So basically you're using transactional email providers to send non transactional emails.
I see the advantage of using mandrill et al to send mail. I don't see the advantage of receiving you mail through them... better spam filtering, or some other feature?
@Johchun: Correct. While they're focusing on transactional email, there is nothing in the Acceptable Use Policies of any of those services that prevents them from being used for personal messages.
You could just configure Roundcube to use Mandrill as its SMTP server, you can even specify the credentials rather that using the ones used for IMAP. It should work as long as the domains what would be used via the webmail are setup in Mandrill.
Same as a VPS will never have downtime if you buy it through a reseller rather than direct.
@tehdan: That's a good point. If I wanted, I could simply make some MX servers for people to add to their DNS records for incoming emails, and then require them to enter the transactional email providers API information for their sending capabilities to be turned on. I don't really have a good reason not to do that.
errr?
My point is that an individual will have a hard time providing good email sending services because they'll constantly be battling providers who think they are spam, dealing with real spammers, dealing with DDOS attacks, blacklisting, etc.
By outsourcing the message transmission to a company that deals with it professionally, it makes delivery a lot more dependable.
Those companies care about dependability. They don't care about a webmail interface but I do. It seems like it's a good combination.
IMAP would be required for me.
@DeftNerd so - as @rmlhhd suggested, a competitor could just cobble something similar together in an afternoon with standard tools like roundcube, dovecot and postfix.
I'd suggest starting with your webmail app - if you can attract people with that (you are competing with a lot of very mature clients) then your mandrill idea may give you extra reliability on top of a great UI.
I'd say that was a big risk to take. But I'm not going to buy email service from anyone, so you might not value my opinion too highly
Now that's a name!
Basic IMAP wouldn't be too difficult, but some of the things I want to do would might make IMAP difficult (but not insurmountable).
For instance, someone might set up hello@[alldomains]. If someone sends a message to [email protected], the user can reply through the webmail and it'll set the outgoing sender properly. That's more difficult to accomplish with IMAP.
Also, bob1 and bill1 might both have logins in the system and share a mailbox at [email protected]. In the webmail interface, I can show that a message was received and then replied to by bob1 (with the email return address [email protected]). Bill1 could also reply and it would look like it came from the same email address, but in the system it would show that Bill1 was the author. IMAP doesn't have that functionality. This would be good for shared support email addresses.
I also want to be able to make private notes be able to be attached to messages. I could hack this through IMAP by using drafts, but it wouldn't be ideal.
And I also want to be able to make dynamic signatures assigned to mailboxes, so the signature generated could include the actual name of the author, the domain name, website URL, etc...
These are just some of the things that don't fit with IMAP easily, but I can try to provide some kind of partially-featured IMAP gateway.
As long as it works on phones it should be fine, else your thing will fail entirely even if you provide an App for IOS/Android (like, what do people with Windows Mobile or Blackberry do, both still popular in large corps?).
Would not use the service as all this transactional mail providers are either companies based in US or have US based servers.
Excellent point! I'm big into Bitcoin, Tor, and privacy in general. After I work out the general specifics, I'll do what I can about finding some overseas providers for the email sending engines. The ones I listed are the most popular, but I bet there are some I'm unfamiliar with that are not in US jurisdiction.
So, you're going to build a frontend to sit infront of email transactional providers who can very easily change their AUP's tomorrow to disallow "personal messages"? Who in their right mind would even think about doing this, its the most stupid idea i've ever heard.
Oh, maybe it would make a difference... While a lot of what I'm doing won't work with IMAP, it'll work with JMAP (JSON Mail Access Protocol) that FastMail came up with. In fact, the frontend will simply access the email backend API which will serve JMAP.
If there are any mobile JMAP compatible clients out there, in theory they will be compatible.
I think this idea is clever, but could not see the value proposition, or in plain English, what do you bring to the table to the customer compared to your competitor, like GMail, Outlook, Yahoo mail?
In another word, who are you trying to sell for?
I just lit a cigarette with that burn ;-)
I've already gotten approval from Mailgun and Mailjet's legal team and tech team for this. Haven't heard back from Mandrill or Sendgrid yet. They've already said that their AUP doesn't disallow this kind of business but they can't provide any extra SLA's for me to pass onto my customers that the customers won't already have with their account. They've also agreed that if a user sends spam, that they'll cut the users API key off but they won't ban my backend IP.
But I need IMAP
Ah, I see you'll implement IMAP, then it's okay
Excellent question.
People that own their own domains but who don't want to pay $5 a month when they only send a handful of emails.
it also appeals to people like that have a hoarding problem and have dozens or more domains and want to be able to quickly implement a [email protected] email address for all of those and only have one inbox to work with, and not have to pay some kind of fee for every domain.
It'll also appeal to people who might have a few businesses with domains and want to hire a support person to be able to answer all the different [email protected] and still keep an eye on all the activity.
@DeftNerd oh please, we all know legal teams change their minds in a heartbeat, unless you have an air tight contract I would take that with a pinch of salt. What protection do you have if they decided to change their AUP's tomorrow? Nothing....
So why couldn't mxroute add this feature and then you have no competitive advantage?
Seems to me it's a low barrier of entry for all potential competitors...which doesn't mean it can't work.
I will say it's refreshing to hear someone with a thought out plan beyond "I HAZ D3DI 2 MAKE LEBZ!!1!"
Thank you for your input.
If all the providers decide to collude and do this all at the same time, I'm sure my customers and be upset that their accounts were terminated at those providers. All the other thousands of customers that just use a transactional email provider for personal messages too. And I'm sure thousands of people will also want to know why the transactional email provider has been reading their emails to determine if they were personal or not, and what criteria was used.
Basically, I'm not worried about it. All I'm planning to do is provide a handsome interface on top of a raw utility provided to individuals. If the utility decides to stop serving those customers, then the customers will be mad at them and not me.
It doesn't currently exist. Just because it could be made by another person at some point in the future is no reason not to build it.
If that was the case, there wouldn't be a gazillion low end VPS providers :-)
Using transactional mail api as a webmail service isn't a new idea, and basing an entire business off something that can change overnight doesn't sound thought out to me.
I don't really see the market audience for this. If someone is tech savvy enough to know about mailgun/mandrill/SES and other transactional mail providers, setting up a receiving mailbox and sending using their SMTP credentials (offered by every one of those services) is a simple matter and they don't have to depend on a third party service.
RainLoop, Squirrelmail, roundcube, etc all are webmail clients that could do this out of the box.
@DeftNerd so in a nut shell, you're out to make a quick buck at the expense of email transactional providers and their generous free quota's. If they wake up and decide to change their AUP and maybe limit their free quota's because you've brought extra load onto their systems which costs real money to maintain, thats totally ok? You ruin it for everyone else because you wanted to make a quick buck...
You're entirely correct that the very basic core concepts of this could be covered by existing software.
All you would have to do is
6.5 Repeat steps 5 & 6 for each domain you have
My solution would be:
Everything else is configured for you
Most of us don't mind doing things the hard way. Most of us find enjoyment in it.
Despite that mentality, I use MXRoute. I also use a hosted Piwiki instance. I also use UptimeRobot.
I could roll my own mail server, I could run Piwiki myself. I could set up my own monitoring solution. I just prefer to let other do what they do best so I can focus on what's important to my time.
Additionally, I'm planning features that no email provider has and aren't build into any of the opensource webmail packages.