feat(heuristics): add Fake Email analyzer to validate maintainer email domain

[AmineRaouane]

Summary

This PR adds a new heuristic analyzer called FakeEmailAnalyzer. It verifies the validity of maintainer email addresses listed in a PyPI package by checking both the format and the existence of MX records for their domains. This helps detect packages with fake or throwaway emails, which are often indicative of malicious intent.

Description of changes

• Implemented FakeEmailAnalyzer that:
  • Validates email format using a regex.
  • Verifies the existence of MX records for the email domain via DNS resolution.
• Updated detect_malicious_metadata_check.py to include and invoke this new analyzer.
• The analyzer handles DNS errors and skips analysis if no email is present.
• The logical reason for combining quickUndetailed with a failed(Heuristics.FAKE_EMAIL.value) is that a package that is rushed onto a platform by someone using a fake email address points to an actor who may be trying to quickly distribute a package while obscuring their identity and avoiding being investigated.

Related issues

None

Checklist

• I have reviewed the contribution guide.
• My PR title and commits follow the Conventional Commits convention.
• My commits include the "Signed-off-by" line.
• I have signed my commits following the instructions provided by GitHub. Note that we run GitHub's commit verification tool to check the commit signatures. A green verified label should appear next to all of your commits on GitHub.
• I have updated the relevant documentation, if applicable.
• I have tested my changes and verified they work as expected.

[behnazh-w]

Can you please make check_deliverability configurable via defaults.ini so that you can turn it off in unit tests? We try to avoid network calls in our unit tests.

[behnazh-w]

is example.net supposed to be a valid domain?

[AmineRaouane]

Yes and no. The domain is technically valid, but it’s reserved by IANA and not intended for real-world use. So to ensure the email is actually usable by a real user, Should I add a list of reserved domains and TLDs and check against them before proceeding with validation or acceptance, or should I keep it as it is?

[art1f1c3R]

I see the email validator packages has a test environment flag?

test_environment=False: If True, DNS-based deliverability checks are disabled and test and **.test domain names are permitted (see below). You can also set email_validator.TEST_ENVIRONMENT to True to turn it on for all calls by default.

Would that maybe be better in a unit test? If a user does use those IANA reserved domains shouldn't it fail if we use check_deliverability as they aren't set up to receive emails?

[behnazh-w]

Same question, if example.com is supposed to be a valid domain.

[art1f1c3R]

Is this the package email-validator? I can find a package spelled with a hiphen, email-validator, but I can't find one spelled with an underscore like you have here.

[art1f1c3R]

This may be better off raising a HeuristicAnalyzerValueError, as the info field should always be a part of the PyPI JSON data, so if it isn't there then we were given malformed JSON data.

[art1f1c3R]

I see here we're extracting the email fields and then running the is_valid_email function directly on what is present in that field. Have you tested if this works on fields where the email is not the only text present? I've got some PyPI JSON data from Django where author_email looks like this:

"author_email": "Django Software Foundation <[email protected]>"

So the text includes more than just the email. Here's another example from the black package:

"author_email": "Łukasz Langa <[email protected]>"

It may also be a string of multiple emails as well, like the ultralytics package:

"author_email": "Glenn Jocher <[email protected]>, Jing Qiu <[email protected]>"