Summary

  • The 28 October mailmaint working-group draft chooses POSIX pax tar for personal-data exports. It permits a logical export to span several independently readable archive files, including a folder divided between parts.
  • Importers must merge a split folder by its UID and consistent metadata. They must reject unsafe archive entries and must not apply the archive's mode bits, ownership, extended attributes or access-control lists to local files. The draft also warns that access roles inside exported data may be untrusted.

The suitcase has a specification; the border has discretion

The ordinary promise of portability sounds simple: download your account and carry it somewhere else. The proposed archive can contain messages, contacts, events, tasks, notes and attachments. That breadth is useful because a person leaving a service rarely leaves just one type of record. A move that retrieves mail but loses the calendar's meeting attachments or the contact identifiers is a move with a repair bill attached.

Revision 03 gives the package a particular shape. Section 6.4 chooses the POSIX pax interchange format, an extension of tar that can carry internationalized path names and size metadata. Exporters must produce pax archives with regular files and directories only. They may leave the archive uncompressed or use gzip or Zstandard. An importer must accept the first two and should accept Zstandard. These are concrete interoperability choices, not a declaration that every product now supports the format. The Datatracker still lists an Internet-Draft.

Large accounts make the handoff harder. A single folder may be split across archive files. Every part must be independently readable and contain an archive.json; the parts differ in part and final values. Each copy of a split folder's folder.json lists the items in that part while keeping other metadata consistent. The same folder UID is the signal that the fragments belong to one collection. The importer must merge them. If it instead creates two Inbox folders, the user has the bytes but loses the continuity of the mailbox. If it treats one part as the whole, the missing messages can look like a successful migration until somebody searches for them.

The UID is a claim about sameness across the journey. In the draft's one-way synchronization rules, exported JSContact, JSTask and JSCalendar objects carry uid and updated. An importer searches for an existing object with the same UID; a sufficiently similar object should not be rewritten just to give it a new timestamp. The rule attacks a familiar migration pathology: each import looks like a new change, and the receiving system manufactures its own churn. But the phrase “similar enough” leaves interpretation to the receiver. That is a necessary implementation choice with visible consequences for duplicate contacts and calendars.

Permissions stop at the receiving filesystem

The sharpest line is in Section 8.3. Before writing archive contents to a filesystem, an importer must validate entry names, reject absolute paths and parent traversal, and reject entry types other than regular files and directories. It must not apply mode bits, ownership, extended attributes or ACLs from the archive. It creates files under its own defaults. Those commands protect the destination from a hostile or malformed package. They also state who decides local access: the receiving system.

This does not mean the old service's sharing choices are irrelevant. The draft notes that data may contain roles, participation status or shareWith information. It also says source access controls may not transfer reliably, and an importing service must consider whether imported access fields are trustworthy. A user could upload an archive with tampered role data. A calendar invitation's listed participant is not, by itself, permission to grant that participant access to the new service's files. The receiver has to make that decision in its own authority model.

There is a second collision at the filename layer. Two paths can be distinct in the archive and identical when extracted onto a case-insensitive filesystem. Unicode normalization can make the same trouble. The draft requires exporters to try to generate names that survive these differences and tells importers to reject duplicate named items rather than quietly lose one. This is the unglamorous place where a beautiful “your data is yours” promise either becomes an intact mailbox or a support ticket.

The package is powerful enough to deserve suspicion. A whole-account export aggregates private information about people who did not request the transfer: contacts, invitees and correspondents. Section 8 warns about that concentration and about credentials or access tokens escaping through careless serialization. Section 8.3 tells importers to consider decompressed size, entry count and per-entry size. A small compressed file can be a large demand on the new service. Portability expands the amount of data a user can move; it also expands the amount the destination must parse safely.

The previous revision did not yet settle the pax container and split-folder rules that revision 03 now records in its change log. This is a format proposal, not an export button already installed across mail services. It leaves the protocols for requesting and transferring archives to other specifications. That missing protocol matters: a clean file format cannot force a provider to offer a timely, complete export, and it cannot force a destination to accept one.

Sources