Show HN: Email Sleuth – Find and Verify Emails (Rust CLI)

3 iLikeFunctional 2 4/26/2025, 3:53:47 PM github.com ↗
I built this because I was tired of paying $99/month for tools like Clearbit and Hunter — and most of them don’t even verify if the email address exists. They just guess.

So I wrote a CLI tool in Rust.

You give it:

    A full name (like “Jane Smith”)

    A domain (like company.com)
It:

    Generates common email patterns (jane@company.com, jsmith@, etc)

    Scrapes the company website for any public emails

    Does an SMTP check (MX + RCPT TO) to verify if the email exists

    Scores and ranks the candidates
Why?

I wanted something fast, private, scriptable, and verifiable — not just “guesses” wrapped in a pretty UI. This has JSON in/out, works well in batch mode, and can run locally or in CI pipelines.

Notes

    Port 25 warning: SMTP verification requires outbound port 25 access. Most home ISPs block this. I’m not a networking guy, so maybe there’s a better solution — but I just run it on a GCP VM and it works fine there.

    Rust has been awesome for this: fast HTTP/S scraping, socket-level control, robust error handling, and painless multithreading. Probably wouldn’t want to write this in Python.
It’s open-source (MIT), no trackers, no signup, no web UI. Not sure if this is useful to anyone outside of that weird founder/hacker/recruiter intersection, but figured I’d share.

Would love feedback, issues, feature requests, or just a reality check.

Comments (2)

badmonster · 4d ago
How does Email Sleuth handle potential issues with spam filters or anti-spam protocols when performing the SMTP verification (MX + RCPT TO), and does it have any strategies for mitigating false positives or inaccurate verification results?
iLikeFunctional · 3d ago
The most crucial point is that Email Sleuth does not send an actual email message. It performs the SMTP handshake (EHLO), specifies the sender (MAIL FROM), and attempts to specify the recipient (RCPT TO). It stops before the DATA command, which is where the email body and headers (subject, content, etc.) would be sent.

Catch all domains is a major source of inaccuracy. The verify_smtp_email function includes a basic catch-all detection heuristic. If the initial RCPT TO for the target email succeeds (2xx), it then tries RCPT TO with a randomly generated, likely non-existent email address at the same domain (e.g., no-reply-does-not-exist-123456@domain.com). If this also succeeds, it flags the original result as inconclusive_retry with a message indicating a "Possible Catch-All". This isn't foolproof (some servers might have smarter catch-all filters), but it's a common technique.