GMail Trick Detector

[hickscorp]

Consider these two emails:

• someone@gmail.com
• someone+else@gmail.com

It might not be very widespread knowledge, but these two emails are the same - they both get delivered to someone@gmail.com. It would be nice to have burnex not only return a boolean, but instead also return whether the target final email is different than the one provided - so that someone providing someone+else@gmail.com couldn't register several times, for example.

I'd be up for making the PR on this project, but I'd rather first know if it would be interesting for the library?

[Betree]

Hi @hickscorp, indeed! I think dots are also ignored (ie. email.test@gmail.com === emailtest@gmail.com).

I think that the feature you describe fits into this library's purpose (using an alias is a way to get a burner email), so I'm up for this change.

Maybe we should implement it as a separate function to stay backward compatible and to make sure that the people who don't care about aliases are not impacted by the changes?

[hickscorp]

@Betree Gotcha.

So I could suggest a bit of a rework of the API layer, such as the following:

• The traits_for_address function could return some sort of simple structure containing metadata about that email - for example @type t :: %Traits{is_burner: boolean, is_alias: boolean, domain: binary, aliases_to: binary}. In the event of an alias, aliases_to would end up being equal to someone@gmail.com in my previous example, or to emailtest@gmail.com in yours.
• Keep the is_burner?/1 and is_burner_domain?/1 functions exactly as they are, but they would call another function such as traits_for_address1+1 and would simply pattern match on the %{is_burner: true} attribute.

Now in terms of internal logic, I guess the question is - how do we know when:

• An email provider considers someone+xyz@domain.com the same as someone@domain.com like GMail does?
• An email provider considers some.one@domain.com the same as someone@domain.com like GMail does?

Do we change the burner list to be a bit more structured and providing flags? I think what would be nice is a way to the library user to be able to configure these - eg override the default burner list and / or establish rules for each.
Maybe we could establish some sort of a convention, so that we could have a module such as:

defmodule MyApp.BurnerDomainSpec do
  def ignores_dots?("gmail.com"), do: true
  ...
  def ignores_dots?(_), do: false

  def aliases_plus?("gmail.com"), do: true
  ...
  def aliases_plus?(_), do: false
end

So that the library user could pass this as an option?

[hickscorp]

@Betree Just so we're clear, as you said "dots are also ignored". Plus signs are not just ignored by GMail...

[Betree]

@hickscorp sorry for the late reply, I went in vacation and missed this issue when I came back!

Your suggestions above for the rework of the API layer make sense to me.

Do we change the burner list to be a bit more structured and providing flags? I think what would be nice is a way to the library user to be able to configure these - eg override the default burner list and / or establish rules for each.

For a first version I think that we could keep the existing string list and just have a module similar to what you suggest above, with aliases_plus? and ignores_dots? functions to check the properties of each domain. If there's a need for being able to configure custom domains/rules we should spec it in its own issue and implement that separately.

Just so we're clear, as you said "dots are also ignored". Plus signs are not just ignored by GMail...

Absolutely, what I meant by also is that it's another rule. I understand that + is an aliasing mechanism, not just an ignored character.