Nice idea! JFYI, in case you ever run into design questions when extending this, you seem to be implementing a version of Object Capabilities (specifically revocable forwarders / caretaker pattern), specialized for the SMTP situation -- as you want to share with someone the capability to send you messages, but you want that capability to not be shared recursively.
Since you're also thinking about a user giving their agent access to their inbox -- any thoughts on what are the right capability primitives for that situation, and how the API & access tokens can represent that?
For context I'm sleep deprived so sorry if I've missed something obvious, but what differentiates this with something like Fastmail's masked email offering? I use unique emails for every service I use and it works beautifully. This seems... more complicated? I under there's a price difference, but little else.
It aims to be simpler. It's not a mask. It has forwarding as an option but the idea is that you can use one of the inbox types for different needs. The one I use the most is prefix, because you create it once and then you can tack on any suffix to it. When the first sender reaches you, that suffix become locked to their domain (or account, if it's a gmail, outlook, yahoo, etc). That seems pretty useful for subscriptions. For one-time codes, just create a temporary one every so often. It has the option to delete itself (and optionally take the email with it).
I recently found out there is a limit to the number of masked emails you can have on Fastmail (1000, iirc -- definitely not infinite for practical purposes). Also, I miss the option of being able to create masked emails on all the domains I connected to Fastmail -- you can only use the "main" one.
Email, snail mail, text messages etc. all need, IMO, options for ONLY allowing incoming messages from known sources. This seems like it is really aiming to do that for Email and I applaud the effort. Hopefully, it will take off in a big, big way.
True. I find setting up rules and adding to contacts adds work to my day-to-day though. I'm hoping to make something simple and seamless. Prefix inboxes are as simple as I could think so far: make one up, add a suffix on the spot when you handout an email address -- boom, locked to the first one who uses it.
You can already do this with any normal email account. Just do myemail+whatever@domain.com. You can put anything you want behind the +, and it still works.
i.e. myemail+chase@domain.com, myemail+huffpost@domain.com, myemail+facebook@domain.com.
This used to be used as some sort of automatic labeling system that was supposed to be part of the spec eons ago, but it works just fine for generating unique emails so that you can see if/when an email has been leaked.
I think the benefit is supposed to be the locking feature. Any human that sees myemail+chase@domain.com and wants to circumvent your filters to get to your main inbox (typically for sales purposes) can figure out to email myemail@domain.com. With this product, the email is undeliverable unless they label their emails correctly.
Exactly. Even bots can strip the "+" and bombard you with junk. With a prefix inbox you can invent any suffix. I have a "service" prefix that I add suffixes to it when I need: "service-netflix", "service$bank", "service.newsletter-1". I don't need to pre-create each one, only "service" is enough and then any suffix locks to the sender. They can't sell your email. And they may never know to invent a new suffix because they don't know where the prefix starts. You can make it "sdfawetr" if you want.
Nice and looks helpful. It’s crazy when you think about it - email is so prevalent in our lives, yet the scope of innovation last 20 years is that we can react to an emails with emojis.
If anyone is reacting to my emails, I'm not seeing it, might be some vendor-specific thing :/ Which is fine, I don't want that.
The more annoying thing is there's no obviously reliable way to prevent a sender from spoofing the address. Even Gmail/Gsuite will allow spoofed emails from the same domain, though it may flag them as spam.
That's so true. Gmail used to be cool, now it's old and clunky and their "unsubscribe" feature does not do that reliably. I want to tackle that next, look at domains that continue to email people after they unsubscribe.
On the "+" sign comment: I find that many spammers already know the trick. That's why I built a prefix where any suffix will work. If you have "turtle" as a prefix, you can add "turtle$bank", "turtle-barber", etc on the spot, without having to create each suffix.
As for single sender, we attach to the domain, so *.github.com would be allowed. The main problem, to be honest, is when email comes from apple.com, icloud.com, applehq.com, etc. I'm considering a power-feature where you could pre-select a few domains or allow all and then lock it. I feel it would be best for power users only. What do you think?
Nice idea! JFYI, in case you ever run into design questions when extending this, you seem to be implementing a version of Object Capabilities (specifically revocable forwarders / caretaker pattern), specialized for the SMTP situation -- as you want to share with someone the capability to send you messages, but you want that capability to not be shared recursively.
Since you're also thinking about a user giving their agent access to their inbox -- any thoughts on what are the right capability primitives for that situation, and how the API & access tokens can represent that?
For context I'm sleep deprived so sorry if I've missed something obvious, but what differentiates this with something like Fastmail's masked email offering? I use unique emails for every service I use and it works beautifully. This seems... more complicated? I under there's a price difference, but little else.
It aims to be simpler. It's not a mask. It has forwarding as an option but the idea is that you can use one of the inbox types for different needs. The one I use the most is prefix, because you create it once and then you can tack on any suffix to it. When the first sender reaches you, that suffix become locked to their domain (or account, if it's a gmail, outlook, yahoo, etc). That seems pretty useful for subscriptions. For one-time codes, just create a temporary one every so often. It has the option to delete itself (and optionally take the email with it).
[delayed]
I recently found out there is a limit to the number of masked emails you can have on Fastmail (1000, iirc -- definitely not infinite for practical purposes). Also, I miss the option of being able to create masked emails on all the domains I connected to Fastmail -- you can only use the "main" one.
Email, snail mail, text messages etc. all need, IMO, options for ONLY allowing incoming messages from known sources. This seems like it is really aiming to do that for Email and I applaud the effort. Hopefully, it will take off in a big, big way.
I hope so too. I hope I have the right set of features so far. Happy to hear thoughts and early feedback.
Email at least you can set this up with a rule that checks the sender against your contacts and throws them into some folder.
True. I find setting up rules and adding to contacts adds work to my day-to-day though. I'm hoping to make something simple and seamless. Prefix inboxes are as simple as I could think so far: make one up, add a suffix on the spot when you handout an email address -- boom, locked to the first one who uses it.
You can already do this with any normal email account. Just do myemail+whatever@domain.com. You can put anything you want behind the +, and it still works. i.e. myemail+chase@domain.com, myemail+huffpost@domain.com, myemail+facebook@domain.com.
This used to be used as some sort of automatic labeling system that was supposed to be part of the spec eons ago, but it works just fine for generating unique emails so that you can see if/when an email has been leaked.
I think the benefit is supposed to be the locking feature. Any human that sees myemail+chase@domain.com and wants to circumvent your filters to get to your main inbox (typically for sales purposes) can figure out to email myemail@domain.com. With this product, the email is undeliverable unless they label their emails correctly.
Exactly. Even bots can strip the "+" and bombard you with junk. With a prefix inbox you can invent any suffix. I have a "service" prefix that I add suffixes to it when I need: "service-netflix", "service$bank", "service.newsletter-1". I don't need to pre-create each one, only "service" is enough and then any suffix locks to the sender. They can't sell your email. And they may never know to invent a new suffix because they don't know where the prefix starts. You can make it "sdfawetr" if you want.
I assume spammers have become adept at stripping anything between + and @ in email addresses, so this isn't as reliable as properly masked addresses.
Nice and looks helpful. It’s crazy when you think about it - email is so prevalent in our lives, yet the scope of innovation last 20 years is that we can react to an emails with emojis.
If anyone is reacting to my emails, I'm not seeing it, might be some vendor-specific thing :/ Which is fine, I don't want that.
The more annoying thing is there's no obviously reliable way to prevent a sender from spoofing the address. Even Gmail/Gsuite will allow spoofed emails from the same domain, though it may flag them as spam.
That's so true. Gmail used to be cool, now it's old and clunky and their "unsubscribe" feature does not do that reliably. I want to tackle that next, look at domains that continue to email people after they unsubscribe.
I think I'm missing something but I've have an option to use <anything>@<ident>.domain.com for couple years now.
I don't find it that useful though and usually go with standard alias i.e. user+<anything>@domain.com
As for single sender locking - not sure how useful that is. I mean you can get github.com email or notifications.github.com so you miss half of them?
On the "+" sign comment: I find that many spammers already know the trick. That's why I built a prefix where any suffix will work. If you have "turtle" as a prefix, you can add "turtle$bank", "turtle-barber", etc on the spot, without having to create each suffix.
As for single sender, we attach to the domain, so *.github.com would be allowed. The main problem, to be honest, is when email comes from apple.com, icloud.com, applehq.com, etc. I'm considering a power-feature where you could pre-select a few domains or allow all and then lock it. I feel it would be best for power users only. What do you think?
This is amazing, my dream has always been that outlook, gmail, and the likes allowed for setting up bounce rules.
Yes! And it can bounce/block any sender and entire domains too (across all your inboxes, if you choose).
I have used this service since I found it on product hunt. I am loving it! My inbox is way cleaner now.
Glad to know it's working for you!