File is getting too huge about burner-email-providers

[wesbos]

looks like there is a PR to do this : #249

[lindell]

#249 Does only look for invalid top-level domains.
The real list of invalid domains is much bigger if we count all domains where it's impossible sending emails to.

I made a script a month ago, that was going through all domains and checking the MX-record for all domains.
This resulted in around an 80% reduction. From 110434 to 18126 domains.

The only problem is that this is not completely static, and when running the script again, the day after, around 5 new domains did now have a valid MX-record.

Would we be fine with some false positive removals? In that case, I could continue to run the script, and any domain that had a valid MX-record any run, would be added to the resulting list.

[wesbos]

Ahh interesting..

Are the MX records valid because the domains are re-activated?

[lindell]

That is my guess. Or that the domain itself was active all the time. But no MX-record was set.

[wesbos]

What if we keep a list of those inactivated domains and then periodically check and add them back in? Could be done via a github action.

If the domain is no longer registered, just remove it entirely.

If the domain is registered but has no MX records, put it in storage.

If the domain has MX records, keep it in the list.

[lindell]

Don't know if we gain anything from separating no MX record domains and inactivated domains. But I really like the idea of having an evergreen list of domains that is currently active that may re-add things that seemed to be inactive 🙂

The "storage" could even just be the git-history, the script could just look for "cleaning"-commits and check for domains removed there 🤔

[lindell]

@wesbos What language would you prefer this be written in? JS?

[wesbos]

Ideally yes, JS or TS

[wesbos]

fixed #388