TempoLife › Features › Log by email
Log a meal by email
Reserve a private address name for your account, see what an inbound mail handler would store about each message, and read what still has to be built before any mail can be accepted.
Not yet receiving mail. There is no MX route and no inbound webhook pointed at TempoLife, so a message sent to any address you reserve here would bounce at the sending server. Nothing on this page has ever received an email.
What this is for
Most people photograph a meal before they think about logging it. The photo is already in the phone; the app is a few taps further away. An email inbox is the one place every phone, every camera app and every share sheet already knows how to reach. Forwarding a picture to a fixed address is a habit that survives a bad signal, a locked screen and a phone that has run out of patience with you.
So the design is deliberately dull: one address per account, a message arrives, a parser looks at the attachment and the subject line, and a diary entry appears for you to confirm. No app open, no login, no waiting on a network round trip while you eat.
The reason this page exists before the feature does is that the address itself is the part that needs care. An address is a credential you paste into a mail client and then forget about for two years. It has to be unguessable, revocable and cheap to replace, and you should be able to read exactly what it records before you ever use it. That part is built. Receiving mail is not.
Your address name
Reserving a name needs an account, because the name has to belong to somebody. Signed-out visitors can read everything else on this page — the storage rules, the retention window and the revoke path are all described below and none of them change once you sign in.
Your ingest log
The ingest log is the record of what arrived. It is per account, so it appears here once you sign in. Its shape is fixed and described below: one line per message, carrying the sending domain, an outcome and a short detail — never the message, never the photo, never the sender's full address.
What still has to exist
Four separate things, and none of them are half-done:
- A route for inbound mail. Either an MX record pointing a subdomain at a mail server we run, or an inbound webhook from a mail provider that accepts the message and posts it to an endpoint here. Today neither exists: no MX record delegates a TempoLife subdomain to an inbound handler, and no provider is configured to forward parsed mail to us.
- A parser. Something that opens a MIME message, finds the image parts, rejects everything that is not an image or plain text, strips the rest, and hands the result to the same food-recognition path the app uses. Attachment handling is where mail parsers historically get exploited, so this is the part that needs the most review, not the least.
- A size limit and a sender allow-list. An address that anyone can write to is an open door: a stranger who learns it can fill your diary or your disk. The rule has to be that mail is accepted only from addresses you have confirmed on your own account, that anything over a fixed size is refused at the door rather than downloaded, and that a refused message leaves a log line and nothing else.
- A confirmation step. A parsed meal should land as a suggestion you approve, not as a silent write to your diary. Mail is spoofable; a diary entry that appeared without your say-so is worse than no feature.
Until all four are in place this page reserves a name and explains itself. That is the whole of it.
The full design, step by step · What it would store about you
Frequently asked questions
Is anything being emailed to me?
No. This surface never sends mail and never has. It reserves a name and shows you an empty log.
Can someone else use my address?
A reserved name is unguessable rather than secret, so treat it as you would a share link. The protection that matters is the allow-list described above: when the handler is built, mail from an address you have not confirmed is refused rather than stored.
What happens to the photo I send?
Nothing today, because nothing is received. In the design, the image would follow the same path as a photo taken in the app, and the raw message would be discarded once parsed. The ingest log would keep the sending domain and an outcome, never the message body.
How do I stop it?
Revoke the name on this page. A revoked name is refused by a future handler and can never be re-issued to anyone else.
Source: TempoLife feature status — inbound mail handler not implemented · checked 2026-09-02
The app already does this without email
Photograph a meal in TempoLife and it is logged in a couple of taps, with the food database and your day's totals right there.