Check renamed copies and typed reports

A readable preview is only the first check

A 4-file rename preview can look plausible while a missing byte or colliding target ruins the handoff. A plist string display can look correct while an integer has lost precision or an unused malformed object was skipped. The deliverable must retain the actual source bytes and typed structure.

Evidence for the complete handoff
Task	Full evidence	What the preview cannot prove
Renamed copies	Every entry bytes/CRC/SHA; all source→target rows	In-place filesystem rename
Typed plist	Every object/raw bit/reference + typed root	Apple runtime object interpretation
DMARC observations	All source identities, exact counts, policy/auth/rows and inert XML	Unique messages, report authenticity or live security

Name policies are part of the decision

The user wanted version text before the extension. Keeping only the final extension means archive.tar.gz becomes archive.tar version 1.gz. A dotfile without a later dot is extensionless. Flat selection avoids directory identity guesses; exact duplicate original names and portable target collisions are rejected instead of silently overwriting a copy.

Keep originals and full mapping downloads.
Check every ZIP entry and SHA, not just a filename label.
Choose counter separators explicitly; no guessed naming scheme.

Type preservation is more than conversion

The binary-plist user wanted readable content rather than a conversion-only command. Exact integer strings, raw float bits, UID data and a complete object table make that content auditable. The date preview deliberately rounds to milliseconds; the original fraction or IEEE seconds still exists in the full report. Precision and display are separate recorded fields.

The output policy is strict: bad unused objects fail the file, shared-reference growth is bounded before serialization, and no archived class is instantiated. A refusal identifies a supported-boundary issue; it is not converted to an apparently successful partial report.

Preserve observation identity and counting rules

A report with disposition none can contain failed alignment. A report after a successful delivery is still an aggregate observation record. Keep the receiver flags, raw authentication and disposition separate in the download so the summary can be recomputed rather than used as a guessed delivery verdict.

An exact duplicate report contributes once, with all sources retained. A conflicting report under the same identity refuses the batch instead of overwriting facts. The 19-observation example preserves five unique rows, 14 declared aligned pass and 5 fail; a 26-digit count remains an exact decimal string. The same email may still occur in reports from multiple receivers.

Local parsing preserves complete versioned metadata, every authentication result and the declared foreign XML infoset. Links and extension text stay inert. XML normalization is explicit and original hashes remain available; full CSV/JSON carry the data that a bounded table cannot show.

Check declared alignment separately from none/pass disposition.
Keep source mapping and the full policy/authentication report with the CSV.
Treat missing alignment and unknown core data as explicit incomplete/unsupported refusals, not a successful inferred result.

References

User task: version text before extension
Body read 2026-10-07; version 1 is added to basenames while preserving the extension.
User task: read binary plist values
Body read 2026-10-07; the user needs readable content rather than only an XML conversion step.
Python plistlib typed reading
Technical reader reference; custom low-level validation also retains raw widths, bits, unused objects and references.
User task: failing rows with disposition none
Body read 2026-10-07; the task requires distinguishing declared alignment from disposition without inferring whether an unfamiliar IP belongs to a sender.
User task: understand aggregate reports on successful delivery
Body read 2026-10-07; aggregate observation reports are not failure-only alerts or proof of final delivery.
RFC 7489 legacy aggregate fields
Original schema/semantics read 2026-10-07; the first release explicitly supports namespace-free legacy reports.
RFC 9990 current aggregate schema
May 2026 primary specification read 2026-10-07; dmarc-2.0 namespace, pass disposition and modern cardinalities remain distinct.

Tools in this category

Expand a tool to see its steps, options and supported formats, then open its workspace.

Rename file copies with a complete planAdd a basename prefix, suffix or counter to local copies, preserving the final extension and every original byte in a ZIP.

Choose a flat local batch and an explicit name plan. The tool validates every portable target before making byte-identical copies; the selected originals keep their names and contents.

Steps

Select all original files in the intended counter order.
Choose prefix, suffix and optional counter settings.
Review the complete target policy and bounded preview.
Download ZIP and full JSON/CSV; compare hashes before using the copies.

Available options

Prefix: Enter as needed
Placed before the complete stem.
Suffix: version 1
Placed after the stem, before counter and final extension.
Counter mode: No counter · Append counter after suffix
One consecutive counter in selection order.
Counter start: 1
Unsigned decimal 0–999999999; start plus batch index must remain in range.
Counter minimum width: 0
0–9 digits; only adds leading zeroes, never truncates.

Capabilities and limits

1–1,000 files; 20 MiB each and 80 MiB total. Targets at most 200 UTF-16 units. Prefix and suffix each at most 256 UTF-8 bytes; counter start 0–999999999, width 0–9 and final counter ≤ 999999999. These limits apply together. ZIP/JSON/CSV share a protective 96 MiB allocation guard, dominated by the source limits.
A final dot after the first character separates the preserved extension: a.final.txt→a.final version 1.txt. A leading-dot-only name such as .gitignore and extensionless names keep the complete basename. Counter text follows the suffix immediately; add your own separator in the suffix.
Flat portable targets only: reject paths, control characters, Windows-forbidden punctuation/reserved device names and trailing spaces/dots. Duplicate exact source names or target collisions under NFC + Unicode lowercase + NFC reject the whole batch. No folders, regex execution or in-place filesystem rename. Targets must be well-formed Unicode; source basename ceiling 512 UTF-16 units is additionally protective.
The table previews 200 rows and 2,000 UTF-16 characters per cell. Complete original names, target names, byte counts and SHA256 are in JSON/CSV; CSV cells beginning with formula characters are prefixed with an apostrophe. Invalid input or cancellation produces no partial success archive.

Open Rename file copies with a complete plan →

Typed binary and XML plist inspectorRead all local plist objects and references with exact integer width, signedness, raw float bits and a complete typed JSON report.

Inspect one bplist00 or UTF-8 Apple XML plist without instantiating archived classes. Validate every binary object, including unused ones; preserve a typed root, full object directory, raw references and source SHA256 in the downloadable report.

Steps

Select one local binary or XML plist.
Review root type, validated objects, unused objects and explicit raw-number policy.
Download full typed JSON and inspect all objects/references, not only the bounded preview.

Capabilities and limits

One 8 MiB file; at most 100,000 binary objects or XML elements, 64 nested containers and 200,000 expanded visits per validated object/root. Binary physical references are additionally capped 200,000. All limits apply together; full typed JSON ≤ 32 MiB, checked before shared references are serialized repeatedly.
Supported binary types: null, boolean, ASCII/valid UTF-16BE string, data, array, unique-string-key dict, finite float32/64, date and UID ≤ 8 bytes. Integer 1/2/4 bytes is decoded unsigned; 8/16 bytes signed, retaining decimal string, width, signedness and rawHex. These raw 128-bit values do not promise universal NSObject interpretation; UID is inert numeric data only.
XML 1.0 UTF-8 requires plist version 1.0, recognized declaration and only the standard Apple external doctype; it is never fetched. Unknown attributes, tags, PI, custom DTD/entities and unsupported types fail. XML integers preserve lexical text and decimal value in −2^127…2^128−1; binary width/sign is not inferred. Base64 must have canonical padding bits; dict order is retained.
Dates retain binary seconds/IEEE 64-bit representations or the full XML UTC lexeme YYYY-MM-DDTHH:mm:ss[.fraction]Z, years 0001–9999, no leap seconds. ISO preview rounds original binary seconds or XML fractional seconds to nearest millisecond, ties away from zero, before adding its epoch/date; preview must fit JavaScript ISO date range. Fractional input precision remains in the report.
Reject cycles, truncated/overlapping/duplicate offsets, bad references, unknown unused objects, nonfinite floats and malformed UTF-16. Preview only 200 root-value nodes, 2,000 UTF-16 units per cell; full JSON includes every object and reference. This is read-only parsing, not writeback, NSKeyedArchiver execution or a trust/security verdict.

Open Typed binary and XML plist inspector →

Read DMARC aggregate observationsRead local RUA XML or gzip batches with exact weighted observations, complete declared policy/authentication records and explicit duplicate-report handling.

Inspect received aggregate reports locally. Keep receiver-stated DKIM/SPF alignment separate from raw authentication results and disposition, then download every source mapping, policy, row, authentication result and preserved XML infoset.

Steps

Select received local RUA XML or XML.gz reports.
Compare receiver-stated alignment, raw authentication and disposition; inspect source deduplication.
Download complete JSON/CSV to read every row and the full preserved XML infoset.

Capabilities and limits

Select 1–100 XML or XML.gz files, at most 2 MiB encoded each and 80 MiB encoded total. Expanded XML is limited to 8 MiB per file and 80 MiB per batch; 10,000 total source records before deduplication, 200,000 XML elements and 64 levels. Complete JSON and CSV together are limited to 32 MiB. These limits apply together; source filenames have a protective 512 UTF-16-unit limit.
First release supports namespace-free RFC 7489 legacy reports and RFC 9990 reports in urn:ietf:params:xml:ns:dmarc-2.0, with their separate required fields, ordering, multiplicities and enums. RFC 9990 pass disposition remains distinct from none. Other core fields, namespaces, versions, missing alignment flags or unknown alignment values reject the entire batch explicitly; no inferred pass.
Only UTF-8 XML 1.0 and plain XML or validated gzip are supported; no ZIP input. Every gzip member, including concatenated members, is checked for framing, optional header CRC, full CRC and decoded size. Malformed encoding, DTD, custom entities and processing instructions are rejected. Links and foreign extension content remain inert, without network or DNS requests.
Report identity is organization, contact email, report ID, policy domain and declared begin/end. Identical expanded XML bytes under the same identity collapse once while retaining all source mappings. Different XML bytes with the same identity reject the whole batch, including differences in formatting or comments. Counts retain their original lexical form and exact decimal strings.
The JSON includes all metadata, policy, multiple DKIM/SPF results, reasons, declared foreign extensions in supported slots, and an indexed XML infoset preserving names, attributes, ordered mixed content and comments. XML line endings/entities/attribute values are normalized by parsing, and document-level whitespace outside the root is omitted; source and expanded-XML SHA256 retain byte identity. First release requires foreign namespaces in designated extension slots.
The table previews 200 rows and 2,000 UTF-16 units per cell; downloads contain complete records. Counts are observations across receivers, not unique emails. This reader does not verify DNS, signatures, delivery, compromise, sender ownership or report authenticity, and does not fetch reports. Whole-batch errors or cancellation return no partial successful output.

Open Read DMARC aggregate observations →

Tools used in this article

Rename file copies with a complete plan →Add a basename prefix, suffix or counter to local copies, preserving the final extension and every original byte in a ZIP.Typed binary and XML plist inspector →Read all local plist objects and references with exact integer width, signedness, raw float bits and a complete typed JSON report.Read DMARC aggregate observations →Read local RUA XML or gzip batches with exact weighted observations, complete declared policy/authentication records and explicit duplicate-report handling.