GMail Trick Detector

[hickscorp]

Consider these two emails:

• [email protected]
• [email protected]

It might not be very widespread knowledge, but these two emails are the same - they both get delivered to [email protected]. 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 [email protected] 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 protected] === [email protected]).

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 [email protected] in my previous example, or to [email protected] 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 [email protected] the same as [email protected] like GMail does?
• An email provider considers [email protected] the same as [email protected] 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.