# QMail retained notification safety amendment

Status: local implementation contract; not evidence of deployed support.
This amendment supersedes delete-on-read and fetch-as-delivery statements in
qmail-ping.php and qmail-peek.php. No packet fields or command numbers change.

## Immediate compatible safety release

Commands 72 and 73, including resumed long-poll responses, MUST NOT delete a
Tell or mark it acknowledged merely because it was fetched or written to a
socket. This applies to legacy callers and both device-link enforcement modes.
The existing authenticated mailbox routing and rate limits remain unchanged.

Retain indexed Tells for the existing 30-day retention window from latest server
publication (including a re-published version of the same GUID).
Existing fetch delivery masks MUST NOT shorten this window: they are not durable
client acknowledgments. Successful reads do not extend retention. Register Tell
retention independently of whether device-link routing is enabled. Registration
failure must retain the file and be logged; cleanup must fail safe, never infer
permission to delete from missing metadata. Pre-upgrade unindexed files require
an explicit reviewed migration/cleanup, not deletion on fetch.

Ping/Peek can repeat notifications. Clients MUST persist notifications locally
before advancing their polling cursor, and must retry safely after failure.
Callbacks are not proof of persistence. Existing GUID-based deduplication remains
in use; this release does not claim complete edit-version replay semantics.

Legacy cursor filtering and response layout remain unchanged in this immediate
release. Timestamp pagination, simultaneous same-second arrivals, and bounded
response batches require a separate cursor protocol revision; retained storage
allows an earlier-cursor recovery but does not itself solve pagination.

## Follow-on protocol work, NOT implemented by this safety release

Define negotiated per-device durable ACK and an opaque server-assigned ordered
cursor, using existing device-link authentication where suitable. An ACK must
identify the exact Tell version and may be sent only after local DB commit.
An ACK from one device cannot suppress another device's delivery. Repeated ACKs
must be idempotent. Keep an acknowledged recovery window and define device
retirement, quotas, expiry and rollout negotiation. Legacy Ping must remain
non-destructive even when this capability is enabled.

Retaining Tells does not extend public attachment retention and does not replicate
Tells between beacon servers. Those are separate policies and operations.

## Release acceptance

- Ping client A, Peek client B: both can fetch the same Tell.
- Socket disconnect/crash after fetch: Tell remains replayable.
- All legacy delivery-mask bits set: no early reap.
- TTL expiry: indexed Tell can be reaped; unlink failure preserves tracking.
- Client DB unavailable/write failure: no callback or cursor advancement.
- No authentication, payment, object transfer or file-move semantics changed.
- Linux server build and tests plus an isolated two-client live test required
  before deployment. Do not push a fleet-wide auto-deploy as a test.