Summary

  • RFC 1505 put an ordered description of message parts and decoding steps in an elective mail header. A correct parse could identify what transformations to attempt; it could not prove that the result was safe, trusted or authorized.
  • The same format could describe a shell archive or carry file-system owner, group, ACL, password and application attributes. The specification warned against automatic SHAR execution and left the decision to apply protections to the application domain controlling the decoder.
  • Line counts, a decoded byte count and CRC, a registered keyword and even the word Signature were different kinds of evidence. None alone joined sender authority, local policy, realized execution and observed effect.

The command waited after the successful decode

Imagine a mail reader in 1993 receiving a part marked SHAR. It counts the lines assigned to the part, removes the textual wrapping and exposes a shell archive. Every format-level check may succeed. That is not the end of the procedure. It is the beginning of a different decision.

RFC 1505 said use of shar was supported but not recommended. Its warning was unusually direct: a shell archive might contain commands the recipient would not want executed, so a decoder should not run the decoded statements automatically. The warning also applied to future formats containing commands for the receiving machine.

The distinction is easy to blur because decoding feels like one continuous action. In fact, several authorities are involved. The message author may describe a representation. A registry may stabilize the name of that representation. A decoder may know how to reverse it. A local application or user decides whether the resulting program may act. The operating system records what was actually created or executed. A later observation shows whether the intended service changed.

RFC 1505 could coordinate the first three layers. It explicitly stopped short of collapsing them into the fourth.

An experimental header beside a standards-track alternative

Albert Costanzo, David Robinson and Robert Ullmann published RFC 1505 in August 1993. It was Experimental, not an Internet Standard, and replaced their earlier RFC 1154. An IESG note on its first page pointed out that standards-track technology already existed in this area: RFC 1341, MIME.

That contemporary note prevents a simple succession story. RFC 1505 was not an early draft that naturally became today's MIME. It was a competing experimental approach documented while MIME already existed on the standards track. Later MIME specifications, including RFC 2045, revised the MIME lineage through RFCs 1521, 1522 and 1590. They did not retroactively make every RFC 1505 choice part of the MIME contract.

The experiment nevertheless preserves a valuable design question. How much structure can a message declare in a compact header while remaining readable to older software and surviving heterogeneous mail systems? RFC 1505 answered by keeping its structural description in an Encoding field and leaving the body free of repeated wrapper syntax.

The header was a map of parts and transforms

RFC 822 had defined a message header followed by a body, separated by a blank line. RFC 1505 let the body contain one or more parts, also separated by blank lines. The Encoding field listed the parts in their order of appearance. Each entry could begin with a decimal count of text lines and continue with one or more keywords.

The count did not include the blank separator on either side. A blank line meant CRLF alone. The last or only part could omit its count. These small rules mattered because the receiving program used the header to find a boundary that was otherwise visually indistinguishable from an ordinary empty line.

Nested keywords described several transformations or a more precise type. Their order was significant. A decoder worked from left to right, while an encoder wrote the names in the reverse order from the transformations it had performed. uuencode LZW tar, for example, was not a bag of capabilities; it was an ordered recovery path.

Comments were different. Parenthetical comments could appear in the field and be handed to clients, but readers were told not to use them for content interpretation. RFC 1505 therefore distinguished machine-relevant tokens from explanatory prose inside the same header. A visible note could help a human without acquiring control over the parser.

“Signature” did not always mean cryptographic proof

The vocabulary carried another trap. RFC 1505's Signature keyword identified an ordinary signature area at the end of a mail or news message. It might contain the sender's name or a favourite saying. The keyword had to be nested after another type, such as Text Signature.

PEM, PEM-Clear and PGP were separate keywords. Their internal formats could carry encryption, integrity checks, public-key material or detached signatures. Even there, the outer word did not finish the trust decision. A PGP example could tell a decoder what program understood the block. Verification still required the relevant bytes, key material, algorithm result and a local judgment about the key and asserted name.

RFC 1505 also observed that a nested type after PGP could remain visible and reveal whether protected content was text or an EDI transaction. Successful encryption did not erase every traffic-analysis signal. One header could therefore carry claims about format, transform and presentation while leaving confidentiality, authentication and trust to different evidence.

This is why dashboards should not compress all of them into a green “signed” badge. An ordinary sign-off, a cryptographic object, a valid mathematical check and an authorized sender are not four spellings of one fact.

A file arrived with another system's permissions

The most ambitious portion of RFC 1505 was not the line-count header. Its FS encoding tried to carry structured file-system material between unlike operating systems. Directories could contain files, entries and further directories. Files could contain data or nested segments, including the two forks associated with Macintosh files.

The representation could carry a display name, comment, type, creation time, modification time, access time, owner, group, access-control list, password, block size, record size and creating application. This was more than moving bytes. It was an attempt to preserve the administrative surroundings of the bytes.

Those surroundings did not have universal meaning. A numerical owner from one computer might designate an unrelated account on another. $GROUP or $SYSTEM described a source-side role, not necessarily a receiving principal. Access letters for read, write, execute, delete or change-protection required a local enforcement model. Even time could lose precision: RFC 1505 told a decoder to disregard precision beyond what its own file system could store.

The decoder thus performed a projection. It could reproduce some facts, approximate others and reject or ignore those with no local equivalent. The received ACL was evidence of how the sender described protection. It was not a grant from the receiving administrator.

The plaintext password exposed the control boundary

RFC 1505 allowed a password attribute containing the access password for the encoded item. It reasoned that the item's content followed anyway, so the password's appearance in clear text was not itself treated as a separate security problem. The more important sentence came next: if a decoder actually set that password on a created item, the resulting security or insecurity belonged to the application domain controlling the decoder, as did ACL and other protections.

That sentence prevents a dangerous inference. A sender can supply a string called a password. It cannot, through the name alone, decide that the string will become a local secret, overwrite an existing protection, create an account equivalence or satisfy the recipient's current policy.

A safe receiving path would preserve the source claim, map it into a local proposal, show any loss of meaning and record the local decision. Copying protection invisibly is not fidelity when the source and destination protection models differ. It is silent reassignment of authority.

Counts and CRCs proved narrower things

RFC 1505's LZJU90 encoding combined compression with a printable alphabet chosen to survive transformations such as ASCII-to-EBCDIC conversion. Its output ended with the original byte count and a CRC. A decoder was expected to compare them with the byte count and CRC it obtained during decompression.

That check was useful. It could show that an output differed from the encoded sender-side bytes or that decompression had gone wrong. The line count in the message header proved something else: how many encoded text lines belonged to a part. Neither check authenticated the person who sent the message. Neither proved that a keyword had been assigned honestly. Neither authorized a command or imported ACL.

The correct evidence model kept the receipts separate:

  • header parse: which line range and ordered keywords were declared;
  • transform receipt: which decoder and version produced which bytes;
  • integrity receipt: whether length, CRC or cryptographic check matched its defined input;
  • provenance receipt: which message, sender claim and transport path supplied the material;
  • policy receipt: which local rule or person allowed creation, permission mapping or execution;
  • effect receipt: which file, process or service state actually changed.

If one receipt is missing, a later system should display the gap rather than promote the nearest available green check.

Registration named a method; it did not certify an outcome

RFC 1505 asked IANA to register new non-private keywords and permanently reserved X- names for implementation-specific use. Registration could reduce collisions: two implementers were more likely to use the same name for the same documented encoding.

It did not make every decoder support the method. It did not certify that a particular implementation was memory-safe, that the supplied bytes matched the label, that external references remained available, or that active content should run. The registry coordinated vocabulary. Running code and local policy supplied different receipts.

This is the durable lesson of the document's experimental branch. Interoperability improves when names and order are shared. Safety improves when those shared descriptions are not mistaken for commands.

What the sources do not establish

The retained RFCs establish formats, status, warnings and documented lineage. They do not show how many systems implemented RFC 1505, whether any named mailer decoded its FS or SHAR formats, whether anyone received a malicious archive, or whether a password or ACL was ever installed from a message.

RFC 1341 and RFC 2045 document MIME's standards-track development; they do not prove that MIME formally obsoleted RFC 1505. RFC publication does not prove running code. A checksum match does not prove authorship. A registered keyword does not prove safe behavior. A received permission list does not create local principals.

The historical artifact matters precisely because it states where its descriptive ambition ended. A header could tell a machine how to open a package. It could not decide what the opened package was allowed to do.

Sources