- cross-posted to:
- coolwebsites
- cross-posted to:
- coolwebsites
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 [email protected], 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.
deleted by creator
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 “–“.
Yeah, this fundamentally breaks email addresses since [email protected] is the same as [email protected]. If someone’s name is hyphenated and they’ve been able to use that in every other email address, it breaks their email.
Hyphens aren’t allowed in Port87 usernames in order to prevent a situation like this. It’s surprising what is actually allowed to be an email address.
“Some Guy”@[192.168.0.5]
That’s a valid email address. There aren’t really any email services that don’t put limits on usernames though. Your Gmail username can’t be “Some Guy”.
I get that but you’re disallowing valid email addresses to do so. Gmail does actually allow you to use that email address. You would create it as [email protected] and then you can address it to "Some Guy"@gmail.com because Google treats spaces and periods the same since spaces aren’t allowed without quotes.
I like what you’re doing here, I’m just pointing out a major issue with how you’re implementing it. You could have literally chosen any character as the delimiter so it’s weird to me that you chose one that’s so useful vs. others that are not.
I chose it because it is universally accepted. It works everywhere, as opposed to plus, which doesn’t work in a number of places. It doesn’t really matter that it disallows valid addresses. Every provider disallows valid addresses. [email protected] is another valid address, and you can’t register it.
deleted by creator
Also tagged addressing, subaddressing, or mail extensions. Mine is not the first service to use hyphen. The Courier server also uses hyphen. Also, with mine you can use a plus or a hyphen.
deleted by creator
I’m assuming you mean hard code, and I’m not sure what you mean by that. I told you, you can use a plus or a hyphen. Both will work the exact same. If you want to use a plus, you can exclusively use a plus.