You can use the + trick and . trick with Gmail addresses too. I think Outlook as well supports the + trick. The only downside to this is that there are plenty of sites that don't accept a + either knowingly or unknowingly.

Yeah, that's why Fastmail has that syntax.

The + feature long predates gmail. Here’s an example description from the 1990s http://www.faqs.org/faqs/mail/addressing/index.html

I think StavrosK meant Fastmail has the [email protected] syntax because "there are plenty of sites that don't accept a +", not because Gmail supports the [email protected] syntax.

That's what I meant, sorry and thank you.

Yes, it's in the SMTP RFC.

To clarify the SMTP RFC (RFC 5321) says that a valid e-mail address is defined in RFC 5322 - Internet Message Format.

RFC 5322 does say that a `+` is a valid character in the local part of an e-mail address.

The `+` character being used for address aliasing is, as far as I can tell, not mentioned in RFC 5321 or RFC 5322

It's apparently a thing now:

https://tools.ietf.org/html/rfc5233

It's not.

See the sibling comment: https://news.ycombinator.com/item?id=20109564

RFCs don't define any meaning to '+' as described in this thread, except that local part of the address should be interpreted locally (usually by MDA), and preserved unmodified during message transfer.

There's no + aliasing in the specs. There's no interpretation defined for local part of email address.

Oh, yes. I meant "+" is an acceptable character to use in the local part of an email address, as per the RFC. I see now where the misunderstanding lies.

I've been doing this for years with Gmail but the issue with breach notification services like HIBP / Monitor is that you can't add wildcards into your search for notifications, so unless I plug in every me+service@domain email variant in, I could be missing being notified.

this isn't a good anti-spam filter though. + addressing (even the fastmail kind) is trivial to parse and I'm 100% sure email harvesters are aware of it.

They can filter out the boxname part of [email protected], but they can't, in general, filter out [email protected] - it would break too many things. I guess it's possible to recognize mail for mytld.com is handled by FastMail, but I'm not sure anyone bothers. In my case, almost all spam I get comes to an alias I have in my Facebook profile, and the rest of it to an alias I put on my website - so in both cases, I assume spammers just scrapped the e-mail address.

Fastmail also lets you use aliases to protect your main address. I only give out an alias with an alt domain - something like [email protected], [email protected], etc. No one has my real address. I basically only use it as my username. I give an alias to family. I just delete the alias or filter it to the trash if I have problems with it.

I'd be surprised if many harvesters are going to bother with rules just for Fastmail domains. First of all, they have a bunch of them. Second, the spammers' objective is to get email into your mailbox. They don't care if they use an alias to get there. Bad actors who got your info in a data breach are a different story, but there's probably some safety in numbers. There could potentially be millions of accounts to go after before they start thinking about reversing my Fastmail alias. Besides, if you use one of the generic ones like qq.com or eml.cc - or even better yet, your own domain - they're not likely to notice anyway.

This isn’t to prevent spam, it is to identify the original leak. If the unique email address you gave to company X is used for solicitations by company Y, company X must have given it away.

Then what?

Depending on my mood and whether the company is local, write a complaint to the company that leaked the address or to an appropriate government institution. In my country, a local computer security news site started a tradition of telling the offending companies that they can either apologize and donate some money to a charity (and send back the proof of payment), or you'll bring the issue up with Personal Data Protection Office, which will be more than happy to fine them.

I usually go for <company>@example.com where <company> is the company I’m handing my address to. After a breach I route that address to /dev/null

That's trivially easy to guess -- and game.

You want something that is sufficiently random that it can't be easily guessed or gamed, but can be quickly and easily determined on your side.

Salted cryptographic hashes might be a good place to start.

Most spammers won't go through the of "gaming" it. There's no upside. There are far easier targets to focus on than sending more mail to a single recipient who is more sophisticated.

After a breach of <company>@example.com, forward it to support@<company.com>.

Don’t give me ideas.

If you live in Europe, you might have a case.

Fastmail way of doing it is better. Some advertisers are already removing + syntax from Gmail addresses.

I think most MTAs support +. Isn't that part of the e-mail standard?

The MTAs do. Many a website won't allow you to use this syntax for a user registration.

It is, but many services will (incorrectly) prevent an address with a `+` in it from ever making it to their database/whatever.

So the fact that the MTA will route it is irrelevant if it never makes it to the MTA in the first place.

> It is [part of the standard]

+ as a magic character to effect routing isn't part of the standard. Mail servers are free to route addresses to mailboxes in whatever manner they see fit. That + can appear as a character in an address is part of the standard, just not the behavior of it; a server that treats a+1@ and a+2@ as distinct emails is conforming, and from a sending side, you cannot know if a+1@ and a+2@ will end up in the same mailbox.

(But you're absolutely right that too many sites fail to parse email addresses. Or rather, they over-parse.)

You can also set up rules like *@example.com, leading to addresses like [email protected].

As does Gmail. But not all services supports the + on login forms.

I believe this was part of the email standard?

The email standard does include the +, yes. Here's a talk on the topic:

https://youtu.be/xxX81WmXjPg

But yes, that's why Fastmail supports the alternative syntax.