~poldi1405/normalize-email

Make it harder to reuse email addresses
70655701 — Moritz Poldrack 19 days ago
added GitHub mirroring
ccaf317e — Moritz Poldrack 19 days ago
added README
7df94acf — Moritz Poldrack 19 days ago
added rules for cock.li

refs

master
browse  log 

clone

read-only
https://git.sr.ht/~poldi1405/normalize-email
read/write
git@git.sr.ht:~poldi1405/normalize-email

You can also use your local clone with git send-email.

#normalize-email

Go Documentation REUSE status License: MPL-2 builds.sr.ht status

This package is intended to help reduce multiple sign-ups using the same mail-address by applying general and provider specific rules to email addresses, thereby transforming them into a standardised form.

With this John.Doe+marketing@GoogleMail.com becomes johndoe@gmail.com. As these addresses are both for the same mail account, there is risk in this method. The following transformations can be applied based on the address' domain:

  • Remove characters (for example the . in Gmail-Addresses)
  • Remove subaddresses (usually the part after the +)
  • Rewrite domains (googlemail.comgmail.com)
  • make localpart and domain lowercase (JohnDoe@…johndoe@…)

#Missing rules

If you know about more rules, please open an issue or send it via email

#Important notes

Do not send mails to the normalised addresses! Always use the user-provided address as things like subaddresses and receiver-side sieves can affect deliverability. Just because joe+site@gmail.com and joe@gmail.com belong to the same account, does not mean that they are equal.

This library can not detect server side settings. If the subaddress delimiter is set to -, this library will still assume it's +. There is simply no way to do that. This may – though highly unlikely – lead to non-functional addresses being produced. The low likelyhood of this happening to two users on the same domain with the same odd address (joe+doe@… and joe+deere@…) makes this something considered acceptably rare. Again: do not send mails to normalised addresses!

#Stable version

This library is considered stable and considered feature-complete. The only planned updates are updating or adding rules. To avoid creating a new tag at every commit, no tags will be added to this repository and origin/HEAD should be considered stable.