Are Email apps really that hard?
Quote the recent IH podcast: (https://www.indiehackers.com/podcast/035-tobias-van-schneider-of-semplice)
It was a huge failure. The developer completely underestimated, I think we all underestimated working on an email app because email protocols are so fucking old, it's really annoying. That's why you don't see much innovation in that field happening because it all runs on protocols that are decades old. That was a huge failure. I switched to another developer, and you know how every time you switch developer they always come with their own religion.
This sounds believable until you pause and think about it. old protocols get built on top of which makes them -easier- not -harder. Tobias wasn't trying to -kill- email, he was just trying to make a pretty email app. In recent years Front and Polymail and god knows who else have made new email apps work. I don't doub't Tobias' execution abilities at all but can someone with email server experience go a little more in depth as to the state of the tech here? I had an email related idea (not killing it) but listening to this interview made me extremely discouraged and I wonder if that is warranted.
If you are interested in the email space you should follow and possibly get in touch with Mike Taber. He has built Bluetick, an email followup automation tool, and listening to what he says - working with email is HARD (he is also the co-founder with Rob Walling of Startups for the Rest of Us and other cool stuff - he also created Drip so another email-related app).
You can start by checking out Mike's 21-days diary before launching his app: http://www.singlefounder.com/the-21-days-before-my-saas-launch/
solid, solid tips. will do, thanks very much. appreciate learning about a space before i sacrifice weeks and months to it.
Building a custom mail client from scratch is a lot of work. In my opinion, it's not a great business for an indie developer to get into.
Even building on top of a modern API like Gmail's, you can easily spend a year just coding to play catch up in terms of basic features. People expect a lot from their mail clients, e.g. apps on every mobile client.
I agree, I wasn't proposing to do that tbh. bryan (who I met through the IH community) and I were looking into standing up our own mail server and offering that as a service with some differentiating features. Neither of us have prior experience but I honestly had not thought it would be that hard. Just looking for gory details here.
gory details..email server eh ?
Reputation..
IP addresses and volumes matter
Email Servers have reputations .. you have to build a reputation by sending millions (i do mean millions) of emails from a dedicated address daily....
you then have to try to make sure that there is no misuse ...
there are block lists you have to monitor and you will end up on (these systems are woeful(think 90s style html) with crap processes to try to get off the spam list..)
If your on the block lists other systems that are subscribed to it will start to blanket block you...
So now you really have to have a few of those dedicated IP's sending millions...
Spam blockers..
all emails are rated.. with varying scores...
Worst part is many emails servers can create their own rules ..
some universities for example have the strictest rules..
these rules are some times almost un avoidable... and they differ between other providers... and often it is the clients content that will get them blocked..(tip always send a plain text copy as well as a html version both marked as such)
Shit goes wrong..
this is where email servers surprise the most...
it doesn't matter that your implementation is shiny and good
your dealing with all the others out there..
Emails servers usually follow a pattern send email ? not accepted... Ok send in 2 minutes again... ok 10, 20 .. an hour ... 2 hours.. 4 hours..
I'm not joking i've seen other servers give nonsense protocols (the ID's for spam or server busy)...feedback ... only for the same email in the throttle pattern to be accepted 4 hours later...
Explain that to a client.
gtg here there are about 3 more points lol
source: me i wrote most of the email handling code of a saas app which had Alot of advanced emailing..
I also became very familiar with email servers and tracking down where the fuck mail went ..if anywhere.
wow, thank you!
yeah i actually want to run a read-only email server. so a lot of those problems go away except for spamblocking since im basically signing up to be spammed. Its just an idea for now and I will hit you up if it becomes serious.
Don't know much about that, but what little I've heard about it is that deliverability and spam filtering are the big challenges. Apparently Gmail is particularly unfair in how it treats mail from custom/unpopular servers?
I've studied this problem and my conclusion is that SMTP is indeed trash. For instance, you can't easily sign a mail because every relay can rearrange the mail content or modify it. There are many problems with the mail.
Designing a new protocol is possible, but then we compete with Free and a lot of expectation from users. We also compete with all the alternative messaging applications like messenger, skype, wathsapp, slack, etc.
The new service must provide a significant added value to get people simply to use it, even if its free. These type of applications are subject to a very strong network effect barrier.
I had an idea for a method to protect against spam. But bootstrapping is not feasible and the method is easily copyable. So it's not a good business idea and so it stays in the back of my head.
The mail and phone spamming problem will increase. My idea is ganing value ;)
i may come back to you on the spam discussion if i ever get serious about the email server idea. i think it will stay on the backburner for now. love the discussion! thank you.
The podcast with Toby is great & inspiring!
The difficulty is that POP/IMAP/SMTP are really old protocols and mail servers will implement certain parts differently from others. Thus you need do to a lot of testing besides the initial effort of implementing the protocols into your client. There are for sure some libraries but I don't know how well those are maintained.
On top of that, you need to store & share his proposed actions states. It might be possible with IMAP - otherwise, additional backend infrastructure is necessary.
Building it on top of the GMAIL API or Graph API (Office 365) would be much easier. For example, the Graph API lets you store custom data on top of existing emails. This could be used instead of requiring an additional backend to share state. The Graph API also attributes each email with a conversation id which can be used to display email threats. I'm pretty sure the GMAIL API has similar capabilities.
If I would make my own email client I would therefore only focus on either a GMAIL or O365 version. Nevertheless, the actual client will still be a lot of work on top of it.
ok great and have you any experience running your own mail server? I shouldve clarified in my post that that was what I was after - i know Toby was going after a mail client but I was actually thinking about a mail server.
I did once run my own mail server more than 10 years ago. I would never do it again - for $5/month you can get a GoogleApps account :)
My day job is in the email security industry and all of our customers are either using Exchange, Office365 or GooglApps. Not only do you need to fight with your IP reputation/backups/spam but you also need to compete against Google and Microsoft. It's a commodity business and most businesses will choose only players with reputation. I think you would need to focus on a niche like FastMail (anti-Google) or ProtonMail (e2e encrypted emails) and go from there.
very good specific thoughts. I obviously need to do a bunch more research. Yes I would be in a niche, and my server would be read-only so i don't care about reputation but backups/spam do mater yes.