This page exists to separate three things that are routinely confused in product marketing: features that are live, features under development, and features that are only intended. Everything below is labelled accordingly, and nothing here should be read as a commitment to ship.
Nothing on this page claims a partnership, funding relationship, endorsement or approval from Anthropic, from the maker of any other model, or from any AI provider. TempMails does not describe itself as powered by any model, because no such integration exists.
Live today
These are deployed and running. None of them sends message content to a third-party AI service.
| Capability | Status |
|---|---|
| Temporary inbox, expiry countdown and extension | Live |
| Private access via browser cookie and recovery token | Live |
| Sanitized message rendering with remote images blocked by default | Live |
| Plain-text outbound sending with rate limits and blocklists | Live, operator-controlled |
| Rule-based abuse controls: rate limits, blocklists, spam-pattern matching | Live — deterministic rules, not a model |
The abuse controls deserve the note attached to them. They use fixed rules and lists, not machine learning, and they operate on metadata such as sender, recipient and rate rather than on the semantic content of your mail. If you see the word "intelligent" used about a system on this site, it is describing rules, not a model.
In development
Work has started on the scaffolding for optional, per-inbox AI assistance, but nothing in this section is available to a user yet, and no message is currently processed by a model.
- Consent plumbing. The account-free design has no place to hang an opt-in, so a per-inbox, revocable consent record is a prerequisite for every feature below, not an afterthought.
- Provider abstraction. A thin interface that keeps any model provider behind configuration, so a provider can be declined, switched or removed without touching inbox behaviour.
- Disclosure copy. A privacy notice that describes AI processing in the same plain terms as the rest of the policy, published before any feature is enabled rather than after.
Planned, in evaluation order
Each item lists what it would do and what it would require. Order is the operator's current intent, not a schedule.
1. Email categorisation
Sort an inbox into groups — verification codes, receipts, newsletters, personal mail — so the code you are waiting for is the first thing you see. Requires consent, and would run on the message subject and body.
2. Spam and phishing detection
Flag a message as a likely phishing attempt by reading the link destinations and the tone of the request, rather than only matching a blocklist. This is the highest-value and highest-risk item on the list: it puts model output between a user and a warning about a hostile message, so it would ship as an advisory label and never as a silent action.
3. Summarisation
Condense a long message into a few lines so a user can decide whether to read it at all. Useful specifically because a temporary inbox is read against a countdown; useless if it costs more time than it saves.
4. Privacy-conscious inbox management
Automate the tedious parts — marking a code as used, grouping a newsletter run, noticing that nothing arrived — using as little message content as the task allows, falling back to metadata wherever it can.
Why the Claude API is the candidate under evaluation
If any of the above is built, the API the operator intends to evaluate first is the Claude API, chosen for two ordinary engineering reasons rather than any commercial one: a long context window suits summarising a full message with its headers intact, and the vendor's published handling terms make it possible to write a privacy disclosure that is specific instead of vague.
"Intends to evaluate" is the entire claim. It is not a partnership, not an approval, not a sponsorship, and not a statement that Anthropic has reviewed this service or endorsed these plans. Should that evaluation ever happen, this page and the privacy policy would say so explicitly — and if the evaluation leads nowhere, this section will be replaced with what was actually tried and why it did not ship.
How message content would be protected
These are conditions, not aspirations. A feature in the list above does not ship until all of them hold.
- Opt-in per inbox, off by default. No inbox is processed because a visitor created one. The checkbox is unticked, the choice is recorded, and it can be revoked from the same screen that set it.
- Purpose limitation. Content sent for categorisation is used to categorise that message. It would not be used to train a model, to profile a user, or to build an advertising signal.
- Minimum disclosure. Only the fields a feature needs would leave the service. Metadata and computed properties are tried first; the body is sent only when the feature is impossible without it.
- Named third parties, in the policy. The privacy policy already lists the infrastructure providers involved in the service. Any AI provider would be added to that list, by name, before the feature is enabled.
- No training, no retention beyond the task, stated by contract. The disclosure would state what the provider is permitted to do with the payload, and would be written only after those terms were confirmed in writing.
- Expiry still deletes. AI features do not extend how long a message is kept. The existing cleanup behaviour — messages, attachments and access tokens removed after the inbox expires — continues to govern.
- A way to report a wrong answer. Every AI-assisted output would be labelled as such and carry a correction route, because a summariser that is confidently wrong is worse than no summariser.
What would not change
- Creating an inbox would still require no account, no email address and no personal detail.
- Message contents would still not be used for advertising or profiling.
- No AI feature would be required to create, receive or read mail. The plain inbox would remain the product, not a downgrade of one.
- The repository stays public. The code, this roadmap and the commit history are open source under the MIT licence at github.com/samirpuri204/tempmails, so the distance between what is planned here and what is implemented can always be checked independently.
Corrections
If any statement here is inaccurate, or a capability is described with more confidence than the code supports, that is a defect and the operator wants to know. Send the specific point through the contact page; if it can be verified against a source it will be corrected, and this page's revision date will change.