@@ -120,11 +120,14 @@ Implement the new API methods and ensure data propagation.
 - **Update Email Constructor**: Ensure the `Email` constructor copies the new field from the builder.
 - **Utility Classes**: Update `MiscUtil` if it contains helper methods for object creation or parsing (e.g., `interpretRecipient`).
 - **Send Results**: Runtime facts belong to the send result, not the reusable Email. Preserve added fields through result enrichment, receipt construction, and serialization/read-resolution. Keep internal assembly out of the application API and use builders instead of adding positional constructor overloads. Review genuinely released construction contracts separately; retaining serialized compatibility does not require retaining unreleased constructors. Test absence behavior within the supported snapshot format. ADR 0031 explicitly supersedes compatibility with the former concrete report classes; keep that migration boundary distinct from the preserved Email/recipient/attachment format.
+- **Interpreted Source Facts**: Facts extracted from a received message belong to its converted Email read model, not outgoing configuration or a live send result. See [ADR 0008](adr/0008-minimal-mime-structures-and-protection-order.md). Use core read contracts and internal assembly; preserve source metadata through copying/governance/serialization without letting templates manufacture it. Do not add setters, EmailProperty entries, defaults, locks, properties or CLI options for read-only facts. Verify the effective outer message after protection processing, exact/protected bytes, attached-message isolation and absence in older snapshots.
 
 ## 4. Message Conversion & Processing (`simple-java-mail`)
 
 Route the new field according to its ownership. Message-content fields affect the produced `MimeMessage`; SMTP-envelope fields belong to `DeliveryEnvelope` and the provider adapter, not MIME headers. Do not change exact or protected MIME bytes to carry transport metadata.
 
+- **Read Tolerantly, Produce Strictly**: Follow [ADR 0035](adr/0035-tolerant-reading-and-strict-production.md) for MIME/EML/Outlook imports and interpreted source facts. Recover unambiguous formatting, preserve usable neighboring facts and source data, and explain incomplete interpretation through existing feature metadata. Do not make an optional interpretation reject an otherwise readable Email. Keep conflicting or genuinely ambiguous facts unavailable; never invent dates, timezones, recipients or delivery results. Required content-read failures retain their causes rather than returning complete-looking truncated content. Add malformed/partial-source regressions alongside valid fixtures, and preserve outgoing validation, exact/protected bytes and cryptographic verification.
+
 - **MimeMessageHelper**: Update this class if the new field translates directly to a standard MimeMessage header or property (e.g., a new recipient type or a standard header).
 - **SpecializedMimeMessageProducer**: Update the `populateMimeMessage` method if the new field requires logic to decide how the `MimeMessage` is constructed or if it triggers module-specific processing (like S/MIME or DKIM).
 - **MIME Structure**: For a new body-part concept, revisit the mixed/related/alternative selector and each affected producer. [ADR 0008](adr/0008-minimal-mime-structures-and-protection-order.md#mime-producer-selection) contains the producer matrix and protection-order contract; retain custom Message-ID behavior across wrappers.
 
@@ -61,6 +61,58 @@ Simple messages stay simple and clients see multipart containers that correspond
 
 Security and conversion must preserve Message-ID and exact protected bytes across repeated serialization. Missing optional modules must not silently downgrade requested outbound protection. On incoming mail, accessible content and unavailable verification/decryption facts remain distinct; successful parsing alone is not evidence of trust. Exact EML bypasses this composition pipeline and uses its own preservation contract.
 
+## Interpreted mail facts remain part of Email (accepted 2026-10-16)
+
+This addendum is implemented under [#763](https://github.com/bbottema/simple-java-mail/issues/763), verified and accepted in production review on 2026-10-18;
+the earlier MIME/protection decisions remain implemented. The independent integration programme is [#764](https://github.com/bbottema/simple-java-mail/issues/764).
+
+### Context and decision drivers
+
+An application already converts MIME/EML into Email to inspect bodies, addresses and protection results. Delivery-status notifications are specialized
+mail content, not a second transport outcome. Exposing their interpreted facts through another converter facade would fragment the gateway without
+changing who owns the content. Turning those facts into workflow transitions, however, requires application-specific persistence, trust and business rules.
+
+### Decision
+
+Enrich the common Email read model with immutable source facts during existing inbound conversion. Apply the established protection-before-interpretation
+order: inspect the effective outer notification, retain authoritative protected/exact bytes and do not promote an attached report into its parent's facts.
+Keep source metadata separate from outgoing configuration, SMTP submission results and application state. Ordinary templates, locks and outbound MIME
+producers must not manufacture source facts. Copies preserve provenance, while new replies/forwards describe their own source rather than their subject.
+
+Core owns the reading contracts; the main conversion implementation owns parsing and assembly. Reuse Jakarta Mail's MIME/header machinery without an
+optional experimental DSN dependency. Missing/unusable facts remain absent; a recognized malformed notification can retain usable facts and warnings.
+[ADR 0035](0035-tolerant-reading-and-strict-production.md) makes the inbound tolerance boundary explicit: recover unambiguous formatting and retain
+completed facts when optional interpretation fails, with warnings. Failure to obtain required content still fails conversion rather than returning
+silently truncated content. Received claims are not authenticated delivery proof or permission to retry.
+
+Use cohesive read types for interpreted values rather than leaving applications to split status strings or keep parallel type/value getters aligned.
+An enhanced status exposes checked numeric components and broad classification while preserving unfamiliar subject/detail combinations. Reported
+addresses, servers and diagnostics retain their extensible format identifiers alongside their values; only recognized usable formats offer optional
+Internet-mailbox or SMTP-response views. Those conveniences must not invent absent names, outgoing preferences or delivery evidence. Their construction
+stays internal to conversion, and automatic rendering excludes reported identities and prose.
+
+### Alternatives considered
+
+- **A parallel delivery-report extractor API:** explicit, but forces callers to select another gateway for facts that belong to the converted Email.
+- **Application-only raw parsing:** avoids library work but duplicates mail-format/protection knowledge across integrations.
+- **An SJM handler registry, dispatcher or durable workflow:** convenient for one example, but makes mail interpretation own application persistence,
+  scheduling, correlation and business state. Teach those integrations instead, using their existing platforms.
+
+### Consequences and boundaries
+
+Specialized interpretation is discoverable through the same Email object, without getter-side I/O or new configuration layers. It does not turn Email
+into a mutable delivery tracker. Callers choose correlation, trust, serialization, logging and downstream action; no missing-report success inference or
+automatic retry follows. Metadata must survive copying and supported serialization without retaining MIME objects or changing wire bytes.
+
+Related: [optional modules](0006-optional-modules.md), [provider-neutral MIME](0007-provider-neutral-mime-boundary.md),
+[DSN identifiers](0022-dsn-identifiers-belong-to-send-attempts.md), [safe retries](0030-safe-bounded-mail-send-retries.md),
+and [public/internal boundaries](0031-public-api-and-internal-construction.md). Acceptance tests and feature contracts belong in the implementation plan,
+not this decision record. Sending ownership, state machines and the shared concurrency infographic's resource layers remain unchanged.
+
 ## Implementation anchors
 
+[DeliveryStatusReportParser](../../modules/simple-java-mail/src/main/java/org/simplejavamail/converter/internal/mimemessage/DeliveryStatusReportParser.java)
+implements interpreted notification facts within the shared MIME pass. [DeliveryStatusReportTest](../../modules/simple-java-mail/src/test/java/org/simplejavamail/converter/DeliveryStatusReportTest.java)
+and the [dated verification record](../research/763-delivery-status-verification.md) cover this extension separately from the historical evidence below.
+
 [MimeMessageProducerHelper](../../modules/simple-java-mail/src/main/java/org/simplejavamail/converter/internal/mimemessage/MimeMessageProducerHelper.java), [SpecializedMimeMessageProducer](../../modules/simple-java-mail/src/main/java/org/simplejavamail/converter/internal/mimemessage/SpecializedMimeMessageProducer.java), [builder validation](../../modules/simple-java-mail/src/main/java/org/simplejavamail/email/internal/EmailPopulatingBuilderImpl.java), and [EmailConverter](../../modules/simple-java-mail/src/main/java/org/simplejavamail/converter/EmailConverter.java) implement these boundaries. [OpenPgpMimeTest](../../modules/simple-java-mail/src/test/java/org/simplejavamail/openpgp/OpenPgpMimeTest.java) and [OpenSSL S/MIME interoperability tests](../../modules/simple-java-mail/src/test/java/org/simplejavamail/internal/smimesupport/OpenSslSmimeInteroperabilityTest.java) are existing verification anchors, not newly executed tests for this record.
@@ -79,4 +79,8 @@ Absence of a receipt must never be interpreted as proof that no message was acce
 
 Recipients and raw server replies can contain personal information and untrusted text; they are not redacted configuration diagnostics. SMTP acceptance is not mailbox delivery. DSNs, bounces and application reconciliation remain separate concerns. Pending ENVID work adds correlation metadata but does not change these meanings.
 
+[ADR 0008's interpreted-source-facts decision](0008-minimal-mime-structures-and-protection-order.md#interpreted-mail-facts-remain-part-of-email-accepted-2026-10-16)
+adds reading of a supplied delivery notification through its converted Email. This is distinct from the original send result: a received report does
+not mutate a receipt, authenticate delivery or authorize automatic replay. Mail retrieval, correlation and business reconciliation remain application-owned.
+
 Existing regression landmarks include [AngusSubmissionResultTest](../../modules/angus-mail-provider-module/src/test/java/org/simplejavamail/internal/mailprovider/angus/AngusSubmissionResultTest.java) and [MailSubmissionReceiptTest](../../modules/simple-java-mail/src/test/java/org/simplejavamail/mailer/MailSubmissionReceiptTest.java). This retrospective documentation pass did not rerun Java tests.
@@ -18,6 +18,9 @@ Keep `Email` as the public message type. `startingFromExactEml(...)` returns a c
 
 Make the input bytes the sole authority for MIME content. The parsed Email getters are an inspection view; they are not the recipe used to reconstruct the message. Internally, `InternalEmail` owns an `EmailSource`: composed sources apply governance and render MIME, while `ExactEmlSource` returns a `FinalizedMimeMessage` from copied bytes and declares `PRESERVE_ALL_BYTES`. Keep this distinction at the source boundary rather than scattering exact/composed checks through every send mode.
 
+[ADR 0035](0035-tolerant-reading-and-strict-production.md) permits recovery in that inspection view without changing authoritative bytes.
+Tolerant reading does not relax this explicit submission mode's validation, content-preservation or transport-safety requirements.
+
 Exact submission bypasses Email defaults/overrides, composed-message validation, embedded-resource resolution and DKIM/S/MIME/OpenPGP transformations. Content that is already final must not silently acquire headers, signatures or encryption. Envelope invariants and the configured maximum byte size still apply. Copying an exact Email through the ordinary composition builder intentionally creates a composed source and relinquishes the preservation contract.
 
 [ADR 0028](0028-per-email-recipient-rejection-handling.md) records the explicit recipient-rejection choice on ExactEmailBuilder under #754.
 
@@ -35,6 +35,10 @@ No configuration property or Spring metadata default is added for a per-send ide
 
 ## Implementation evidence and limits
 
+[ADR 0008's source-facts addendum](0008-minimal-mime-structures-and-protection-order.md#interpreted-mail-facts-remain-part-of-email-accepted-2026-10-16)
+keeps interpretation of a supplied notification on the converted Email. This does not move mail retrieval, trust, correlation or business actions into
+SJM, or turn the original submission receipt into a final-delivery tracker.
+
 [ADR 0030](0030-safe-bounded-mail-send-retries.md) records the retry extension implemented under #756. Generated ENVID
 remains transaction-specific on each replay, while explicitly fixed IDs remain fixed. A stable Message-ID or ENVID is not a server
 deduplication guarantee; retry safety still comes from submission facts.