fix: RedTube, Tube8, YouPorn email module false positives

[kristoisberg]

This PR fixes false positives in the RedTube email module, and possibly in the Tube8 and YouPorn modules as well, since they use the same detection mechanism.

The modules previously always interpreted "The email address provided does not meet our registration requirements." error messages as taken emails for well-formed email addresses, but this produced false positives for email domains, which, I assume, have been blacklisted.

As there aren't any better indicators to go by, the fix is quite unorthodox: in case of a suspicious error message, we generate a random email address on the same domain. If the random email also receives the same response, the domain is most likely blacklisted; otherwise, the email is actually taken.

Previously false positive test case:
user-scanner -m redtube -e asdgtgffgffhg@zohomail.com

Sadly I'm not aware of any true positive emails.

[brunolm]

Before: the module made one request and read the message "The email address provided does not meet our registration requirements." as "an account already exists here", provided the address was well-formed. The problem is that RedTube sends that same message for two unrelated reasons, and checking the address format can't tell them apart:

• the address is genuinely already registered, or
• the entire email domain is blacklisted for signups.

So every well-formed address on a blacklisted domain was reported as Registered.

After: when that message comes back, the module sends a second check for a randomly generated address on the same domain. A random 32-character local part cannot plausibly belong to a real account, so if that one is refused too, the refusal is about the domain rather than the address.

Confirmed working on my end.

I'd suggest maybe having a list of known blocked domains to avoid multiple requests, I'm now more easily hitting the rate limits. Some domains that are probably blacklisted (but I haven't verified): zohomail.com, yopmail.com, 10minutemail.com and guerrillamail.com

[kaifcodec]

Thank you for the review and confirmation @brunolm !

By the way @kristoisberg what you think about this as @brunolm said,

I'd suggest maybe having a list of known blocked domains to avoid multiple requests, I'm now more easily hitting the rate limits. Some domains that are probably blacklisted (but I haven't verified): zohomail.com, yopmail.com, 10minutemail.com and guerrillamail.com

Isn't it covered by your approach when it hits the api with newly generated email address of the same domain?

[kristoisberg]

Thank you for the review and confirmation @brunolm !

By the way @kristoisberg what you think about this as @brunolm said,

I'd suggest maybe having a list of known blocked domains to avoid multiple requests, I'm now more easily hitting the rate limits. Some domains that are probably blacklisted (but I haven't verified): zohomail.com, yopmail.com, 10minutemail.com and guerrillamail.com

Isn't it covered by your approach when it hits the api with newly generated email address of the same domain?

I believe this wouldn't have much of an impact, since the blocked domains are relatively uncommon and most double requests would be performed for true positives. There would also be additional maintenance burden and a risk of false negatives since the domains could theoretically be unblocked at any point.

However, in case we go through with it, I suggest a slightly altered behaviour. In case of the ambiguous error:

1. Check if the domain is listed under known blocked domains. If yes, return "available".
2. Retry the request with a random email address.
   a. If the request passes, the email is actually in use, return "taken".
   b. Otherwise, return either "error" or "available" with instructions to report this domain on GitHub so we could add it to the list.

As another implementation detail, the lists of blocked domains would also need to be different for each site. For example, zohomail.com is only blocked by RedTube.

[brunolm]

lgtm

[kaifcodec]

@kristoisberg No worries, I am merging it for now as @brunolm as approved it as well.
If something changes in future we can fix that later.