component · 0x0030 / 0x0031

Email Zone.

The Email Zone defines GUID-addressed inboxes for POZ mail. Names are sugar for humans; the protocol only uses GUIDs. Each inbox has its own end-to-end encryption key and references a service entry that knows where the mail servers are.

GUID addressing

Every inbox has a 16-byte random GUID and a human-readable name ("Inbox", "Support", "Newsletter"). The messaging protocol only ever addresses inboxes by GUID. This:

Eliminates namespace collisions — two records can both have an inbox named "Support" without conflict.
Lets you rename an inbox without breaking incoming mail.
Lets you have many inboxes per POZ record, each with its own key.

end-to-end encryption

Each inbox declares an X25519 encryption key (referenced from the Public Key Map). Senders encrypt to that key; only the holder of the corresponding private key can read. The mail server stores ciphertext, never plaintext.

message types

Type	Token	Use case
SINGLE	—	Fire and forget
SINGLE_REPLY	created	Back-and-forth conversation
ONGOING	subscription	Repeated delivery (newsletter, alerts)
REPLY	existing	Reply with conversation chain
FORWARD	—	Forward with embedded originals

Tokens are how a recipient revokes future mail without revealing private state. Cancel a subscription token, and that sender's ongoing messages stop being accepted. Cancel a single-reply token, and the conversation ends.

verifiable conversations

Replies include a conversation chain — a list of message hashes linking back through the full conversation. Forwarded messages embed the original chain. The recipient can verify every message back to the original senders' POZ identities, end to end. There is no way to splice a forged message into the middle of a conversation.

fig 01 · each reply carries the previous message's hash. Forwarded threads embed the chain. Splicing a forged message anywhere would invalidate every subsequent hash.

where mail lives

The inbox entry references a service in the Service Zone by hash. That service entry lists the mail servers — same pool / priority / weight model as everything else. Migrating mail providers means publishing a new service entry; existing senders see the change because the service hash changes.