From a handle to a handful of email-shaped guesses
Mailcat takes a nickname, the local-part of an address, and checks a set of mail providers for whether nickname@that-provider appears to exist. Depending on the provider, the check is an API query or an SMTP conversation. The README's pitch includes the idea that this can be done without notifying the human who owns the mailbox. Treat that as a design aim you verify on an address you own, not as a guarantee you extend to other people. Aims are not switches. If a run ever produces a mail, a code, or a notification, you stop, and that provider is done for the day.
This is useful in a narrow way. You already have a handle. You want a candidate list of addresses that *might* be that handle at a few providers, so that later, on an address you yourself control, you can see what "exists" looks like. It is not a licence to guess a stranger's inbox, and it is not a step you follow by trying passwords. The candidate is a hypothesis. Hypotheses do not get logged into.
The licence is Apache-2.0, which is why you will hear it described as friendlier for products than the GPL tools in this track. Friendlier for a software licence is irrelevant to the person whose nickname you typed, and irrelevant to the provider's terms. Apache-2.0 still expects you to keep its notices if you redistribute the software. It never expected you to probe inboxes.
Common nicknames collide. pip_tadwell_osint101 is a good training input because it should not belong to a thousand strangers. alex should, and will, and a hit on alex@ a large provider tells you almost nothing except that the world contains people named Alex. If your real handle is a common word, do not use it for this lesson. Use the long persona. You are trying to see the tool, not to map a city.
Mailcat turns a nickname into email-shaped hypotheses. A hypothesis is not an envelope, and you do not get to open it to see if you were right.