Pritam Khedekar
Why I Built TIP Tool: A Self-Hosted Way to Stop Handing Out My Real Email Address

Why I Built TIP Tool: A Self-Hosted Way to Stop Handing Out My Real Email Address

By Pritam Khedekar · Sep 13, 2026

The problem: your inbox is a standing attack surface

Every sign-up form, every "download the whitepaper" gate, every free trial asks for the same thing: your email address. Once it's given, it doesn't come back. It gets sold, scraped, breached, or simply used more aggressively than you agreed to — and from a security research standpoint, that address becomes a durable identifier an attacker can build a profile around.

This isn't a hypothetical. Phishing remains one of the most consistently effective initial-access techniques in the threat landscape. CrowdStrike's 2026 Global Threat Report frames the current era as the "year of the evasive adversary" — attackers increasingly rely on social engineering and identity-based entry points rather than pure malware, because a real, monitored, high-trust email address is worth more to them than a zero-day (CrowdStrike, 2026). MITRE's own ATT&CK framework formalizes this: phishing (T1566) sits at the top of the Initial Access tactic precisely because it's cheap, scalable, and doesn't require breaking anything technical — it just requires an inbox to send to (Strom et al., 2020).

Academic research backs this up with numbers, not just anecdotes. Suzuki and Salinas Monroy (2022) model phishing mitigation as a sequential schema — pre-attack, attack, and post-attack stages — and argue that most organizational effort is spent reacting after a phishing email lands in an inbox, rather than reducing the number of inboxes an attacker can realistically reach in the first place. A 2026 field study of digital microfinance institutions in Kenya found that even when organizations formally adopted frameworks like ISO/IEC 27001, NIST CSF, or CIS Controls, 83% of them used those frameworks as compliance checklists rather than operational practice — and phishing incident rates only dropped meaningfully (22–35%) where detection and monitoring were actively maintained, not just documented (Mathenge, Mukunga, & Mwangi, 2026). In other words: policy alone doesn't shrink the attack surface. Reducing exposure does.

And the human side of this problem is getting harder, not easier. A 2025 systematic review of phishing in the age of generative AI found that LLM-assisted phishing content is now good enough to defeat the traditional "look for bad grammar" heuristic that used to be a reasonably reliable human defense (Jabir, Le, & Nguyen, 2025). Altulaihan et al. (2023), reviewing email security tooling broadly, reach a similar conclusion from the defender's side: most email security investigation tooling is built to analyze phishing after delivery, not to prevent an address from becoming a target in the first place. And once a real identity is compromised at the email layer, the downstream cost is severe — CISA's joint advisory on the BianLian ransomware group documents exactly how an initial foothold (frequently phishing-adjacent, credential-based access) escalates into full data-extortion incidents against real organizations (CISA, FBI, & ACSC, 2023/2024).

The common thread across all of this: the fewer real, permanent, monitored addresses you hand out, the smaller your personal attack surface. That's not a new idea — disposable/temporary email services have existed for years — but most of them are third-party services you have to trust with your mail, hosted by someone you don't know, with no guarantee of what happens to the messages that land there.

Suggested screenshot: none needed here — this section is narrative/citation-heavy.

What TIP Tool actually is

TIP Tool (Temp Identity Privacy Tool) is a self-hosted, open-source PHP application that gives you your own private, disposable-email portal — one you run, one you own the database for, and one nobody else's business model depends on.

Repository: https://github.com/protonic/TempIdentityPrivacy-TIP-Tool

At a glance, it's a single-owner tool (not a multi-tenant public service): you sign in as the admin, generate a random address like x7k2p9@yourdomain.com, use it wherever you'd normally hand out a real email, and read whatever arrives in a private inbox UI — without your actual email provider ever seeing that traffic.

Suggested screenshot: the public landing page, and the "Sign in to your mailbox" panel.

The part most write-ups skip: how it actually captures mail without 1,000 mailboxes

This is the detail that makes TIP Tool practical to self-host, and it's worth explaining precisely because it's a genuinely elegant use of a decades-old email feature: catch-all routing.

You don't create a new real mailbox every time TIP Tool generates a new address. Instead:

  1. You configure one domain with catch-all email enabled — most registrars and mail hosts support this natively, routing "any unknown recipient @yourdomain.com" into a single real mailbox you control.
  2. You add that one mailbox's IMAP credentials into TIP Tool's admin panel, once.
  3. Every address TIP Tool generates afterward — abcd1234@yourdomain.com, qz88fx@yourdomain.com, however many — is never a real mailbox anywhere. The catch-all rule silently forwards all of them into that single monitored inbox.
  4. TIP Tool's IMAP fetcher connects to that one mailbox, reads incoming mail, and matches each message's recipient address back to the specific temp address you generated — so in the UI, it looks like each generated address has its own private inbox, even though physically everything landed in one place.

This means the entire mail infrastructure for the tool is: one domain, one catch-all mailbox, one set of IMAP credentials — regardless of whether you generate ten addresses or ten thousand. And critically, you don't need to expose this publicly at all. If your only goal is personal privacy, you can run the whole thing on a local XAMPP/LAMP install on your own machine — no public hosting required — as long as your one catch-all domain/mailbox is reachable over IMAP from wherever the app runs.

Suggested screenshot: the "Manage Domains" admin screen showing one domain added with catch-all IMAP credentials (redact the real password/host if you want).

What's actually protecting you under the hood

Since this is a security-adjacent tool, it's worth being explicit about what security engineering went into it, not just the headline feature:

  • CSRF protection on every state-changing form (login, domain management, settings), with server-side token validation tied to the session.
  • Encrypted IMAP credential storage — the IMAP password for your catch-all mailbox is encrypted at rest using a random per-row initialization vector (AES-256-CBC), not stored in plaintext in the database.
  • Rate limiting and abuse controls — hourly/daily caps on address generation per IP, with getClientIP() deliberately not trusting client-supplied X-Forwarded-For-style headers by default, since those are trivially spoofable on a direct connection.
  • Persistent login throttling — failed admin login attempts are tracked server-side (not in a session cookie that resets the moment you clear cookies), on top of a database-backed account lockout after repeated failures.
  • CSP and standard security headers — X-Frame-Options, X-Content-Type-Options, a real Content-Security-Policy, and noindex/nofollow robots directives so the mailbox itself never gets crawled or indexed.
  • Sandboxed HTML rendering for incoming email bodies, since an email client that blindly renders arbitrary sender-controlled HTML is a classic XSS vector.

None of this is exotic — it's the boring, correct baseline every self-hosted tool handling credentials and third-party content should have. But it's exactly the kind of thing that's easy to skip when a tool is "just for me," so I built it in rather than around it.

Suggested screenshot: the CSP header or security headers visible in browser dev tools (Network tab → Response Headers) — nice, concrete proof for a technical reader.

Setting it up on Hostinger

This is the fast path; the repository's README.md has the full manual walkthrough (including IIS and generic cPanel hosts) if you want more control or if you skip the wizard described below.

  1. Get the code onto Hostinger. In hPanel, open Websites → Dashboard → File Manager → Access files of your domain, and upload the contents of the repository directly into public_html (not in a subfolder, unless you're prepared to adjust include paths). Screenshot: File Manager showing the uploaded project structure inside public_html.

  3. Confirm PHP version and extensions. Under Websites → Dashboard → PHP Configuration, select PHP 8.2 or 8.3. Under PHP Info, confirm imap, openssl, mbstring, and pdo_mysql are enabled — if imap isn't available on your plan, the mail-fetching half of this tool won't work. Screenshot: the PHP Configuration screen with the version selected.
  4. Create a MySQL database in hPanel, note the DB name/user/password, and import sql/installer_public_release.sql via phpMyAdmin. Screenshot: phpMyAdmin's Import tab mid-import, or the resulting table list.
  5. Run the setup wizard. Visit https://yourdomain.com/setup.php in your browser. It's a one-time form: fill in your site name, site URL, admin email, and the database credentials from step 3. It tests the DB connection before writing anything, then generates the external config folder (../tip-config/, one level above your web root — outside the publicly served directory, so it's never reachable over HTTP) and, optionally, a ../tip-cron/ folder with ready-to-schedule fetch/cleanup scripts. Screenshot: the setup.php form filled in, and the "Setup complete" confirmation screen.
  6. Delete setup.php immediately. It can write live database credentials to disk, so it should never remain reachable on a public server once setup succeeds — the page itself displays this warning.
  7. Create your first admin account. Generate a bcrypt hash (php -r "echo password_hash('YourStrongPassword', PASSWORD_DEFAULT);") and insert it into the admin_users table via phpMyAdmin.
  8. Add your catch-all domain. Sign in at /admin/login, open Manage Domains, and add the one IMAP mailbox behind your catch-all setup (host, port, username, password, SSL). Screenshot: the Manage Domains "Add Domain" form.
  9. Schedule the cron jobs. In hPanel's Websites → Dashboard → Cron Jobs, add the fetch script (every 1–2 minutes) and the cleanup script (hourly), pointing at the absolute paths inside your generated tip-cron/ folder. Screenshot: the hPanel Cron Jobs list showing both scheduled entries.
  10. Test end to end. Generate an address, send it a real email from an external account, and confirm it shows up in the inbox UI within a minute or two. Screenshot: the mailbox UI showing a freshly generated address and a received test email.

What this doesn't solve — and shouldn't be used for

Worth saying plainly, since this is a security-adjacent write-up: a disposable address is a privacy tool, not an authentication or fraud-prevention tool. Never use a temp address for banking, government services, healthcare, or any account with password-recovery flows you might actually need later — losing access to the catch-all mailbox means losing access to that recovery chain. Phishing and social engineering also don't stop being effective against you personally just because a given address is disposable; if anything, the CISA BianLian advisory (2023/2024) is a good reminder that the actual damage from a phishing-originated compromise usually happens well past the inbox, once an attacker has a foothold. Reducing address exposure is one layer, not the whole stack.

Try it yourself

The full source, the setup wizard, and the manual deployment guide (Hostinger, generic cPanel/GoDaddy, IIS, and local XAMPP/LAMP for personal use) are all in the repository:

https://github.com/protonic/TempIdentityPrivacy-TIP-Tool

References


identity and access management IAM privacy cyber security email security.

Comments

No approved comments yet.