Hi, I’m Hunter Perrin, and I made a new email service called Port87.
Gmail was a great email service back in 2006, but now it just sucks. They put ads in your inbox that look like unread emails to trick you into clicking them. To me, that means Gmail is malware.
I’ve been degoogling my life for the past 7 years, and Gmail is the last Google service I depended on. I love ProtonMail and use it too, but I developed a new way to sort email automatically, and wanted to write my own service based on it.
Port87 lets you use a tagged address like yourname-netflix@port87.com, and that automically creates a “netflix” label and puts all email to that address in it. This helps keep your email organized automatically, and protects against spam and phishing.
The database abstraction library I wrote for Port87 is called Nymph.js, and it’s open source. Also the UI library I wrote is called Svelte Material UI, and it’s open source too.
I hope you all like it, and hopefully it can help migrate away from Gmail.
Nice. Why use ‘-’, and not ‘+’ like we are used to from google? One argument against ‘-’ is that some people use it as part of their name.
You can also use a plus sign if you want to, but it’s not accepted everywhere, so I recommend using hyphen instead. One example is that Microsoft doesn’t accept plus signs in emails addresses, but does accept hyphens.
Usernames in Port87 can only contain letters and numbers, so there isn’t any issue with using it as a separator.
MS shadowbans my Proton email domains also. They’re a data broker and don’t want you to be able to hide your identity. People used + in their emails for exactly the reason and they figured that out.
The reason is that + is specified in the RFC as being for email aliases, so many systems ban it because they don’t want you to be able to track who they got your email from. A hyphen, on the other hand, is a normal character.
You’re no RFC compliant doing what you’re doing, but the advertiser won’t catch on immediately because of it.
I don’t believe there’s any RFC that says I can’t or shouldn’t do what I’m doing. The only RFC concerning subaddressing I can find is RFC 5233 (and the one it obsoletes). That one only concerns sieve filtering, which I’m not doing, and it specifies that any character can be configured as the separator character. The three examples it gives are “+”, “#”, and “–“.
Are you able to guarantee that your email service will still be around a year from now? Or five years from now? Or twenty?
Not trying to hate, just want to make sure before I create an account and start using your service for literally everything. If you one day decide to shut down and I lose access to my primary email address, I’m screwed.
This is a great question.
I can guarantee it will be around a year from now (unless California or the United States is no longer around). I have no plans to close it or stop offering the service. I’m funding it myself, and I have enough to keep it going without profit for several years (probably over five years). For now, I’m letting people on through a waitlist so I can control its growth and understand the limits of the current servers. Then I can set up automatic provisioning based on those metrics.
I’m trying to self fund it through profitability, so that the only people I have to answer to are my customers, rather than investors, who may not have the best interest of the customers in mind.
As for twenty years in the future, I would love to still be in control of it, but I can’t guarantee that. If I do sell it, one of my top priorities will be that the new owner maintain the current domain name and users. Or if I step down as CEO, I would choose a successor that shares my vision and motivations.
I’ll also be supporting custom domains in the near future, so if you join and use your own domain, then you could always transfer that to a new provider if anything does happen to the service.
I hope that answers your question well and alleviates any concerns you have.
what is the business model for this service?
i couldnt find a privacy policy.
Sorting emails like this is really useful.
Here’s the privacy policy:
https://port87.com/privacy-policy
You get 500MB free storage, and you can receive unlimited email. Here’s the breakdown of subscriptions:
- $0.99/month to send unlimited messages.
- $1.99/month for 2GB
- $5.99/month for 10GB
- $9.99/month for 20GB
- $19.99/month for 100GB
- $39.99/month for 1TB
I’m working on a mobile app that will be free. For now, the web app is a progressive web app, so you can install that to your home screen and it works like a mobile app.
I’m also working on other features that aren’t ready yet, but they’ll be premium features:
- IMAP, SMTP, and CardDAV support.
- Custom domain support.
- Additional users for your custom domain.
So basically the business model is pretty similar to other email services. One difference is that I charge for sending mail, and basically that’s to prevent spam. Spammers are unlikely to use a real payment account, because it will get shut down when they’re caught spamming.
Thanks for the informative answer.
The business model seems to be subscription based which i like(decently priced imo).
i suggest you looking into supporting external mail clients like k9/fairemail. Emails being encrypted at rest would be big.(People like to keep their stuff private even from the provider). Having a web app is nice tho.
i hope your ventures into this become succesful.
Thank you. :)
Once I have IMAP working, third party clients like those will work. IMAP will also let you export and import emails.
One of my goals is ease of use (particularly to support enterprise users), and storing emails encrypted complicates things. (You need a bridge for IMAP, and you need to index all emails on the client side to support full text search.) I will support S/MIME and OpenPGP over IMAP though, so with the right setup, emails could be end-to-end encrypted.
Why do you think you need a mobile app when there’s already a ton of free email clients for mobile?
I’m going to support IMAP too, but IMAP doesn’t fully support the way Port87 works, so the mobile app will probably be the better experience for most people.
Labels in Port87 have the following options:
- Get push notifications about new mail that comes to this label.
- Show the mail from this label in the aggbox.
- Mark incoming mail to this label as read.
- If the sender is new, screen (hold) their emails until they pass a simple challenge to make sure they’re human.
- Include this label in the list of addresses sent to people when they try to mail your bare address.
In the app, I can present these as toggles, but there isn’t a way to do that in IMAP.
IMAP also isn’t aware of an address being mapped to a label, so in the app when you hit reply or compose, it will use the address of the label as the From address. In IMAP/SMTP, you’ll have to adjust that yourself every time.
So basically, I’m going to try to make using a third party app the best experience I can, but there are limitations at the protocol level that will be very difficult to work around.
With ProtonMail filters you can do the same. Custom domain with all-catch address, use service-name@customdomain.com and use filters to send them the desired folder, or spam or delete it
That’s what I was doing when I came up with this idea. It works well, but you have to create a filter every time you sign up somewhere. Also with mine you can screen senders (when someone new emails a label with screening, it will email them back a link to click to prove they’re human before the email is delivered).
I think Fastmail already handles this gracefully, and has all the right integrations. Why should I use your service over Fastmail?
For example, the integration with Bitwarden can generate a new username for every site you go on.
I think to an attacker, your naming allows for identification of the pattern.
Also, 100% spam identification… nothing in the world is 100%. Unless you count the verification for someone to send you an email, which I don’t know if I consider spam identification.
I’ve never used Fastmail, so I don’t know what it’s like. You’re welcome to try mine out, and if there’s something you would like me to add, I’m open to suggestions. :)
So the 100% spam block rate is talking about the prototype, which is what I was doing with ProtonMail and my Gmail account (which is where I prototyped the screening system). I’ve never gotten spam in my inbox in those places since I set up these systems. I’m not saying it’s impervious to spam, but I am saying spamming it is not really easy. If you start to get spam in a label, you can just block that label and change your address to a new label’s address for whatever account that is.
This is where I think the flaw is in your system. You wouldn’t necessarily want to give your friends evul-friends@foo.com. Because once you start getting spam to it, you can’t nuke the email, because more then one person has it.
This is why one address per recipient or service makes the most sense. Not user defined, but completely random or maybe what the Fastmail automated emails do.
I suggest doing some market research before building your product/service so you are designing something that has the best fit for your consumer, and I think Fastmail handles things better than your service would right now, based upon what you’ve shared.
That’s why you’d use screening on evul-friends@foo.com. Spam mail generally doesn’t have a valid Return-Path, and if it does, it’s probably not a monitored mailbox, so the spammer wouldn’t even receive the screening email, let alone follow the instructions in it.
(By not valid, I mean a return path that leads to an actual mailbox. It can be a valid email address, just a bogus or spoofed one.)
I think you are misconstruing spam in this context.
While you are right about “spam” mail not meeting valid header details or authentication, a lot of “spammy” content does - marketing emails.
fastmails aliased emails allow for users to generate unique email addresses for each individual service they sign up for. What this enables is that when that service inevitably sells that email address to another spammy, potentially legitimate, but still spammy provider. They can then unsubscribe from that alias email entirely.
What you are describing seems less focused on protecting one address from being sold and shared. I think you need to accommodate for the fact that businesses sell lists of email addresses against their users wishes. That use case doesn’t seem to be met yet
Congrats on doing your part. We need more privacy focus emails Competition and alternatives are great, I wish you success!
Why should I use this over email aliasing services like addy.io or simplelogin?
Mostly because mine is automatic. You don’t have to set anything up in advance. I was at the gym the other day, and I just put in hperrin-planetfitness@port87.com, and later when I checked my phone, the “planetfitness” label was there in my pending labels. I’m pretty sure they’re going to send me ads, so I’m just going to block the label once I’m sure I’m not going back.
But also I think it’s a really good email system, but I’m biased, because I made it. :)
Kudos dude! I will definitely try this out ✨
Svelete is quite fantastic.
This is awesome! The way this works is what I’ve been doing for years by manually creating different emails. Mymail.streaming@gmail, myemail.work@gmail, myemail.medical@gmail et cetera .I have literally dozens of Gmail accounts to keep things organized. The idea of people able to transition that to a single address sounds amazing. Can’t wait to get approved.
Fastmail offers this as well. I suggest looking into their offerings.
Definitely will try this out.
Are all of its components open source?
Not all. It’s made of mostly open source components though, with proprietary parts added on top. Here are the open source components it uses:
Components by others:
- Node.js
- Express.js
- Haraka
- SvelteKit
- Svelte
Components made by me:
- Nymph.js
- Svelte Material UI
(These lists are not exhaustive.)
I am also going to incorporate Nephele (the WebDAV server) and a yet to be named IMAP server into it, which are open source projects of mine.
