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.
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.
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.
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.
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?
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.
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.
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.
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).
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).
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.
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
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
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 :).
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.
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...
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.
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
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).
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.
cloudmanic | 5 hours ago
[OP] edpin2000 | 4 hours ago
hmokiguess | 4 hours ago
[OP] edpin2000 | 4 hours ago
jlm66 | 4 hours ago
asdff | 3 hours ago
[OP] edpin2000 | 3 hours ago
[OP] edpin2000 | 3 hours ago
mkirsten | 3 hours ago
[OP] edpin2000 | 3 hours ago
mahboi | 3 hours ago
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.
xlii | 3 hours ago
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?
[OP] edpin2000 | 3 hours ago
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?
amflare | 3 hours ago
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.
_djo_ | 3 hours ago
[OP] edpin2000 | 2 hours ago
bch | 2 hours ago
[0] https://www.rfc-editor.org/rfc/rfc5233
[1] https://news.ycombinator.com/item?id=43952475
DoctorOW | 3 hours ago
[OP] edpin2000 | 3 hours ago
drayfield | 3 hours ago
tmarice | 3 hours ago
clickety_clack | an hour ago
mmcclure | 53 minutes ago
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.
[OP] edpin2000 | 3 hours ago
ssivark | 3 hours ago
ssivark | 3 hours ago
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?
[OP] edpin2000 | 2 hours ago
LewisOrton | 2 hours ago
zatkin | 2 hours ago
[OP] edpin2000 | 2 hours ago
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?
lucb1e | an hour ago
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
another-dave | 2 hours ago
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
jambalaya8 | 2 hours ago
aleksiy123 | 2 hours ago
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.
popupeyecare | 2 hours ago
You can use the same tech to build throwaway accounts like you are envisioning. Problem is that it would be prohibitively expensive.
eosis | 2 hours ago
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...
popupeyecare | 2 hours ago
structief | an hour ago
peanut-walrus | an hour ago
lucb1e | an hour ago
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
srhngpr | an hour ago
AuthAuth | an hour ago
rikkipitt | 42 minutes ago
Great innovation, hope it goes well for you.
dandaka | 36 minutes ago
[OP] edpin2000 | 28 minutes ago