DEV Community: Ishan Shrestha

Your disposable email list is rotting (size wont save you)

Ishan Shrestha — Mon, 14 Sep 2026 15:02:51 +0000

Most signup guides brag about list size.

“110k domains.”

“300k domains.”

“Biggest blocklist on npm.”

Cool screenshot. Doesn’t mean the gate still works on Thursday.

Here’s the pattern I keep seeing. Someone copies a GitHub dump, wires disposable: true into validation, ships, and sleeps well. A week later a fresh yopmail clone walks straight through createUser. The list still looks huge. The product is already rotting.

Size is a vanity metric. Freshness is the product.

What actually breaks

Day one feels great. Mailinator dies. Guerrilla Mail dies. The dashboard looks clean. You paste a package list into Laravel or Node and call it done.

Then a burner provider spins up a cheap new domain. Or twenty. Your package hasn’t released in three months. The rule still “passes.” Trial seats fill with ghosts who never open the welcome mail. You start rewriting onboarding copy while the real leak is upstream.

Binary blocklists have a second failure mode. They feel productive until you nuke a real person on Apple Hide My Email or SimpleLogin. Those addresses look weird. They are not tempmail. If every unfamiliar domain is guilty, you trade fake signups for angry real ones.

You need both:

A list that moves
An allowlist for privacy relays on purpose

Most tutorials ship a static file for #1 and skip #2.

Size without motion is theater

I run Email Score. Signup-gate check: syntax, DNS/MX, disposable, then allow or block. Our disposable domain database is 216,254 domains.

I’m not leading with that number on purpose.

Competitors already market bigger piles. TempMailChecker talks 300k+. A bigger integer doesnt mean their list moved this week. It means they scraped more history.

The only number I care about after an Import is newly added. Everything else was already known.

What we run instead

Once a week we merge three maintainable, disposable-only feeds. Not free-provider lists. Not “every Gmail clone on earth.”

disposable-email-domains (CC0) — community standard, bindings everywhere, boring in a good way
fakefilter (BSD-3) — closer to realtime provider monitoring
groundcat (MIT) — aggregates then MX-validates, plus an allowlist worth respecting

Normalize. Dedupe. Subtract privacy aliases hard: Apple Hide My Email, SimpleLogin, Firefox Relay, Duck aliases, addy.io.

Also refuse to treat Gmail, Yahoo, Outlook, and the usual free providers as disposable. That confusion shows up in bad lists more than people admit.

Then paste into the admin Import tab. One domain per line. Up to 50k per request. The DB skips what it already has.

A quiet week, real numbers

Last Import looked like this:

Public merge after allowlist: about 16.5k domains
Already in our DB: most of them
Newly added: 560
Errors: 0

The live disposable database is at 216,254 domains now.

The story isn’t “we have 216k.”

The story is 560 domains that would have been misses if wed frozen the list.

If your weekly add count is zero for a month, either burners got polite (they didn’t) or your sources went stale.

Operator checklist you can steal

You don’t need our product to copy the shape.

Sync on a schedule. Weekly is fine. Daily if trial abuse is loud.
Prefer permissive disposable-only feeds. Dedupe. Subtract privacy relays on purpose.
Hard-block known burners. Soft-score the gray area: brand-new domains, catch-all MX, role addresses like info@.
Fail open if the check times out. A dead validation path that takes signup down with it is worse than a delayed flag.
Run the check before createUser. Cleaning the users table later is worse than never writing the junk.
Keep confirmation email for ownership. Disposable detection is a courtesy filter, not proof of a human.

What we deliberately skip as the main gate: heavy SMTP RCPT probes. Slow. Often blocked. Catch-alls lie. Fine as an optional signal elsewhere. Bad as your only signup story.

Where Email Score fits

If you want the live piece without babysitting three GitHub remotes yourself, thats what we built.

One API call. Syntax, DNS/MX, disposable. Signup-shaped verdict. Not a bulk list-cleaner. Not a 0–100 vanity score.

Email Score · Validate emails before you send

Validate syntax, MX, and deliverability before you send. Email validation API built by Neural Evo.

https://emailscore.neuralevo.com

The 216,254-domain database is evidence at the bottom, not the headline. The weekly merge is the habit. If your disposable list hasn’t moved since you pasted it in, it isn’t protecting you. Its decorating the README.

If your list hasn’t moved in 30 days, what are you actually blocking?

Originally published on Medium: https://medium.com/@ishanshrestha/your-disposable-email-list-is-rotting-size-wont-save-you-9edec7a9bfdc

I built a small C++ game engine so an AI IDE could touch the whole thing

Ishan Shrestha — Thu, 03 Sep 2026 20:08:11 +0000

Originally posted on Medium.

I wanted to make a game. I also wanted the AI IDE on my desk to edit the whole running process, not just the scripts.

Godot still makes you do linking and scene wiring in the UI. Unreal would not run on this laptop. Writing a raw Vulkan renderer from scratch meant months before I could drop a cube on screen. So I took the middle: Diligent Engine for the GPU, and I built everything else.

The machine is an Intel HD 620. No discrete GPU. That forced the rest of the design. Keep draw calls low. Cull hard. Do not pull in heavy middleware.

Demo: https://youtu.be/nsptiy-I4Ps
Repo: https://github.com/Ishan5hrestha/SapanaEngine

Why Diligent, not Godot or raw Vulkan

Full engines hide the part I wanted to learn, and they are too fat for this hardware. Raw Vulkan is a career by itself. Diligent sits in between. Pipeline state, resource binding, HLSL once, targets Vulkan / D3D12 / Metal / D3D11 / GL. It is a dependency. It is not the codebase.

I write ECS, scenes, assets, physics, cameras, input, and a flight sim. Diligent draws.

What is in the engine

ECS and scenes. EnTT. Scenes are JSON. Entities get transforms, mesh refs, physics blocks, LOD groups. A loader fills the registry at startup.

Assets. GLB/glTF through Diligent's loader, wrapped in my own cache. Builtin cube and plane for quick tests. String IDs like builtin:cube or meshes/drone.glb.

Rendering. Two modes in config: Basic (forward, color, optional PCF shadows) and PBR (Diligent's GLTF PBR path, behind pimpl). Procedural sky, no skybox texture. Cascaded shadows. Frustum cull, distance LOD, far cull with hysteresis.

Physics. Jolt 5.3.0, FetchContent, pinned. Opt-in. No physics block in the JSON means mesh-only. Static and dynamic bodies, box and plane shapes for now. Public headers never see Jolt. Pimpl.

Flight. The sandbox has a quad. Two profiles on the same craft.

DJI: level, altitude hold, heading-frame move.
FPV: acro, rate pitch/roll/yaw, idle throttle is freefall.

Four virtual motor forces at the arm corners. Tunables in config/flight.json. Cameras: freelook, chase, FPV nose. L flips the flight profile. K cycles cameras.

Input. Bindings live in JSON. Cursor capture for mouse look.

Most of the C++ came out of the AI IDE. The real work was keeping it light enough that this laptop still runs, and fixing the parts the model got wrong.

Sandbox

That shot is Sapana Sandbox on Vulkan. Same frame you see in the title bar: mid-60s fps on integrated graphics. Green ground with static physics. Dynamic cubes. Visual-only glTF cube. One flyable drone. About forty static trees with box colliders.

Edit a config or the scene JSON, rebuild, relaunch. No recompile hunt for every tweak. Builds on Linux (Mint 22.3 here) and Windows (win branch).

The bug

Far-distance cull, with LOD enabled, can strobe. Builtin cubes pop. Sky shows through. Freelook and drone share one view path, so both get it. Far hide vs camera far plane, shadow casters dropping while receivers still draw, PCF on basic meshes. Hysteresis helped. It is not fixed. Workaround: turn LOD off in config/lod.json and restart.

What this is not

It is not Unreal. It is not a product. It is a small engine for a specific game, on limited VRAM, where the whole loop is files an IDE can touch.

If you want the boring details, the README in the repo has the layer list, controls, and build steps.

How I Stop Fake Signups From Farming Free Credits (JS/Python)

Ishan Shrestha — Mon, 31 Aug 2026 16:28:05 +0000

A few client apps had the same leak.

They offered free credits so people could try the product. Normal and fair. Then throwaway emails showed up, grabbed the free stuff, and disappeared. Support time went up. Costs went up. Real users got a worse experience.

We tried free tools. One helped for a while. One broke at the worst time. After patching this more than once, I wanted one simple rule for signup:

If the email looks abusive or undeliverable, block quietly and move on.

That is what I built into: https://emailscore.neuralevo.com/

This post is the practical version: what to check, and copy-paste code in JavaScript and Python.

The rule that matters

Call the validate API and gate on verdict.

allow: continue signup / trial
block: stop with a neutral message

You can inspect other fields later. For signup abuse, start with verdict.

POST https://api.emailscore.neuralevo.com/api/v1/validate/email

Header:

Authorization: Bearer YOUR_API_KEY

JavaScript (Node fetch)

async function shouldAllowSignup(email, apiKey) {
  const response = await fetch(
    "https://api.emailscore.neuralevo.com/api/v1/validate/email",
    {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ email }),
    }
  );

  if (!response.ok) {
    throw new Error(`Validate failed: ${response.status}`);
  }

  const data = await response.json();

  // Primary signup gate
  return data.verdict === "allow";
}

// Example
const ok = await shouldAllowSignup(
  "ada@company.com",
  process.env.EMAIL_SCORE_API_KEY
);

if (!ok) {
  // Show a neutral error. Do not explain the abuse logic.
  console.log("Please use a different email.");
}

Python (requests)

import os
import requests

def should_allow_signup(email: str, api_key: str) -> bool:
    response = requests.post(
        "https://api.emailscore.neuralevo.com/api/v1/validate/email",
        headers={
            "Authorization": f"Bearer {api_key}",
            "Content-Type": "application/json",
        },
        json={"email": email},
        timeout=10,
    )
    response.raise_for_status()
    data = response.json()
    return data.get("verdict") == "allow"


ok = should_allow_signup(
    "ada@company.com",
    os.environ["EMAIL_SCORE_API_KEY"],
)

if not ok:
    print("Please use a different email.")

What a response looks like

{
  "input": "ada@company.com",
  "normalized": "ada@company.com",
  "verdict": "allow",
  "policyReason": "clean",
  "checks": {
    "syntax": "pass",
    "disposable": "miss"
  },
  "deliverability": {
    "status": "deliverable",
    "reason": "mx_found"
  }
}

Useful extras when you need them:

checks.disposable: throwaway / block list hit
deliverability.status: can the domain receive mail
policyReason: why policy decided what it did

For most signup flows, still gate on verdict first.

Where this helps

Free trials and free credits
Waitlists
Invites
Any form where fake emails quietly cost money

Try it

If you want to poke at it without wiring code first, there is a free checker on the homepage:
https://emailscore.neuralevo.com

There is also free API access for devs.

If you try the snippets, tell me what broke or felt unclear. I am still improveing this from more client pain, so blunt feedback helps more than polite compliments.

Originally published on Medium.