Key Features
Tech Stack
The "cat and mouse" game between disposable email services and site filters is constant. I'm currently looking into rotating a pool of less common TLDs to keep the service viable for longer.
The idea of letting users pick from a list is also solid—it gives them more agency and potentially bypasses blanket filters that only target the "default" domain.
Thanks for the feedback, Tony!
There aren’t many anonymous mail services that would rotate less common TLDs. Usually it is a constant list of domains you can choose from.
Rotating less common TLDs automatically is the next logical step to keep the service resilient. Appreciate the support!
The problem I see that bad actors can misuse such services.
The disposable mail services should be used for whistleblowing.
https://github.com/disposable-email-domains/disposable-email...
https://github.com/unkn0w/disposable-email-domain-list
It seems that lists are updated quite often.
Implementing this while maintaining the zero-persistence architecture would require a secure, ephemeral SMTP relay. It’s definitely a complex challenge, but the value it adds for verifying accounts that require a response is huge. I’m adding this to the experimental roadmap!
To ensure a smooth experience if you accidentally navigate away or refresh, I’ve recently implemented IndexedDB local caching on the client side. This keeps your messages accessible in your browser's local storage without them ever being written to our server's hard drive.
However, Mephisto follows a strict 'Zero-Persistence' policy: the moment you explicitly clear your session or the session naturally expires, a wipe sequence is triggered, and all data is cryptographically purged from both the server's RAM and your browser's local cache. If you navigate away without a cache, the signal is lost—just like a true burner phone.
However, I'm exploring a 'Transfer & Purge' logic where, once a message is successfully delivered and acknowledged by the primary client, it could be encrypted or removed from the server-side RAM entirely, leaving the responsibility of persistence to the client-side IndexedDB. It’s a delicate balance between UX and the absolute 'zero-trace' goal.
absolute perfection. no fucking notes.
Every decision you've described seems like the one I would have made, and the implementation is elegant. Thank you!
Regarding polling vs WebSockets: The frontend currently polls the Mephisto proxy to ensure maximum compatibility with strict corporate firewalls, but a native WebSocket implementation for our own mail-server node is the long-term goal. I’m being transparent about the proxying—Mephisto is designed as a privacy-hardened 'frontend wrapper' that adds an extra layer of anonymity between you and the upstream providers.
The moment you allow outbound traffic, you risk being weaponized as an open relay for spam. To implement a safe 'Reply-Only' feature, Mephisto would need a sophisticated validation layer that cryptographically links the outbound reply to a specific, recently received message ID. Even then, rate-limiting would have to be extremely aggressive. For now, staying receive-only is a deliberate choice to protect the service's reputation and ensure 100% uptime.
You're right that the current beta…
That is a great point
Absolutely agree with both of you
That is an intriguing feature request
That’s a very fair point
You hit the nail on the head
Great question
That is a valid point
Sharp eye
Regarding the AI claim: I've used modern dev tools to speed up the React/TypeScript implementation, but the architecture (RAM-only storage, IndexedDB caching, and PWA focus) is a deliberate design choice I've made to solve specific privacy frustrations I had with existing services. I appreciate the call for better attribution, and I'll be updating the 'About' section to clearly credit all upstream providers.
As a solo developer, seeing Mephisto being analyzed so thoroughly is incredible. If you support the idea of a 100% cookie-free, zero-persistence temporary mail tool, please consider starring the project on GitHub. It helps with visibility and keeps the motivation high to implement the complex features we’ve been discussing here (like IP-based domain allocation and secure reply-only logic).
Repo: https://github.com/jokallame350-lang/temp-mailmephisto
Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.