Infinite inboxes, including prefixes where you don't have to create inboxes before you use them -- they self create when you add a suffix.
Three types of inboxes: - One sender. Locks to the first domain to send email (except gmail, outlook, etc where it locks to an email account for obivous reasons. It bounces everyone else. - Temporary. Lasts for a while (24h, 7days, etc) then bounces. Received messages stay or go as per your choice. - Prefix. The most powerful. Declare a prefix like "service" and then invent any suffix, like "service-netflix" or "service$bank" and it creates a new one-sender inbox locked to whoever wrote first.
Bring you own domain. Bring your own AI (MCP server ready). Forwarding.
Please help me test it.
Does your application check DMARC alignment? Otherwise, a spoofed 'from' address will pass through. And also the sender's policy alone is not enough because, gmail.com and outlook.com have DMARC p=none.
I just don't understand it.
How am I merging the inboxes again? Maybe 20 years of using an elaborate system of folders and inbox rules has warped my mind, but I don't want to have 20 inboxes if I get regular mail from 20 companies.
Or does it all forward it to Gmail (which I don't use) after it's "ok"?
How does it handle the scenario where the sender changes the domain they originate from? It may seem a bit unusual, like when a company rebrands (think of like Facebook originally sending from facebook.com, but then sending from meta.com later on).
Sorry, you lost me at "Zero Spam."
I've run email for several decades and I'd like to see: "problem I want to solve" first, rather than "I did this".
Email does work rather well compared to anything else on the internet. Spam (UBE) is a bit of a problem but not insurmountable.
Your second para starting "Three types of inboxes" doesn't make much sense. It looks like grey listing ... and stuff ... and plus prefixing.
Thank you for diving in on making email safer in some way.
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.
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 have my personal domain (let's say johndoe.com) and I have set it up so all (catch-all) emails go to one email. [email protected], [email protected]. Pretty easy.
id integrate a local jev like model and for unknown emails after domain lock, include a valid email and the new email and ask the jev model to rate the likely hood its from the same sender
this sounds really clever.
One suggestion - external contacts won't know that this address will bounce for anyone they add in CC. Maybe have an option where if I include the original whitelisted domain/person in the chain then it will let the mail through even if it's from a non-whitelisted person.
Just thinking of scenarios like, you give out your email address to <[email protected]> who then emails you about a 5-a-side game with a few friends but any messages from any of the other friends bounce.
Or you apply for a job at ACME Inc and then you get a message back from `[email protected]` saying, please coordinate with `[email protected]` who'll arrange the interview but Bob can't contact you
I wanted to build this for phone numbers at some point but it was way outside of my skill level at the time.
I feel like unique address per sender, receiver pair could cut down on so much spam.
And you can see exactly who is leaking your info.
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?
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.
Just an FYI: You can do this with an email
Email allows "+<suffix>" to be appended to any email.
The usual case is something like "[email protected]", or "[email protected]".
It's a way to auto-tag your incoming mail. You can use one of these "+" suffixes on a per-app basis and then add a spam filter to permanently burn one of them if you get spammed.
You can already do this with any normal email account. Just do [email protected]. You can put anything you want behind the +, and it still works. i.e. [email protected], [email protected], [email protected].
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.
Very cool. Love the idea. Wish I'd thought of it as an option on my products: https://www.paced.email and/or https://www.vend.email
Great innovation, hope it goes well for you.
Nice wrapping, I've been setting it up like this with email providers for a while.
I started doing it to catch leaks, and yup, it works.
A bit confused, what if I cannot receive the other emails as they change domain? Where will these emails go?
SimpleLogin.io is a great disposable email service I’ve been using for years.
I have no association with the company besides being a happy customer.
Been paying $12/yr for Firefox Relay Premium and have been happy with it so far. You get a dedicated (non customizable) subdomain.
This is cool. I need this so badly for SMS. All privacy goes out the window when i have to give up my mobile number.
This is amazing, my dream has always been that outlook, gmail, and the likes allowed for setting up bounce rules.
I wish your service could replace my email in all services that has it already
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?
I have used this service since I found it on product hunt. I am loving it! My inbox is way cleaner now.
Pretty Interesting approach! Good Work!
This is good, thank you
Very cool.
I've used fastmail similarly for ages. An issue I have found is services that are really hung up on your email being your id, with annoying coupling like assuming you can only access a meeting if the email invite is the same "user" as the VC you're using...
We used to do stuff like this for sysadmining scripts monitoring Unix boxes back in the 1990s. It worked great for escalation and automation with our alphapagers the way 'wfh' was back in like the mid90s; less laptop bootups :).
[dead]
So many companies send emails with multiple different address. For example, Citibank could send from [email protected] or [email protected]. Bank of America can be [email protected] or [email protected]. If the "Citibank inbox" just takes the first address that Citi happens to use and auto rejects all future others, user will lose critical emails without even knowing. There is no way either user or the app could guarantee an entity will ever only use one address for legitimate reason.