# Gmail kept the body and changed the ID

The preview sent its test email successfully. Our acceptance script still failed.
The saved provider receipt said the send had happened, but searching for the
Message-ID we had reviewed found nothing. Retrying the send would have answered
the wrong question, at the cost of another email.

We first inspected the one synthetic message already in the account. Its recipient
was correct, its replacement attachment was present, and the internal attachment
source headers had been removed. That last detail mattered: it suggested Gmail
had used the frozen outgoing message. The evidence did not support blaming the
whole raw-MIME request just because one header had changed.

A smaller experiment separated those possibilities. A short plain-text self-send
arrived in the inbox with the expected body, but Gmail replaced its Message-ID.
Shortening our identifier did not help. Using the account's domain did not help
either. The next experiment added a dedicated attempt header. Gmail preserved
that value while replacing Message-ID again.

The local send ledger was already doing its most important job. Once submission
was uncertain, it refused to send again. What had failed was our way of finding
the receipt afterward. We had treated a header we supplied as a header the
provider would necessarily preserve.

Recovery now has a second, narrower piece of evidence. The reviewed MIME carries
an attempt marker, and the private ledger records that marker with the submission
time. If the original Message-ID lookup finds nothing, recovery examines a bounded
page of recent sent-message metadata. It returns a receipt only for one exact
marker match. Another page, two matching messages or no match leaves the send
uncertain. A subject match would have been easier to implement, but it would not
identify the operation the user approved.

The live test then simulated a missing receipt after a real send, with the send
method replaced by an assertion that forbade another submission. Recovery found
the stored message. The body and attachment hashes also matched the reviewed
content. That tested the provider behavior the mock had never challenged.

The next failure was more mundane. Downloaded attachment hashes matched, but our
path assertion rejected the destination. macOS had resolved `/var` to
`/private/var`; the downloader used the resolved path and the test did not.
Comparing resolved directories fixed that assertion without relaxing the rule
that downloads must stay in the requested directory. The full live journey then
passed, including mailbox actions and two collision-safe attachment downloads.

These are local fixes after the published 1.8.4a1 preview. They do not change the
bytes already on PyPI, and they do not turn an unconfigured physical NAS into a
passed test. They do change what the next acceptance run measures: the content
Google stored, the receipt we can recover, and whether another send was prevented.

## The receipt became the release criterion

When the preview was ready for promotion, a green command was no longer enough
for us. The first test had already shown why: the provider had completed the work
while our local lookup insisted it had not. We went back to the lost-receipt case
instead of adding a retry to make the command look successful.

That distinction survived the stable review. Recovery still has to find one
provider-preserved marker within a complete bounded page; an ambiguous result
still leaves the send uncertain. Promoting the package does not widen that search
or make a subject line count as a receipt. If Gmail stops preserving the marker,
we will need another way to identify the approved operation before allowing
recovery to report success.

The 1.8.4 release includes that behavior after the real self-send journey and the
combined 8,665-test regression run. The mock remains useful for proving that an
uncertain send cannot repeat. The stored message remains necessary for proving
that our chosen identifier survives the service. Neither test can replace the
other; the first failed acceptance run is the reason we now keep both.