Define three different kinds of incompleteness
An incomplete collection may mean that expected reports never arrived, that an individual file is truncated, or that a well-formed report lacks the observations needed for a particular conclusion. Those are different conditions. A parser cannot recover absent sender observations by accepting damaged XML, and a valid document does not establish that every receiver reported all relevant traffic.
Begin by naming the level being assessed: transport receipt, artifact integrity, syntax and schema, field consistency, provenance or population coverage. Preserve the report identifier, reporting interval and ingestion context where available. Do not present a generic “invalid report” count as if it explains which layer failed. RFC 9990 separates report generation, delivery and evaluation, providing the basis for a layered review rather than one binary health score. RFC 9990, section 3.1, 3.5 and 9
Treat the parser boundary as security-sensitive
Aggregate report files are untrusted input. RFC 9990 specifically describes resource-exhaustion attacks against archive decompressors and XML parsers, including compressed and XML bombs. A report that arrives through an expected mailbox or references a known domain does not become safe to process without limits. External reporting permission concerns the receiving relationship, not the harmlessness of arbitrary file contents.
A proposed parser design should impose bounds before expensive work: message and attachment size, decompressed bytes, compression ratio where useful, nesting or element counts, processing time and queued work. It should disable dangerous XML features such as unnecessary external entity resolution and avoid fetching remote resources merely because a document names them. These are defensive design recommendations, not assertions that a particular parser or EmailAuth feature has been configured. RFC 9990, section 8.1
Validate structure without silently rewriting evidence
Preserve the original artifact or an appropriately access-controlled evidence copy before transformations, subject to a defined retention decision. Identify the media type, compression handling, document format and schema version. RFC 9990 defines aggregate XML structure and extension handling. A parser should distinguish a supported extension from malformed structure, and should not silently coerce arbitrary input into a trusted report simply because some familiar element names appear.
Record errors at a useful level of precision without leaking sensitive content into general logs. A truncated document, wrong root structure and unsupported format should have distinguishable reasons. If an implementation offers partial extraction, its output must remain clearly marked incomplete and unsuitable for claims that require the missing fields. Do not discard the failure state while retaining attractive-looking counts. RFC 9990, section 5 and Appendix A
Check consistency and provenance after parsing
Syntactic success does not prove truthful content. RFC 9990 warns that report data can be forged to influence policy decisions or overload report receiving systems. Preserve the sender and transport context available to the collection system, and keep the reporting organization’s asserted identity separate from evidence that authenticates it. A report’s XML claims alone should not create customer ownership or change an enforcement policy.
Proposed semantic checks should examine reporting interval order, field types and ranges, count interpretation, policy context and relationships between evaluated results and authentication details. Differences may arise from policy changes during a reporting period or different observation contexts, so an inconsistency deserves classification before an accusation of forgery. Duplicate or overlapping reports also need a documented handling strategy rather than blind addition to totals. RFC 9990, section 3.3 and 8.2
Design a safe fixture suite before implementation claims
The acceptance plan should include a valid minimal report, a supported-extension case, a truncated artifact, malformed XML, a wrong-type field, a contradictory interval, a duplicate report and a resource-exhaustion candidate. Use inert, bounded local fixtures whose sizes and expected outcomes are declared. This manuscript does not supply executable malicious payloads or claim that any test has run.
For each fixture, record its identifier, hash, intended format, compressed and expanded size assumptions, resource budget, expected classification and recovery action. The expected result should distinguish reject, quarantine, safely accept or accept with an explicit limitation. A test that merely avoids a crash does not demonstrate that the input cannot contaminate aggregate statistics or cross tenant boundaries.
Keep recovery behavior in the same acceptance table. After rejecting one artifact, the worker should release resources, preserve a bounded diagnostic record and continue processing unrelated valid work under the proposed design. The actual implementation must demonstrate that behavior. A fixture suite without resource measurements or recovery evidence is an incomplete security evaluation, even if its test names sound comprehensive.
Fictional diagnosis: a truncated file and a plausible duplicate
Imagine a fictional daily collection containing one valid aggregate document, a second attachment truncated during transfer and a third file repeating an earlier report identifier and interval with different counts. No reports were uploaded or parsed for this example. The proposed workflow first isolates the truncated artifact as a structural failure rather than interpreting its surviving elements as complete daily coverage.
The conflicting duplicate receives a separate consistency and provenance review. It may represent a corrected report, a delivery duplicate with altered content, or false data; the file alone does not settle that question. The collector should preserve the relationship and avoid silently summing both versions into a trend chart. Any reconciliation decision needs a recorded rationale and scope.
The valid report remains eligible for normal processing under the proposed controls, but the dashboard should disclose that collection quality for the interval is incomplete. It should not display the absence of parsed failures from the truncated artifact as evidence that authentication improved. This distinction protects analytical conclusions without turning every damaged file into an unsupported allegation about the reporting organization.
Retention, failure reports and release status
Choose retention according to diagnostic need, privacy obligations and authorized access, rather than inventing a universal number of days. RFC 9990 leaves post-processing storage decisions to the evaluator. Keep raw artifacts, normalized records and error logs under separately justified access and retention rules. A proposed cleanup process must not be described as already deleting data or satisfying a legal requirement.
Failure reports are a separate format and privacy surface under RFC 9991. Do not feed them into an aggregate-only parser or assume that their more detailed content can be shared wherever aggregate summaries are permitted. Route unsupported report types to a clear, bounded handling path and obtain the necessary data-sharing decisions before real processing. RFC 9990, section 9.3; RFC 9991, section 4 and 7
The catalogue requires a malicious-and-malformed fixture suite with resource limits, expected results and recovery behavior. That suite and its execution remain open. This draft provides only a design framework and fictional diagnosis. Original evidence, human review, source applicability, production routes, visual accessibility and owner release remain open. No actual report, parser execution, external upload or production data-retention operation was performed.