TempoLife › Features › Log by email › how-it-works
How logging by email would work
The full design for meal logging by email: the route a message would take, what the parser would accept, the limits that would apply, and why none of it is switched on.
None of the following is running. This is a design description, written in the conditional on purpose.
The path a message would take
1. Delivery. Your mail client sends to your reserved local part at a TempoLife subdomain. For that to resolve, the subdomain needs an MX record pointing at something that accepts SMTP. The alternative — and the more likely first version — is a mail provider that receives on our behalf and posts a parsed message to an HTTPS endpoint. Both are ordinary infrastructure; neither is configured.
2. The door check. Before a byte of body is read, three things would be checked: is the recipient a live reserved name, is the sending address on that account's confirmed list, and is the declared size under the limit. A failure at this stage would end the message. That is the cheapest place to say no, and the only place where saying no costs nothing.
3. Parsing. The message would be walked part by part. Image parts of known types are kept. Everything else — HTML bodies, calendar invites, nested messages, archives, anything with a content type we do not expect — is dropped without being opened. Filenames are never used to decide what a part is; the declared type and the leading bytes are.
4. Recognition. The surviving image would go through the same food-recognition path a photo taken in the app uses. Nothing new is invented for email: the same model, the same portion estimates, the same uncertainty.
5. Confirmation. The result would appear in the app as a pending entry, not as a logged meal. You confirm or discard it. This is the step that makes the whole feature safe to build: even a message that got through every check cannot silently change your diary.
6. The log line. One row is written whatever happens — accepted, refused, oversized, unparseable — recording the time, the sending domain and the outcome. That row is what you see on the main page.
What would be refused
- Mail from an address that is not on your confirmed list, whatever it claims in the From header.
- Anything above the message size limit, refused during the SMTP conversation rather than downloaded and then rejected.
- Attachments that are not plain images, including archives, documents and anything executable.
- Mail to a revoked or rotated name, permanently and with no way to re-enable that particular name.
- Bursts: a rate limit per address per hour, because an address that can be written to is an address that can be flooded.
Why it is not built yet
Accepting mail from the public internet is a commitment, not a feature flag. It means running or renting an SMTP endpoint, keeping a MIME parser current, handling spoofed senders, absorbing spam volume aimed at an address that will eventually leak, and storing images that arrived from outside the app. Each of those has an ongoing cost and a failure mode where somebody else writes to your diary.
The honest position is that the address side is easy and is done, and the receiving side is the entire job. Rather than shipping a page that implies mail works and quietly drops everything, this surface says what it is: a reservation desk with the restaurant still under construction.
Frequently asked questions
Could I use a filter to auto-forward meals?
That is the intended pattern once it works: a rule in your own mail client that forwards messages with a photo to the reserved address. It would still be subject to the allow-list, because the forwarding address is what arrives.
What about receipts and menus rather than photos?
Plain text in the body would be parsed the same way typed text is in the app. Rich HTML receipts would not be, at least not in a first version — parsing arbitrary marketing HTML is a much larger job than reading a line of text.
Would there be an address per meal type?
A plus-tag on the same address (breakfast, lunch) is the obvious way to do it without minting more names. It is a detail for later; the base address has to exist first.
Source: TempoLife feature status — inbound mail handler not implemented · checked 2026-09-02