Completely disagree. Security resources are scarce and should be allocated toward protecting secrets.

Non-secrets, like addresses and SSNs, should be rendered harmless rather than squandering resources trying to keep them secret.

Yeah. Email addresses aren't secrets. If any one server or inbox gets popped you're fucked.

Though if you run a full domain you can use emails as one-use affairs. Most don't though and, really, what's the point? It only saves you from journalists, not from a motivated attacker.

> if you run a full domain you can use emails as one-use affairs

or, if you use a service that lets you generate aliases, like gmail's "+", or a service like mailinator.

The problem is that the attack vector of email addresses is they are sometimes used as a username, and therefore contains more information than what is strictly required (for the purpose of a username). Leaking the "real" email address not only leads to spam, but allows a more dedicated attacker to use that email address as a starting point on a different site, or hack the email address altogether.

And with sites increasingly blocking disposable email addresses like mailinator, or disallowing email aliases, the problem can only get worse.

Having your own domain is cheap. Generating an email that’s a function of the target website is trivial. I’ve done it for 20 years.

I can confirm the source of every email breach that contains one of my addresses.

Yep, I do the same. I typically use <sitename>@sites.<domain>.<whatever> for website logins (stored in my password manager, so I don't need to think about it to login), so that if my password ever leaks, I know where it was leaked from.

sadly using elite hacking skills this is easily circumvented

    p0wn3r $cat  testerm
    [email protected]
    [email protected]
    [email protected]
    [email protected]
    
    p0wn3r $cat  testerm | sed 's/+.*@/@/'
    [email protected]
    [email protected]
    [email protected]
    [email protected]

and so if you set up your email filters right, you can find out who is doing this sort sort of "hacking" to get your real email address. What you do afterwards is up to you.

By definition, if someone is offloading your data to a 3rd party and they sanitise the addrs, then you can't tell.

The "+" is not limited to Gmail, it's standard. The problem is many services with fancy mail validation don't accept it.

Does Gmail allow sending from the + addresses? There's quite an issue if somebody contacts you on that address but you reply without the alias.

They do allow it, but it’s a pain to set up for each + address, especially on iOS.

I have not find a way to send email from Gmail, using either the web interface of their SMTP server, from a custom username (left side of @ symbol). I have a custom domain using Google Apps, but to send mail I use a third party SMTP server to customize the username portion of the From field.

I've never had an issue using a different email for support, I always mention that I own the domain or email suffix and they can verify that if they want to (though nobody has so far).

I'd forgotten about the gmail trick. You're certainly right about that. Though I will say one thing: I've not been hiding my email this past decade and—as far as I know—it has not bit me.

> you can use emails as one-use affairs [..] what's the point? It only saves you from journalists, not from a motivated attacker

Can you explain this claim?

If you generate your single-use email addresses wisely, then you should know that the one you gave to - say - Marriott should only ever receive emails from Marriott.

If - say - Marriott gets hacked and that particular one of your many different email addresses leaks, then:

a) you'll find out that address is burned just as soon as anyone other than Marriott uses it (you immediately generate a new one, give it to Marriott, and stop accepting any mail at all on the old one)

and

b) if anyone other than Marriott uses it, you know immediately that that message can't be legit.

c) chances are that all your incoming phishing traffic will arrive at mismatched addresses. Makes it even harder to fall for it in that moment of mental blackout.

But if someone phishes you on [email protected] you're probably more likely to imagine it's legit. Swings and roundabouts.

No-one would know that [email protected] is an email address you can even be reached on, unless it leaks out from BankCo.

ADD: and of course, you aren't really going to stick +BankCo after your real name to generate an email to use with BankCo. You're going to give them something generated like you'd generate a password - "[email protected]" or similar - so if anyone finds out that particular email address for you it doesn't tell them with whom you use it.

But that's a big if because phishers will always aim for the weakest individuals in the flock.

You can do a lot with a SSN in Finland. The first 6 digits are your date of birth followed by 4 random characters. If I had your SSN (and address) I could:

- Phone up the tax office and find out about all your finances, and make adjustments to your tax percentages and affairs.

- Phone your medical provider, and very possibly socially engineer them into revealing medial information. I could book an appointment with your doctor for example and impersonate you on the phone appointment.

- Call all your utility providers and cancel contract without you knowing about it.

- I highly suspect I could call your phone provider and take over your phone number, and in some cases use this to take over your email.

Whilst SSN should not be treated as a non-secret, the reality is that it is a secret and is often the only line of defense when dealing with companies.

And it shouldn't be.

The problem is that using a government issued ID is easy since everyone has one. That's the wrong use for something like a SSN, but you're right, it's what's done in practice.

We should be moving away from that. Government issued ID should merely be the equivalent of a user name, with any real use requiring additional factors of authentication (password, security key, etc). Unfortunately, most of these other factors are also easily accessible (mother's maiden name, date of birth, etc).

Ideally, we'd have something like:

- number issued at birth (like present system), frozen until individual activates it - individual sets password when unfreezing - all accesses must be explicitly allowed by the user - user can grant/revoke/audit access, and access is denied by default - no private data is stored in the account - companies that use the account for authentication are required to delete user data when the user requests it, and these systems are audited to ensure this happens

However, that's not the case. We should be fighting to change that. Having something like an email address or identification number become public knowledge shouldn't matter one bit...

I agree with most of what you said, but it's even more important to keep access to your email secure than it is to keep the address private, so why should I trust your relatively unknown service to be the gatekeeper to all my accounts?

I like the idea, but I'd like it better if my existing email provider that I already trust gave me unlimited aliases (long random ones are fine, and I'd even be willing to pay, say $0.10 each). "+" suffixes are a start but they still leak the original email address.

"+" suffixes are generally a waste of time. Most actors will strip everything between + and @ to avoid exposure like this.

Too many sites disallow the + thing. It's not a great solution.

Sendmail and postfix both allow you to configure that. I have my mail set up so '+', '.', and '_' all work the same. I've never seen any site deny the '.' or '_' character.

If you run your own mail server, you can simply catch-all. The + trick is for the rest.

There are other privacy respecting email providers who give aliases. Posteo and Mailbox.org provide three aliases to begin with. Additional aliases on Posteo are EUR 0.1 per month. Runbox provides 100 aliases per account, and more can be purchased later. Fastmail provides about 600 aliases per account.

Practically, Runbox gives you much more aliases. You can use their own set of domains for each alias which is not small. Can't tell exact number now but around 30 or so. Really handy. There is another problem though. After you've done with many aliases and domains it's getting more and more difficult to maintain. You have to at least vaguely remember which one you have used already. I wish they could introduce a better way of managing aliases.

Is there any technical reason for charging per alias? It’s just an extra $0.00000001 database entry per, no?

It might be to slow alias namespace depletion, and put a cost on potential squatting.

Makes sense on their domain, but if I’m pointing my $1.95/year .info domain at them, I don’t understand the limits.

Fastmail has unlimited aliases, they aren't trivial to set up, but easy enough that I've set up ~10.

That’s not true. Fastmail provides about 600 aliases per account, not unlimited. [1] That’s quite high, but it’s also easy to run out of if one hands out aliases on a per-site basis.

[1]: https://www.fastmail.com/help/account/limits.html

It also supports a catch-all alias though.

Ah! Thanks for the correction.

Keeping emails private defeats their purpose as communication address and can lead to a false sense of security instead of properly controlling passwords and multi-factor authentication.

Having a "username" that you login with which is different than the email address would solve the same issue.

Yes because that's the same as requiring two passwords. It's even more secure to get three or five. But using the email address serves a different purpose, people rarely forget them.

Not really, in the event of a leak, two hashed passwords leaks less information than a hashed password and an email address.

Why have 2 not 1. Well one of them has to be globally unique on the site, the other has to be hard to guess. Two different requirements.

You can say that for sufficiently high values of hard, "hard to guess" implies "globally unique".

It is also a built in way to do password reset, and they are automatically globally unique, by definition.

While that is of course true enough, I go to a fair amount of trouble to remove my name, age, address, etc, from public databroker sites because I value my privacy. I don't want my email going around either. Any information leakage can be used to harm me.

Doesn't that just identify you to the databroker as someone with enough money to care? Now you're just on a much shorter list of high-value targets.

Emails are designed for communication, but we also use them for authentication and targeted marketing. For those use cases it should be private.

They're a public endpoint and are open to receiving from any other address. It's no different than your physical address. You don't use them for authentication or marketing, they're just an identifier. Keeping them private accomplishes nothing.

Here's a much more in-depth article from Troy Hunt, the same security guy running HIBP quoted in this story: https://www.troyhunt.com/im-sorry-but-your-email-address-is-...

One major issue with email address reuse is social engineering. It's a lot harder to attack someone's account if you can't even provide the email address.

Right now if you know someone's personal email, you can be pretty sure they use it everywhere. It's not a good practice, but it's hard to understand why until you've been the target of wtf-level social engineering attacks where someone got into one of your many accounts starting with nothing but an email address they don't even control.

Of course, there are some issues with the OP's email forwarding service:

1. You have to be someone concerned enough about security to want to generate email addresses, yet you have to be cool piping them through a third party. Ouch.

2. Niche product. I didn't realize how bad social engineering could be until I started hosting bitcoin services. I've had people break in to my AWS accounts twice (with bogus information) after Amazon told me they made a note on my account and that it should now be impossible. As we speak, I cannot get into nor cancel an AWS account that someone SE'd that's charging my CC every month even though it has my CC on file. I have to issue a charge-back. It's hilarious. Amazon thinks an email is more authenticating than a CC that's been on file for years before the attacker changed the email. They literally don't even have a customer support process for this situation. 99% of people even on HN have no clue how pwned they'd be if they're ever a target.

3. It's more of a feature on an existing product than a standalone service. I'd expect players like 1Password to implement it themselves.

It’s not too hard to set up your own VPS with Debian/OpenBSD and do the email forwarding/server yourself. The key is that it’s then literally a matter of a bash script to generate and accept one-time email addresses.

You have to jump through a few hoops for gmail to accept your emails. The documentation is there.

If you’re already running a VPS for other reasons, then this is free. If you’re not, then VPSs are extremely cheap anyway.

But you do keep your address private or at private as possible. You give it out only as needed.

If all twitter accounts had a physical address scams would increase, crimes, etc.

This convoluted idea is only getting purchase here because the idea of effective penalties for mishandling/misuse appears outlandish.

Emails are not used for authentication. Access to an email account can be used for authentication the “reset password” approach.

Emails are an ID on most sites, that’s it. Just because you provide the email as an ID for the account you want to authenticate against doesn’t mean it’s a factor of the authentication.

Your service looks very interesting, but I have one concern and some suggestions.

The auto-generated email addresses seen in the screenshot look very long. There are sites that restrict email addresses to 30 characters, 40 characters, 50 characters, etc. A quick count on one of those on your site showed the length to be more than 50 characters. So this may not work unless you provide a way to specify the length of each generated email address.

Now for the suggestions: the pricing on the Plus tier seems quite high. In fact, one could pay less than $4 a month (the Plus pricing) and get a Runbox mail account with 100 aliases and a Fastmail account with 600 aliases. So the only value in using your service at that tier seems to be the auto-generation part. The pricing for the unlimited tier is also much higher than the average prices of any paid privacy respecting email service. With the services mentioned above, one wouldn’t get tied into an @users.idbloc.com address either if one were to use their own domain.

I disagree.

>Triggering important security processes (eg reset password, social engineering attacks) are trivial once you know someone’s email address.

Sure, but that alone isn't an issue unless you have weak passwords for your email accounts.

>If you want to keep your email address private (you should), generate a new, random email address whenever you give yours out (the same way you use a password manager)

If you're already using a password manager how's that going to provide any additional security? No one is going to crack your 128 bit entropy passwords even if they have your email.

It helps avoid most phishing emails. I have a DB with a list of randomly generated aliases and services I've provided them to. My e-mail client is set up so that these individualized per-service aliases are highlighted (and renamed to the name of the service I provided the secret alias to) in the message list, so I instantly know when I receive e-mail from a service, and when someone is trying to spoof it by sending e-mails in the name of the service to my public address.

I can also whitelist some of these private addresses, so that my spam filter can't hide e-mails from services I depend on, no matter who sends them (it can be automated no-reply address, or some support person's address, etc.), so it's not really whitelistable based on the sender. I can't whitelist my public addresses.

It has plenty of benefits with regards to security.

It's basically a secret passphrase you give to a company that it can use to reliably contact you, and that you can use to verify that you're talking with someone you've given this secret to. It's not perfect, but much better than public addresses.

Your system looks useful and at the same time seems to involve some manual work. Please consider writing one or more blog posts about your setup. It could be very helpful to others.

I doubt it would be very useful. It's very niche.

- I have a simple custom web UI for managing mailboxes and aliases in the PostgreSQL database.

- I have postfix/dovecot setup with virtual mailboxes. I avoid DB/postfix interaction by simply dumping DB into a static postfix config files (this is much lighter on resources, than having postfix connect to the database, and much less complicated). I don't use catchall address.

- I use POP3 to get mails from my VPS, to avoid storing archive there, and to avoid having to deal with IMAP in my mail client and filtering scripts

- I use neomutt as a mail client. It has some nice options, like reverse_alias (which I use to display names of my private aliases)

- Neomutt can read configuration from a stdout of some command. I use this to generate aliases and other config options, that make it so that when I reply to something delivered to a private alias, the reply will be sent from that alias too. Using this I can have a single Inbox.

- I filter e-mail using a PHP script (it parses the e-mail, checks the alias database, and decides whether to pass the message to bogofilter, Junk, or Inbox)

Aside from adding aliases to the database, there's no other manual work.

You can probably avoid the database by having some scheme, where address is servicename.[substr(sha256(servicename+secret), 10)]@domain.com and filter/whitelist/highlight on the hash validity.

Totally agree that generally speaking no one is breaking high complexity passwords. Why break the password when you can just convince someone to change it for you?

Easiest way is just to put up a fake service and they’ll give you their real password (same one they use everywhere). I can do this in a day and get thousands of real passwords and emails if I wanted to.

Are you sure all your passwords are secure? Are you sure your accounts can’t be broken into with social engineering? Is your password manager infallible? It’s defence in depth.

Of course you may also do this for privacy reasons as well, when your reddit account is leaked do you want that linked to your LinkedIn account?

>Are you sure all your passwords are secure?

all the ones in my password manager are

>Are you sure your accounts can’t be broken into with social engineering?

And who's to say that you can't also use social engineering to recover the real email? eg. "I forgot which email I used, but it's on my domain, example.com". This is even more plausible if you use any of the "tricks" that the GP mentioned, like putting random characters, since it further lends credence to your "forgot my email" story.

>Is your password manager infallible?

Considering you have to store all those different emails somewhere, I don't see how this mitigates the treat.

>It’s defence in depth.

Sure, it's defense in depth, but the gains in security is so marginal.

>Of course you may also do this for privacy reasons as well

Sure, I'd buy that aspect, but catchall domains or dot/plus tricks aren't going to cut it because they're relatively easy to deanonimize. Not to mention all the data you leak on those platforms just by using them (location references, friend lists, interests, etc.)

So are you saying that all recommendations regarding non disclosure of usernames are useless?

Because an email address is essentially an username.

> If you have your own domain you can use a catch all/wildcard address, eg. @mydomain.com

I've done this before. You will get a shitload of spam. I recommend suffixing the user of all addresses with something you want to go to your inbox.

E.g. I use *[email protected] (r for "real"). Anything that doesn't end in [email protected] never hits my main inbox.

Been using a wildcard for one of my email domains for years (facebook@..., linkedin@... etc) and never once have I had issues with spam. Everything for services I dont care about goes through SpamAssassin on the mail server and items that pass get dumped to Gmail, where only "ham" messages will get forwarded through to my real inbox.

I think they were using their catch-all for non-transactional/newsletter emails. I have a catch-all for websites and then another that I give to people to email me on. This lets me see emails sent to me by a person easily while having separate email addresses for each site.

Do you have catchall directly on the second level domain (@mydomain.com) or do you only catchall a specific subdomain (@mail.mydomain.com)? I'd expect a very big difference in the volume of blue sky spam between those two. If GP sbov has the catchall directly on mydomain.com, then restricting the value space to *.r will make a meaningful difference.

Having the "validating substring" in front of the @ will actually make it easier when you have to use the email address in vocal communication: many humans are unaccustomed to encountering more than one dot after the at.

Yep, directly on the second level domain. I do not use a mail subdomain.

> I recommend suffixing the user of all addresses with something you want to go to your inbox.

I use a subdomain. *@abc.example.com goes to my CatchAll folder. [email protected] go to their respective users. There are no equivalent names between @abc.example.com and @example.com so if anyone gets cute[0] and tries stripping out subdomains, the messages are rejected. Also, subdomains are common enough that no one thinks anything of it.

As a nice bonus, the subdomain can also be directed elsewhere. I've aimed it at various "we automatically file your e-mail" type scripts and services before, just to try them out.

0 - Spammers absolutely try to get cute and drop the subdomain. For example, in the Dropbox leak, [email protected] and [email protected] of mine were leaked. I see tons of spam attempts to [email protected] and [email protected] daily.

Thats a good solution. For 15 years or so I just used the [email protected] approach. But in the last 4 or 5 years, the spammers have gotten smarter and now are stripping off the site and just emailing [email protected].

Yours is a good solution.

Since we’re sharing anecdotes: I do this presently and get very little spam to random addresses. I’ve been on this scheme for about a decade now. All spam is to a specific address, which I’d given out.

I use a wildcard on my domain. Spam filtering is _really_ good these days. It truly is not a problem. I get tons of spam, and it's all filtered.

You don't use wildcard addresses for this, you use sub/plus-addresses. That way the spam problem is completely avoided and multiple users per domain will work normally.

I'd use something else not plus because gmail uses plus so spammers may be aware they can change the plus to anything

>[email protected]

Isn't it elementary for a bad agent to scrub those? Your actual e-mail address ([email protected]) is too visible.

Sure, but from a security/authentication standpoint that won't be an issue.

Even if you have my [email protected] address it still won't help you with login in on other sites as the address used on another site is still unknown.

Yes, it is- however it could stop an automated attack where the bad agent isn’t targeting you specifically or is not a particularly knowledgeable agent. It also might help you find out where a leak or spam is coming from (eg if you get a reset password email from [email protected], you know your Facebook email address is known to an attacker). So it’s better than nothing.

Obviously this only works if all emails to [email protected] and [email protected] are rejected without notifying the recipient. This was how Yahoo's scheme worked (I never actually used it, not sure if it's still active). If gmail's doesn't, then I agree it's worthless.

gmail also ignores dots

so you can do `[email protected]`

then if you get any email to `[email protected]` you can filter it

Of course, they can start stripping dots in gmail addresses too, but then they'd have to be targeting gmail specifically or they'd break for most services where dots do matter.

Pretty easy reason why you shouldn't; under GDPR you don't have consent to use this email (though this reasoning is a bit shakier) and scrubbing the suffix runs afoul of spam laws in my country (if you're given an email for contact, you use THAT email, not anything else).

> [email protected]

Sadly, "+" doesn't work. Too many web email validators fail when given a "+" character. Gmail has made some of that a little better, but I still bump into it too much.

I generally use "_" or "." for wildcard start as any email validator that hangs on those will get smashed immediately.

It unreasonable to assume anyone could ensure his email is kept private the moment she shares it with at least one other entity.

Rather than trying to fight windmills, it's better to use unique emails for sensitive/high-risk purposes. That way they cannot be used as primary key.

Company policy here is to never register any company account under a generic <[email protected]> email but use a partly randomized email for each provider <[email protected]>. That way no one can use one leaked email to even identify other services we use (think reset password/login dialogs leaking information about an email being registered or not).

> I’ve recently launched https://idbloc.co which aims to help deal with this

Nice! I just started working on the same thing, and it would be great to be able to drop the project… except trusting a new service with your e-mail is hard. (It’s even hard to trust established names like Google or ProtonMail.) If only every service supported encrypting e-mail so providers couldn’t read it. :(

I've been working on similar project since last year as well. (I slacked a little bit -- grad school and stuff). Too bad the SMTP protocol is limited. I was thinking of ways such a service can be designed in a provably secure way (where we don't get to actually read the messages, just apply rules based on headers only). Any thoughts?

(Actually, replace “trusting a new service” with “trusting 3+ new services” – it’s probably hosted on AWS or something, and https://idbloc.co/privacy mentions that mail is forwarded with MailGun.)

The irony lay in that email addresses were originally designed as communication channels (like snail mail), but have since been co-opted into serving as a unique identifier (like SSN).

So, you need to share your email address to be able to communicate properly, but you also need to hoard it because it is part of how you identify yourself. Aliases are one workaround but are not universally accepted as identifiers.

Many of us do not use our email address for any part of our identity. I believe it’s a poor choice to do this or allow/enable others to, as well.

Tell that to the companies who use it as a login.

A catch all address is just asking for a sunami of spam.

But maybe something*@example.com

I have two Gmail addresses. A public and a private. For anything that is public facing, that exposes the email or that I don't trust as much, I use the public email. For everything important, I use the private one (and sometimes with the + method).

My private address is set to forward to my public. I only respond and send email from the public email.

BTW this is how you market a product. Intimately knowing the space. Providing insightful context on the importance of the problem in a public forum. Offering the free solutions, which are usually manual and cumbersome. Then, finally, offering your service as an easier alternative. Well done.

I think we need to completely reimagine email, though a proper fix is likely pretty easy. I think social networks have done a pretty good job at the basic idea:

- ask to connect, perhaps with a short message as to why (maybe limit to 100 text characters) - once approved, communication is encrypted (PGP keys are exchanged behind the scenes)

I think that would drastically limit the amount of spam, phishing, and intercepted messages, which is good for everyone. Unfortunately, I think it's also quite unlikely to hit the mainstream.

I wonder if an email masking service would make sense. You register with it, and give it your real address. You then can generate a new public email anytime you like. Control how it behaves, etc. [/me hits up google]

So, I just looked to see, and there is already a service doing this: https://www.abine.com/. The email forwarding is the easy part. They also do "burner" credit card numbers. I don't know that domain to know how you do that, but that seems good. They also do phone numbers. Neat idea.

There's also http://gishpuppy.com which I've been using for about 14 years now.

Until Gishpuppy itself gets hacked...

There's also Burner Mail https://burnermail.io

I have also seen https://lttrfeed.com/ with a focus on newsletters.

>is the 2nd factor required

Email is not a factor in authentication, it’s a user identifier. There is a huge difference between the two. Requiring users to also provide their first name is also not a factor.

Email is just a worse version of the same factor in a login. They are both just “something you know” only email is even worse because it’s something everyone who knows you knows.

Just to drive the point home, if a website asks you to set three passwords that it asks you for on each login, that’s not 3-factor or even 2-factor authentication. They are all just part of the “something you know” factor.

I highly suggest using a catch-all on a subdomain, not a top level domain. Top level domains get dictionary-style spam/phishing storms (eg alice@, bob@, charlie@, etc), but those don't seem to occur with subdomains. You can also create just an MX record for a subdomain, which helps 'hide' it to some extent.

The first time I setup a top level catch all, I had the first dictionary style attack within a day or so. I've been using a catch-all mail-only subdomain for well over a decade, and have had no such attack.

> I strongly believe that we should be keeping our email addresses as secure as our passwords.

That doesn't make any sense. Just create multiple email addresses, one for talking with people and a separate one for signing up for services.

The one problem is there are companies like Facebook where even if you sign up with a secret email address, they will send password reset tokens to the other public-facing email addresses you have on your profile.

idbloc looks good. Maybe consider a one-time price option too. Or for people on the free plan, consider allowing them to buy a one-time top-up pack of email "credits" if they use up their free 100.

Personally I have a bunch of spare email addresses from google, yahoo, and others that I created many years ago before they demanded a phone number when signing up. I just use those for website logins.

there is also theothermail.com to generate throwaway email addresses that forwards emails to your original inbox, you don't need to use your personal email address to sign up for a newsletter

we created the service theothermail.com to generate throwaway email addresses that forwards emails to your original inbox, you don't need to use your personal email address to sign up for a newsletter

Thanks for the tip about gmail's "+" support. I'll start using it. I don't think it does anything to keep your email address private, though. Recovering the original valid email address from "[email protected]" is trivial.

this is like saying that you should keep your public street address private... you are thinking about it backward. What needs to be done is don't use your email address as a login or worst, as a password recovery option.

Google (and others) should support hashing/obfuscation the unique part, for example

[email protected] -> (some unique symbol to denote hash, say +)(hash)@gmail.com

It wouldn't be complicated for them to implement, and give everyone a few such aliases.

While not of any value for 95% of users, for techies a great workaround is to have your own domain and use a distinct email for each service that all go to one catchall account.

Eg: [email protected]

Public-Private cryptography is the answer.

Forget about email addresses, the network should scale globally from the user's public key that can be stored on any number of nodes as the user id with the data.

Someone pointed out the other day just remove everything after the plus and you have the real email.

"+" is unfortunately rejected by far too many validators.

Cool. So I just have to wait till your backend gets compromised and starts sniffing my emails mid-forward? Or is it already set up to do that?

Email is inherently weak and should not be used for anything sensitive. It’s weak by design.

"Should not be" and "is not, ever" are, unfortunately, two wildly different world states.

The fact is that email is often the keys to the kingdom, if compromised, or the baited hook to be used in phishing. With consequences which have had globally-significant consequences, to date.