So many companies send emails with multiple different address. For example, Citibank could send from citicards@info6.citi.com or CustomerService@thankyou.citi.com. Bank of America can be communications@servicing.bankofamerica.com or onlinebanking@ealerts.bankofamerica.com. 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.
Ah, but Clova handles that. It locks to the domain, not the sender or the subdomain. So both your examples would still be allowed (citi.com and bankofamerica.com). There are also permanent inboxes in the system, which allow anyone. The trick is to delete them after a while when they get polluted with spam.
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).
It doesn't right now. I'm thinking about options and so far all seem either "too much work" for the user. A few options:
1) a button to release the lock and allow the next sender to lock it again (only works for renames like you mention, facebook.com -> meta.com but not for apple.com and icloud.com sending together).
2) A button to manually add related domains. This is too much work because users can't guess new domains easily. I had betterstack.com email me as that and also as betterstackhq.com.
3) Allow up to 3-5 domains and let users block them manually. I feel this option is what permanent inboxes are for -- Clova already has an option to block entire senders (the whole domain or just a user).
4) Plugin some logic or AI in the backend to help categorize things together and understand that betterstack.com and betterstackhq.com are the same thing, apple.com, icloud.com etc are related, etc.
Put the auto rejects into its own list and let the user add it to an existing inbox.
So if I have have the inbox for Facebook.com email, then I notice unsorted messages coming from meta.com, I can merge this into the Facebook inbox. You can probably guess and recommend the correct merge because they’ll inbox in the To: line is already known.
I think if you’re centralizing the data for merging across all users, you can really get smart about recognizing or train an agent on that info.
I don’t think you should ever totally trash an email though. This will lose you users over time. Put them in a list/folder. Similar to how there are Junk and Spam folders where flagged emails get put. The user still gets to have those emails in case they need them or a false flag occurs.
Yeah, that is a good point. We all hate spam, but not receiving something might be worse. We do offer "permanent" inboxes, so that's the easy solution. But if no one will use one-sender or prefix, then that defeats the purpose. Something to think about. In the initial design I had something like that, a list of "blocked" emails. But that just adds more work for people to do...
The convenience of having the first email in "claim" the inbox sounds nice, but how do you stop bad actors from claiming other genuine businesses before you've done business with them? ex., one fast food company spamming all of their competitors' names for your accounts?
What's the difficulty in letting someone manually add more domains, or replace the existing domain explicitly without going through a "release inbox, and the next email can claim it again" dance?
I really like this idea, but only in theory right now.
You could gather enough data to be able to handle big known players. Randoms get the single claim treatment, and for big services used by a lot of people you could learn the domains and allow adjacent domains.
met someone a few weeks ago. They said their email address is @<german ISP>.de but half the time they're sending from @icloud.com, I guess because they have an phone from Apple and don't understand the settings
I volunteer at a library where people can come with tech questions. Just last week, someone asked to help sort out their email addresses because they have various, from Microsoft, from an ISP, and because they have an Apple phone of course Apple also pushed an icloud address onto them that they didn't want
Seems quite common to have a second sending address with how Apple is pushing its lock-in (email addresses are some of the hardest things to migrate). Though, also without that, I tend to think people typically migrate their primary email address at least once or twice in a lifetime, not counting business emails that are sometimes also allowed for reasonable amount of private use (not saying that's a good idea but people do it). Not that unusual
If Apple "pushes an iCloud address onto you" that you don't want, why not just freaking ignore it completely? Don't share it with friends, they won't know about it. Don't ever log into it. Ignore it.
Who cares?
FWIW I use my free iCloud email account with my custom domain since Apple (unlike Google) offers that as a free service. However, I just forward all email to my GMail address and use a custom reply-to in GMail so it _seems_ like I'm using the custom domain in both directions.
> Don't share it with friends, they won't know about it. Don't ever log into it.
Doesn't Apple helpfully offer logging in with their email address constantly? At any rate, they were receiving emails on it and I don't think the user knew how to add an email address. They couldn't find their email client's account settings in iOS, but they struggled with several inboxes in the email client.
I assume that when you start using the device (since that requires Apple account tying) they create a new 'free' email address and provision it onto your devices. From what I later found online, indeed Apple has separate settings for their cloud offerings as compared to when you buy it from a competitor, which afaik is anticompetitive but until all countries get around to sending desist notices... apple does what apple does best
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).
Masked emails are infinitely shareable eg. a spammer can harvest that email address and then reach you. You don't typically have a setting to block anyone else (other than the original intended counter-party) from reaching you -- unless you set up some specific filtering rule (if that's even supported).
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.
This is what I do, and my usage is very similar pattern to the posted project.
Everything gets {service}@{type}.mydomain.com, so, for example, twitter@social.mydomain.com. I really only use the subdomain for some automated tagging, but it's come in handy.
I used to accept *@mydomain, until spammers started sending spam to completely random addresses. Suddenly I received hundreds of copies of every spam mail, addressed to random combinations of characters @mydomain.
Yeah but that's obviously guessable. Twitter_hrejb@example.com can be traced back to a Twitter DB leak, because otherwise there's no way to guess the "hrejb".
> Yeah but that's obviously guessable. Twitter_hrejb@example.com can be traced back to a Twitter DB leak, because otherwise there's no way to guess the "
Thats exactly what is do. A random combination of three after the service. Works perfectly
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.
The email protocol allows all senders, but you’ve always had the option to configure your client to delete all incoming messages based on whatever criteria you see fit. Technically it still hits your email server but it’s effectively the same as what UX you want on client side.
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.
This is what finally made email useful for me again. I use hey.com email and the Screener whitelist is probably the most important feature. (Selective notifications being the second most useful for me.)
I think this could work for text messages, too. All new texts could go to a screener and don't notify until you opt-in.
That defeats the purpose. If I have an email, I want to be reachable. We just need a good spam detector...oh wait, that's pretty much solved already :)
Anyway, nothing against the posted project! I think it's cool.
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. chase@johndoe.com, att@johndoe.com. Pretty easy.
Same - very easy to setup with Cloudflare Email Routing and no fees. All email gets forwarded to an obscure Gmail, and use Amazon SES for sending emails (also ends up being free due to super low volume of emails).
I've been using my own domain with a catchall for over 10 years and never had problems with spam. Spammers tend to send to harvested address lists, not just try to send to random mailboxes for a domain.
The backscatter can be annoying though. I had none for over 10 years either but it's picking up now to perhaps a few per month. Looking around how to prevent it, apparently "backscatter" is an established term for the phenomenon that you can't fix, where you receive rejected spam emails, and they're often sent from randomly generated prefixes @ your domain (no matter that you have SPF/DKIM/etc. set up). My partner also gets waves of autoreplies, like "your support ticket will be handled soon" and "I'm out of office until ...", where someone seems to have used their domain with a random prefix no apparent reason
The solution is probably to tell the senders that they're effectively sending out spam / doing a variant of open relaying by emailing the spoofed address, but even internet-savvy institutions like an IP address assigning organization (RIPE) sends me backscatter so I don't have a ton of hope
I finally gave up on using catch-all, and now only allow e-mail to addresses @mydomain.com that follow a certain pattern. If someone were to specifically target me and look closer at all the addresses I use, they would quickly figure out the pattern, but I see no reason why a spammer would do that.
*@mydomain.com worked fine for me for about 15 years, then suddenly spammers started doing exactly that, sending e-mails to random addresses. I would get countless copies of every spam message, addressed to completely random combinations of characters @mydomain.com.
I forward my catch-all to gmail so I get they're great spam filtering while preserving the ability to switch off of them instantly should I decide to in the future.
Same. I've done this for years with my crappy namecheap web host email. Works great. Pro tip. Just setup a subdomain on a domain you already own. This makes filtering even easier.
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 <your-neighbour@gmail.com> 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 `alice@acme.com` saying, please coordinate with `bob@our-recruiter-consultancy.com` who'll arrange the interview but Bob can't contact you
Seems very nice. I'll start trying it out. Just have to pick my prefix :)
In the past I have used Mailinator's public inboxes for one time code messages and anonymous subscriptions, but their success was also their own demise since several sites stopped accepting Mailinator emails.
Clova's design seems much better. With the possibility of having "legitimate" one sender only inboxes, a site refusing to accept such e-mail becomes more unlikely.
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?
Agents can create new inboxes and inboxes can be of 3 types, besides "Permanent" which is just a regular inbox. The other types don't have "rules" that you can customize. Instead the rules are baked-in: Temporary -> expires after some time, One-sender: allows only one sender (the first one to prove its email identity), Prefix: similar to one-sender but creates a new inbox for every suffix (and if spammers catch on to the prefix, you can delete it and create a new one).
I built https://statphone.com which is one emergency number that dials multiple people and shows up as itself on the caller ID so you know it's urgent.
You can use the same tech to build throwaway accounts like you are envisioning. Problem is that it would be prohibitively expensive.
This is a great idea, but I think it's worth reconsidering the "first person to answer, handles it" logic. All the folks who didn't answer in time are now panicked with no idea what's going on.
Instead, you could make it so anyone who answers after the first person starts out muted and hears a message like: "Uncle Bob's on the line, press 1 to join the call or stay on the line to listen quietly." They could then choose whether or not to join in.
Just a thought! Great idea nonetheless — I'd buy it if I had a valid use case!
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.
What I really want is for unauthenticated senders to be reliably blocked. Even Gmail/Gsuite will allow spoofed emails from the same domain, though it may flag them as spam. I get that there are special circumstances where a legitimate sender can't authenticate itself, but that's their problem.
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.
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.
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"?
Email allows "+<suffix>" to be appended to any email.
The usual case is something like "user+testing@site.com", or "user+bills@site.com".
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.
I used to do this when I could, but many poorly written email validators reject such addresses. (One service, Rappi, was so gloriously, hopelessly broken that they spammed me now and then at the address with a + in it but I couldn't use it to log in!)
Now I just use Fastmail's masked address feature. (And I do not use Rappi.)
I remember a scheme from the 90s that put a keyed hash in there - and a filter that only accepted valid ones - checked with a key. I think there was an optional date (valid-to).
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.
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 :).
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
True. it works well. I found the interface a bit lacking but they can always improve. The free tier is limited to a few days or weeks and then it's paid. If you're a low needs customer, having a permanent free tier is nice.
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?
If your current email is on your own domain, you can! Just a DNS change and a few configuration steps and all new messages land in your new inbox. If you have something like gmail or outlook, then you can still do it with a simple configuration change there to forward emails. On gmail I know you can create filters (rules) to forward to different inboxes even, so current subscriptions could land in different Clova inboxes. Email me at support at clova dot email and I'll guide you through some options.
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...
So many companies send emails with multiple different address. For example, Citibank could send from citicards@info6.citi.com or CustomerService@thankyou.citi.com. Bank of America can be communications@servicing.bankofamerica.com or onlinebanking@ealerts.bankofamerica.com. 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.
Ah, but Clova handles that. It locks to the domain, not the sender or the subdomain. So both your examples would still be allowed (citi.com and bankofamerica.com). There are also permanent inboxes in the system, which allow anyone. The trick is to delete them after a while when they get polluted with spam.
banks also often have multiple domains - different one for transactional emails, different one for statements etc.
Instead of auto-locking it should be possible as user to configure the list of allowed domains that land there.
I have had banks using different domains totally, like bank.com and bank.email and notifications.bank.com etc.
And then you have India where every bank domain is required to end in .bank.in
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).
It doesn't right now. I'm thinking about options and so far all seem either "too much work" for the user. A few options:
1) a button to release the lock and allow the next sender to lock it again (only works for renames like you mention, facebook.com -> meta.com but not for apple.com and icloud.com sending together).
2) A button to manually add related domains. This is too much work because users can't guess new domains easily. I had betterstack.com email me as that and also as betterstackhq.com.
3) Allow up to 3-5 domains and let users block them manually. I feel this option is what permanent inboxes are for -- Clova already has an option to block entire senders (the whole domain or just a user).
4) Plugin some logic or AI in the backend to help categorize things together and understand that betterstack.com and betterstackhq.com are the same thing, apple.com, icloud.com etc are related, etc.
Anything else?
Put the auto rejects into its own list and let the user add it to an existing inbox.
So if I have have the inbox for Facebook.com email, then I notice unsorted messages coming from meta.com, I can merge this into the Facebook inbox. You can probably guess and recommend the correct merge because they’ll inbox in the To: line is already known.
I think if you’re centralizing the data for merging across all users, you can really get smart about recognizing or train an agent on that info.
I don’t think you should ever totally trash an email though. This will lose you users over time. Put them in a list/folder. Similar to how there are Junk and Spam folders where flagged emails get put. The user still gets to have those emails in case they need them or a false flag occurs.
Yeah, that is a good point. We all hate spam, but not receiving something might be worse. We do offer "permanent" inboxes, so that's the easy solution. But if no one will use one-sender or prefix, then that defeats the purpose. Something to think about. In the initial design I had something like that, a list of "blocked" emails. But that just adds more work for people to do...
Tis the nature of communications, email is a chore for sure. It's mighty useful though
The convenience of having the first email in "claim" the inbox sounds nice, but how do you stop bad actors from claiming other genuine businesses before you've done business with them? ex., one fast food company spamming all of their competitors' names for your accounts?
What's the difficulty in letting someone manually add more domains, or replace the existing domain explicitly without going through a "release inbox, and the next email can claim it again" dance?
I really like this idea, but only in theory right now.
You could gather enough data to be able to handle big known players. Randoms get the single claim treatment, and for big services used by a lot of people you could learn the domains and allow adjacent domains.
> It may seem a bit unusual
met someone a few weeks ago. They said their email address is @<german ISP>.de but half the time they're sending from @icloud.com, I guess because they have an phone from Apple and don't understand the settings
I volunteer at a library where people can come with tech questions. Just last week, someone asked to help sort out their email addresses because they have various, from Microsoft, from an ISP, and because they have an Apple phone of course Apple also pushed an icloud address onto them that they didn't want
Seems quite common to have a second sending address with how Apple is pushing its lock-in (email addresses are some of the hardest things to migrate). Though, also without that, I tend to think people typically migrate their primary email address at least once or twice in a lifetime, not counting business emails that are sometimes also allowed for reasonable amount of private use (not saying that's a good idea but people do it). Not that unusual
If Apple "pushes an iCloud address onto you" that you don't want, why not just freaking ignore it completely? Don't share it with friends, they won't know about it. Don't ever log into it. Ignore it.
Who cares?
FWIW I use my free iCloud email account with my custom domain since Apple (unlike Google) offers that as a free service. However, I just forward all email to my GMail address and use a custom reply-to in GMail so it _seems_ like I'm using the custom domain in both directions.
> Don't share it with friends, they won't know about it. Don't ever log into it.
Doesn't Apple helpfully offer logging in with their email address constantly? At any rate, they were receiving emails on it and I don't think the user knew how to add an email address. They couldn't find their email client's account settings in iOS, but they struggled with several inboxes in the email client.
I assume that when you start using the device (since that requires Apple account tying) they create a new 'free' email address and provision it onto your devices. From what I later found online, indeed Apple has separate settings for their cloud offerings as compared to when you buy it from a competitor, which afaik is anticompetitive but until all countries get around to sending desist notices... apple does what apple does best
>think of like Facebook originally sending from facebook.com
ahem, didn't they originally send from thefacebook.com ? (back when facebook.com was owned by someone else)
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.
I love this message. Your advice was:
* Actionable
* Constructive
* Succinct
* Borne out of relevant experience
And you were sure to thank them for the contribution. This is a model HN comment.
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).
Masked emails are infinitely shareable eg. a spammer can harvest that email address and then reach you. You don't typically have a setting to block anyone else (other than the original intended counter-party) from reaching you -- unless you set up some specific filtering rule (if that's even supported).
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.
If you have 1000, it might be better to just set up a custom domain and just use a wildcard alias.
This is what I do, and my usage is very similar pattern to the posted project.
Everything gets {service}@{type}.mydomain.com, so, for example, twitter@social.mydomain.com. I really only use the subdomain for some automated tagging, but it's come in handy.
I used to accept *@mydomain, until spammers started sending spam to completely random addresses. Suddenly I received hundreds of copies of every spam mail, addressed to random combinations of characters @mydomain.
Yeah but that's obviously guessable. Twitter_hrejb@example.com can be traced back to a Twitter DB leak, because otherwise there's no way to guess the "hrejb".
> Yeah but that's obviously guessable. Twitter_hrejb@example.com can be traced back to a Twitter DB leak, because otherwise there's no way to guess the "
Thats exactly what is do. A random combination of three after the service. Works perfectly
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.
The email protocol allows all senders, but you’ve always had the option to configure your client to delete all incoming messages based on whatever criteria you see fit. Technically it still hits your email server but it’s effectively the same as what UX you want on client side.
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.
This is what finally made email useful for me again. I use hey.com email and the Screener whitelist is probably the most important feature. (Selective notifications being the second most useful for me.)
I think this could work for text messages, too. All new texts could go to a screener and don't notify until you opt-in.
That defeats the purpose. If I have an email, I want to be reachable. We just need a good spam detector...oh wait, that's pretty much solved already :)
Anyway, nothing against the posted project! I think it's cool.
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. chase@johndoe.com, att@johndoe.com. Pretty easy.
Same - very easy to setup with Cloudflare Email Routing and no fees. All email gets forwarded to an obscure Gmail, and use Amazon SES for sending emails (also ends up being free due to super low volume of emails).
Do you have Open Tofu recipe for this? Sounds really cool
You must love all the spam you're getting with a catch-all!
I've been using my own domain with a catchall for over 10 years and never had problems with spam. Spammers tend to send to harvested address lists, not just try to send to random mailboxes for a domain.
The backscatter can be annoying though. I had none for over 10 years either but it's picking up now to perhaps a few per month. Looking around how to prevent it, apparently "backscatter" is an established term for the phenomenon that you can't fix, where you receive rejected spam emails, and they're often sent from randomly generated prefixes @ your domain (no matter that you have SPF/DKIM/etc. set up). My partner also gets waves of autoreplies, like "your support ticket will be handled soon" and "I'm out of office until ...", where someone seems to have used their domain with a random prefix no apparent reason
The solution is probably to tell the senders that they're effectively sending out spam / doing a variant of open relaying by emailing the spoofed address, but even internet-savvy institutions like an IP address assigning organization (RIPE) sends me backscatter so I don't have a ton of hope
I finally gave up on using catch-all, and now only allow e-mail to addresses @mydomain.com that follow a certain pattern. If someone were to specifically target me and look closer at all the addresses I use, they would quickly figure out the pattern, but I see no reason why a spammer would do that.
*@mydomain.com worked fine for me for about 15 years, then suddenly spammers started doing exactly that, sending e-mails to random addresses. I would get countless copies of every spam message, addressed to completely random combinations of characters @mydomain.com.
I forward my catch-all to gmail so I get they're great spam filtering while preserving the ability to switch off of them instantly should I decide to in the future.
Been running my own mail server with this setup for over 10 years. This really hasn't been a problem for me at all... Yet
Same. I've done this for years with my crappy namecheap web host email. Works great. Pro tip. Just setup a subdomain on a domain you already own. This makes filtering even easier.
Yes, but replying can be a pickle.
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 <your-neighbour@gmail.com> 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 `alice@acme.com` saying, please coordinate with `bob@our-recruiter-consultancy.com` who'll arrange the interview but Bob can't contact you
Seems very nice. I'll start trying it out. Just have to pick my prefix :)
In the past I have used Mailinator's public inboxes for one time code messages and anonymous subscriptions, but their success was also their own demise since several sites stopped accepting Mailinator emails.
Clova's design seems much better. With the possibility of having "legitimate" one sender only inboxes, a site refusing to accept such e-mail becomes more unlikely.
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?
Agents can create new inboxes and inboxes can be of 3 types, besides "Permanent" which is just a regular inbox. The other types don't have "rules" that you can customize. Instead the rules are baked-in: Temporary -> expires after some time, One-sender: allows only one sender (the first one to prove its email identity), Prefix: similar to one-sender but creates a new inbox for every suffix (and if spammers catch on to the prefix, you can delete it and create a new one).
a unified solution for both old and new problems! such a nice idea. i liked gmail's "+" variant but yours are way cooler
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.
I built https://statphone.com which is one emergency number that dials multiple people and shows up as itself on the caller ID so you know it's urgent.
You can use the same tech to build throwaway accounts like you are envisioning. Problem is that it would be prohibitively expensive.
This is a great idea, but I think it's worth reconsidering the "first person to answer, handles it" logic. All the folks who didn't answer in time are now panicked with no idea what's going on.
Instead, you could make it so anyone who answers after the first person starts out muted and hears a message like: "Uncle Bob's on the line, press 1 to join the call or stay on the line to listen quietly." They could then choose whether or not to join in.
Just a thought! Great idea nonetheless — I'd buy it if I had a valid use case!
Great idea nonetheless though!
Marketing needs some work. I don't really understand your website copy.
It's an uphill battle to trust my email to a 1-person startup. Website doesn't look very professional. Video has weird copy in it, and AI voice.
Perhaps start with a self hosting option until you gain footing.
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.
What I really want is for unauthenticated senders to be reliably blocked. Even Gmail/Gsuite will allow spoofed emails from the same domain, though it may flag them as spam. I get that there are special circumstances where a legitimate sender can't authenticate itself, but that's their problem.
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.
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.
That's been my experience too. That's why prefix inboxes allow any suffix, including "-", "_", "$", "!" etc.
The “x+tag@domain.com” format is also rejected by many validators, sadly. I thought this was a gmail feature, but was corrected[0][1] a while ago.
[0] https://www.rfc-editor.org/rfc/rfc5233
[1] https://news.ycombinator.com/item?id=43952475
Seems like the temporary address can only be used to receive email, you can't send email from it. Is this by design?
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"?
Isn’t this functionality identical to an approved senders list?
Why this extra complication?
I could just have a normal email and block any domain I haven’t approved, ya?
Your website needs to make this more clear.
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 "user+testing@site.com", or "user+bills@site.com".
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.
I used to do this when I could, but many poorly written email validators reject such addresses. (One service, Rappi, was so gloriously, hopelessly broken that they spammed me now and then at the address with a + in it but I couldn't use it to log in!)
Now I just use Fastmail's masked address feature. (And I do not use Rappi.)
I remember a scheme from the 90s that put a keyed hash in there - and a filter that only accepted valid ones - checked with a key. I think there was an optional date (valid-to).
So you might give someone an address like:
dell-rep-01012027-<hash>@anymail example.com
Isn't that a gmail-only feature?
It's almost as old as SMTP - with various implementations in exim, qmail, postfix etc (plus/minus, minus, plus seperator).
"email suffix addresses".
Gmail and o365 support it, not sure about Apple.
https://www.rfc-editor.org/info/rfc5233/
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.
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.
Yes it does. DMARC/SPF/DKIM and spam checking.
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 :).
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
Interesting. Thanks for the suggestion. I was thinking some whois heuristics could do too, but there are so many corner cases.
feed the whois data to jev also
Been paying $12/yr for Firefox Relay Premium and have been happy with it so far. You get a dedicated (non customizable) subdomain.
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.
True. it works well. I found the interface a bit lacking but they can always improve. The free tier is limited to a few days or weeks and then it's paid. If you're a low needs customer, having a permanent free tier is nice.
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?
You mean, when the same sender changes domains? This is rare, but I'm thinking about allowing the lock to reset, if one chooses to.
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.
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!
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?
I wish your service could replace my email in all services that has it already
If your current email is on your own domain, you can! Just a DNS change and a few configuration steps and all new messages land in your new inbox. If you have something like gmail or outlook, then you can still do it with a simple configuration change there to forward emails. On gmail I know you can create filters (rules) to forward to different inboxes even, so current subscriptions could land in different Clova inboxes. Email me at support at clova dot email and I'll guide you through some options.
Sorry, you lost me at "Zero Spam."
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...