From your blogs I think you are using a Key, Value data structure, which means when a query comes, your data store needs an exact *key* to find the value (if it has been breached or not). That's probably the best data structure for HIBP since it can scale infinitely, however it will not allow you to query troy+*@hunt.com.. I guess the only way to address that is to either canonicalize the data as you add it, by removing everything after "+" (or ".", or "-"), which means this will only work with new data sets, or change the table schema / contents of "Value", which is very unlikely to happen.. Another solution would be to create a new "table" with all e-mails with "+", ".", or "-", and then query both when someone requests information, only that this time you format the "Value" of those "Keys" accordingly.. Although it may seem like a lot of work, the earlier it is done, the better it will be as it will include more datasets..

Unfortunatley there are some online-services that don't accept emailadresses with + sign. I had problems with 2 services in the last month.

To Kem's question, we're *always* talking tiny percentages. I just checked the last set of data I loaded which was a spam list and only 0.009% of emails used the + syntax.

This is something I still want to add folks, but it'll be to the benefit of a tiny percentage of the community.

Tony,

I'm in the 0.03% and have been for years. It's been a fantastic way to identify abusers of my email address. I'd love to see this feature implemented and would be glad to help any way I can.

The 0.03% stats appear to be from November 2014. Do you have more recent stats? (Today is November 29, 2016.) I'm curious if more people have caught on to this technique these days...

Thanks,
Kem

Since there's a comment in here about "go read the RFC", here's the RFC that describes subaddressing: https://tools.ietf.org/html/rfc5233

I would be perfectly happy if this were only implemented for new breaches and if it didn't tell me the exact tagged e-mail address.

Under these conditions you would only need to canonicalize email addresses as they come in and the rest of the code would work as-is. Convert to lowercase, strip generic subfields, add a special case for gmail dots and yahoo hyphens, store it and that would be it.

Would it not be possible to just add a, "This email address has tags," checkbox to the search, with a small tooltip telling confused people what it is? That way the extra code to search for tagged addresses never gets executed for the 99% of people it's not relevant for.

You should not be deliberately programming data leaks into HIBP!

Just because Google started to support this "+tag" idea does not undo the fact that + has been a valid char left of the @ in internet email addresses since there have been internet email addresses. Go read the RFCs.

Now, if you want to do it on a domain-by-domain basis after verifying that a domain that supports "+tag" otherwise does not allow + on the left of @ in any other email address, all power to you, but please do not do it for all domains "because Google supports it". The internet has already had far too much non-standards conformant cr*p to deal with because of attitudes like that in past (when variously Sun, IBM and MS have been the problem actors).

I've recently started switching registrations to use the "+" syntax and would love it if this feature was supported. As it stands I am adding subscriptions for every "+" variation I have used (or remember using)

I use this feature quite often, but have been hesitant to use it recently due to haveibeenpwned's not supporting it. This would be an awesome function.

Adding both the full address with the "+" and a normalised ones without it would be an option, but it's difficult to do retrospectively and would mean enumerating back through hundreds of millions of records (I can't just query for everything containing a plus due to the data structure).

I'll continue to monitor this and if it either becomes easier to implement or more popular with users (it's still *extremely* rare) then I'll reassess.

How about using the canonical e-mail as an index field, and adding a second e-mail field, containing the actual email from the breach ?

This way, if guillaume+hello@whatever.com is found in a breach, create a record in the database for "guillaume@whatever.com".

This is a neat idea, and I'd really like to see it implemented in HIBP.

Having said that, I also question how far should HIBP go and adjust for the quirks of individual email providers. Generic sub-addressing is a standard (rfc5233) and implemented by nearly every provider, but going all the way would be much more involved than that.

A few examples of such quirks:

1) AFAIK, dot addressing is something specific to gmail. Other email providers (like Hotmail) treat JaneDoe@outlook.com and Jane.Doe@outlook.com differently.

2) For plus addressing, Yahoo allows users to create a separate prefix for disposable addresses e.g. JaneDoe@yahoo.com will have addresses of type "CustomPrefix-foo@yahoo.com" and "CustomPrefix-bar@yahoo.com" (Also note the - instead of +)

3) For domain equivalence, gmail.com and googlemail.com are equivalent, but contrary to what one of the comment below claims, JaneDoe@outlook.com and JaneDoe@hotmail.com are different accounts.

Generic plus addressing is a good idea, but I feel implementing support for every possible email address equivalence might not be as useful for the effort involved, especially when the other problems are much more easily solvable by registering just one more account in HIBP.

The problem with a domain alias is that it's even less predictable than the "+" pattern. There's no assurance whatsoever that all domains will continue to work consistently in an interchangeable fashion nor is there necessarily a canonical list of them for each email provider.

I'd also be surprised if if many people actually used them in that way. Per the stats here, use of the "+" syntax is extremely rare and I can only imagine that domain substitution is even less so.

Another consideration is domain aliasing. For example, these are equivalent:
JohnDoe@gmail.com
John.Doe@googlemail.com

As can be:
JaneDoe@outlook.com
JaneDoe@hotmail.com
JaneDoe@msn.com
JaneDoe@live.com

I just posted a similar suggestion. Google also uses periods in the email address for filtering. so email@gmail.com and e.mail@gmail.com will go to the same user, but like + syntax, it allows you to filter those messages.

That's along the lines of what I've been considering Nate, the main challenge is that when someone searches for an address without a plus in it, I need to be able to pull back the address WITH the plus in it. This means that I need to store a reference in the table without the plus which the current data scheme doesn't support.

Right now, there's a key and then a comma delimited list of impacted breaches. I'd need to add the account with the plus along the breach and not only that, but there could by MANY instances of accounts with a plus on the same breach for the same user. For example, let's say that again foo@bar.com on Adobe I need to support foo+1@bar.com and foo+2@bar.com. Now we're talking about a collection of related addresses against the occurrence of the master address next to the breach.

I don't mind adding an extra table query for the rare instance where the plus symbol is used and I also don't mind iterating back through every existing row for a bulk update of some kind, the main thing is that for the 99%+ of searches where there's no plus, I don't want to add an overhead for those guys.

slight correction: in 2b, "it" refers to the main table.

I think a possible solution would be the following:

1. add an extra table for addresses with a + in them, with a relationship to the main table;
2. when an address with a +is added, do 2 things:
a. add the address WITHOUT the + to the main table;
b. add the address WITH the plus to the second table with a link to it.
3. When a user queries an address that has a stored plus value, you can retrieve all values from the other table and show them somewhere to the user (for example, below the breach it's from).

This means you store all mails in the same method, namely always without the plus, but you can easily (single query) retrieve the value with the plus. It also seems to me like it's something that can quite easily be implemented (I think I could implement it myself, and I'm only a junior developer). The biggest downsides:

1. it takes slightly longer to import the breaches because you have to transform the pluses;
2. if the address has a + in there, you need an extra query to retrieve them, slightly affecting performance and possibly costing extra;
3. you need to develop a one-time transformation which can deal with the existing records (probably the most complicated part).

Totally right @anonymous, it's resolving the relationship between x+y@ and x@ that's the tricky bit. It'd be easy just to allow the breach to be found when searching for x@ (I'd just add it as a standalone record), but there's no construct at present to turn that around and advise the user that x@ was breached by virtue of x+y@ being breached.