I'd love to have this implemented to filter out '.' and '+foo' for email domains that allow this, specifically @gmail.com

Wouldn't it be quite easy to follow a recipe like this:
In a breach Troy could do the following for email addresses which are known to implement such a decoration scheme:
- add another record where all decorations have been removed but don't count it to the number of breached email addresses
* found in a breach: john.doe.the.greatest+somesite@gmail.com
-> add also johndoethegreatest@gmail.com as kind of hidden record for breach, too

When john.doe.the.greatest@gmail.com subscribes to be notified, he should get the notification that john.doe.the.greatest+somesite@gmail.com appeared in a breach!

I understand there is some complexity involved here and email decoration might not be used by many, but those who do it on purpose, do it with something in mind.

there's also a million ways to do this - e.g. not using a syntax at all or just pre-fixing or addending the service name. not sure how you could accommodate all of them.

I just voted in favor, but I understand Troy's perspective.

better enable .dot syntax for google mail accounts!

I understand the problems with complexity of the + (stripping useful information, etc) but what about periods? If my email is

plusproblem

I can put periods anywhere in that email address and they will all resolve to me.

plus.problem
pl.us.pr.ob.lem
plusprobl.em

You're not adding a suffix, just inserting periods. How complex would it be to detect variations like that? Perhaps a way for a user to opt-in, noting "please check for period variations on my email address"? That way you're not scanning an astronomical number of permutations against a list. For example, knowing I've opted in and my email starts with "pr" look for all breached emails starting with the letters "pr" and strip the periods from them in a temporary list, and compare with mine?

The reason I ask is because I've used a lot of period variations and can't always remember the way I've used them. I only got notification of a recent breach from a vendor themselves, not HIBP. I could add as many as I could remember to the HIBP mailing list, but don't want to stuff your database with that if this will be added at some point.

Maybe as an alternative you could allow a 'batch' search feature, where I could load all my <name>+<website>@gmail.com addresses and a report with a matched results summary for each?

The onus would be on me to maintain my list of addresses (not hard, a CSV export from 1Password would do it).

No change to status as of now, complexity remains the same as does prevalence of use.

Hello Troy,

This feature is by far the most wanted feature for hibp on uservoice.
Not many people use email filtering that way, but almost every people using it are tech-y people who use your website and services.

It may not be significant overall but I believe it's a more significant trend within your own users.

What are your thoughts on this feature as of now?

I am using mail extensions (the "+" syntax") extensively to protect myself against spammers and data leaks, and therefore would like to see this feature supported. As such, I would have to submit approx. 150 different email addresses to "Notify me" in order to keep me updated.

Perhaps a different, more simple approach could work? If someone queries a regular email address (e.g. first.last@domain.com), just perform the query as usual, by searching for an exact match. If someone queries an address in the format "first.last+@domain.com", could you do a regex search against the database(s)?

With this approach, it might be easier for both the affected users and the site operators to achieve something acceptable for both sides. Thanks for consideration.

I do use email alias services from email service providers (ESPs) like GMail, Outlook & Yahoo. All three have different implementation of alias email address w.r.t. usage of syntax and domain names. Such inconsistencies among ESPs have already been commented here.

I was wondering why these popular ESPs, aren't using the domain search (https://haveibeenpwned.com/DomainSearch) or API (https://haveibeenpwned.com/API/v2) to inform its end-users of the possible breaches of pwned websites. This is similar to how domain administrators are expected to use HIBP.
For example: Yahoo informing me that my private details stored at Adobe were unintentionally exposed and stating that it got this information as-is from HIBP.

Advantages of ESP directly using the services of HIBP instead of the end-user:
1. ESP is better equipped to inform the end-user with an enumerated list of breaches associated with each of their alias email addresses (Yahoo allows up to 500 disposable email address to be created by a user) and also the primary email address. Hence, the implementation of handling of exposed alias addresses is handled by respective ESP and not HIBP. User also need not register all alias email address with HIBP.
• FirstNameLastName@yahoo.com was pwned in LinkedIn, Twitter, Yahoo.
• BaseName-Adobe@yahoo.com was pwned in Adobe.
• BaseName-FreshMenu@yahoo.com was pwned in FreshMenu.
2. I read https://www.troyhunt.com/the-legitimisation-of-have-i-been-pwned/ Unlike Amazon or Opentable, most of the internet-related service providers (IRSP) are neither proactive in handling nor do they provide timely alerts to the user of possible breaches. Example: FreshMenu decided NOT to notify its impacted customers. https://www.thenewsminute.com/article/data-breach-freshmenu-leaked-data-110k-users-2016-co-didn-t-inform-users-88195 This might be due to multiple reasons like economic reasons to reduce cost, avoid time spent in pacifying impacted customers, reduce the chances of start-up losing to competition in a new & growing market, weaker Data Protection law and enforcement in India. So it would be better if the appropriate ESP using the services of HIBP alerts the user irrespective of the breached IRSP doing it or not.
3. The total number of ESPs (free, govt., educational & corporate) is smaller than that of all other varied kind of IRSP. Hence the efforts of HIBP, ESPs and IRSP are better channelized in mitigating the effects of a breach and each of them doing what they do the best.

# Failure and success of the suffix idea

## Failure of my.email+anysuffix@anydomain.tld option

I agree with Troy here, I see no clean easy handling of + suffix.

For example, whitelisting "providers known to use +syntax" obviously fails with independent sites.

Actually, the suffix trick is really (and should be) an implementation detail, not something that can be detected and handled.

For anyone not convinced you have to know that the character triggering suffix behavior is not standardized. In postfix for example you can set whatever character you want.

And indeed I chose an alternate character because of so many braindead sites that forbid the + character when registering.

## Success of the *@mydomain.org or *@mysubdomain.majorprovider.com option

If the e-mail provider really allows you a full subdomain, you can receive mail at e.g. postmaster@mysubdomain.majorprovider.com or one of the other options, then just use HIBP Domain Search!

Now, where is the form to register for domain notification?

The feature is mentioned on https://haveibeenpwned.uservoice.com/forums/275398-general/suggestions/15109419-include-email-addresses-or-some-info-for-domain yet not seen on main site.

Thank you for any hint.

While I am an avid user of the '+' aliases along with a wildcard address (my own domain on Gmail) and would support a functionality like this, I've read the comments and have to agree with Troy's stance on this one, there are a number of good reasons why its not worth the investment.

Perhaps a simple solution is to do this on the user end - A simple program to read all the 'to' addresses with a '+' (or just every to field which reached the mailbox, which would support wildcard users) in them via Gmail API and then using HIBP API to check each of those addresses?

"Edit: Just to put the value of this into context, I've just run some stats on the Adobe breach. Of the the 152,989,508 rows in the dump, only 49,905 email addresses have a "+" in the address so that's 0.03% of entries. That number is also a bit high as it includes junk entries. I'm definitely not ruling this idea out - it's still planned - I just wanted to give a sense of how useful it would be."

I guess running those stats took way more work as a simple implementation (removing the +... part before running the db search seach for '+%'). Also did you check if the adobe breach was a good choice to run this stat ? If I'm not wrong the + feature started to happen in 2002 and most of adobe account were created before this time (I really may be wrong, please verify).

Please add the + (and the period) for people who intentionally use it as a way of automatically filtering their email (me) or locating where spam could have originated.

Maybe, someday, haveibeenpwned.com will even be able to convert (a) to @ !?
Amazing what computers can do, right?

Add the + (plus) and . (period) already, please.
I've always done this.

If you are going to be respected by techies which use it, who tell their users to do it, then you will support this function, and more users will follow the advice of their techies.

I've been using Gmail with pluses for years. It's annoying when sites don't support this - and there are still plenty of them.
I'm now considering doing something like what Stephen Turner does - e.g. linkedin@example.com, without using pluses.
Not as good as HIBP supporting pluses, but it does allow you to use HIBP's domain search facility.

Ik have to check for every unique adres sperately. Why? My provider supplies instead of just the xxxx@dds.nl als o<enter_anything_here>@xxxx.dds.nl.

Ik give any company it's "own" adress. I use it to automatically filter my email , move to folders, and block adresses that have been leaked. Also I can prove to a company that they are the breach.

But as it is even more specific than + adressing, I have little hope for a functionality like <wildcard>@xxxx.dds.nl.

I can imagine the possibility for abuse. Maybe this is acceptable when wildcard is only allowed when there are 3 parts after the @?

Ad an addition to this I use the format linkedin.com@example.com with my domains. Searching the data for *.com@* or other TLDs may be useful to help identify the sources of the breach.

If everything after the + is stripped, that information is no longer available to the owner of the address. For example, if I load a spam list and someone used "+netflix" then they no longer know it came from Netflix. Yes, they've has to explicitly check that address but many people also have domain-wide searches and this would screw that up.

In short, nothing yet has changed with this idea: the pattern is still at very close to 0% usage and the same barriers still exist.