RFC 934

RFC 934 ✨ Proposed Standard for Message Encapsulation

Part 1 of 2 🎀

Okay bestie, here's the vibe check on the title block 💅

• RFC number: 934
• Title: Proposed Standard for Message Encapsulation
• Authors: Marshall T. Rose (Delaware) and Einar A. Stefferud (NMA) 👯
• Working group: Network Working Group
• Date: January 1985 🗓️
• Category: Proposed Standard 🦋

STATUS OF THIS MEMO

Okay so this doc is literally pitching a proposed protocol to the ARPA-Internet community 🌈 and it's begging everyone for discussion and suggestions to make it better 🙏. Anyone can share it too, because distribution is unlimited 💖.

Introduction, Scope, and Motivation

The services that a user agent (UA) can offer are varied ✨. Even though all outgoing mail goes through one single posting slot to connect to the message transport system (MTS), we can think about a message draft being posted in one of these four ways 📮:

• Originate - a new message is composed from scratch, which, to the knowledge of the UA, is unrelated to any message previously handled by the user. Brand new main character moment 🎀.
• Reply - a message is composed as a reply to a message previously received by the user. In most circumstances, the UA helps the user compose the reply by building the header portion of the message draft, using components pulled from the received message headers 💬.
• Forward - one or more messages previously received by the user are formatted by the UA as a part of the body portion of the draft. In this sense, a "digest" for an interest group counts as forwarding 📰. Similarly, an argument can be made that "blind-carbon-copies" should also be handled this way 🙈.
• Distribute - a message previously received by the user is re-posted to the MTS. The draft being re-posted is identical to the original message, except that certain "ReSent-XXX" headers get appended to the headers portion of the draft, and the Return-Path header is reset to reference the re-sender's address 🔁. (See [RFC-821] for a discussion of the Return-Path header.)

Most user agents support the first two of these activities, many support the first three, and a few support all four 👑.

This memo only cares about the third type, which is message forwarding 💅. (For a brief treatment of the semantics of message components with respect to replies, see [RFC-822].) Honestly, forwarding is kind of like encapsulating one or more messages inside another 🪆. This is useful for sending past correspondence to new recipients, but without a decapsulation process (which this memo calls "bursting"), the forwarded messages are kinda useless to the recipients 😭. They can't be distributed, forwarded, replied to, or otherwise processed as separate individual messages.

NOTE: RFC-822 mistakenly refers to distribution as forwarding (section 4.2). This memo suggests below that these two activities can and should be the same.

Digests are where bursting really slays 🔥. A bursting capability lets a digest recipient reply to one individual digested message, and it also lets them selectively process the other messages packed inside the digest 🧚. Like, one digest issue usually has more than one topic, and a subscriber might only care about some of them. With bursting, the subscriber can burst the digest, scan the headers, and process the messages they want, and ignore the rest if they're not feeling it 🫶.

This memo is motivated by three concerns 🌸:

• To burst a message, you need to know how the component messages were encapsulated in the draft. Right now there's no unambiguous standard for interest group digests 😵‍💫. This memo proposes one for the ARPA-Internet. Digests might look like they follow a pseudo-standard, but there's a serious ambiguity in the implementations that produce digests. By proposing this standard, the authors hope to fix this problem by directly addressing that implementation ambiguity 🔧.
• Next, there's a ton of confusion about how UAs should handle "blind-carbon-copies" 🙃. Every agent in the ARPA-Internet that supports a "bcc:" facility seems to do it differently. This memo doesn't propose a standard for generating blind-carbon-copies, but it does introduce a formalism that treats the "bcc:" facility as a special case of forwarding 🦋.
• Finally, forwarding and distribution can both be done with the same forwarding procedure, as long as a distributed message can be extracted as a separate, individually processable message ✨. With a proper bursting agent, it'll be hard to tell apart a message that was distributed from one that was extracted from a forwarded message. This memo argues there's no valuable distinction to be made between forwarding and distribution. In the interests of simplicity, distribution facilities should not be generally available to ordinary users of a message system 🚫. However, this memo also argues that such facilities should be available to certain trusted entities within the MTS 🛡️.

NOTE: this memo does not propose that the distribution facility be abolished. Rather, it argues the case forcefully in the hope that other interested parties in the ARPA-Internet will join this discussion 💜.

Message Encapsulation

This memo proposes the following encapsulation protocol 🎀: two agents act on behalf of the user. One is a forwarding agent, which composes the message draft before it's posted. The other is a bursting agent, which decomposes the message after delivery 📦.

Okay, definitions time 🤓. A draft forwarding message consists of a header portion and a text portion. If the text portion is present, a blank line separates it from the header portion. Inside the text portion, a certain character string sequence, known as an "encapsulation boundary", has special meaning. Right now (in existing digestification agents), an encapsulation boundary (EB) is defined as a line in the message that starts with a dash (decimal code 45, -). At first, there's no restriction on the length of the encapsulation boundary, or on the characters that follow the dash 🌈.

1. The Header Portion

This memo doesn't restrict the header portion of the draft, although it should conform to the RFC-822 standard 📝.

2. The Text Portion

The text of the draft forwarding message has three parts: an initial text section, the encapsulated messages, and the final text section 🧩.

2.1. The Initial Text Section

All text (if any) up to the first EB makes up the initial text section of the draft 🌸. This memo doesn't restrict the format of the initial text section. For a digest, this initial text is usually the "table of contents" 📋.

2.2. The Final Text Section

All text (if any) after the last EB makes up the final text section of the draft 🌙. This memo doesn't restrict its format either. For a digest, the final text usually has the sign-off banner (like "End of FOO Digest") 👋.

2.3. Encapsulated Messages

Each encapsulated message is bounded by two EBs: a pre-EB, which comes before the message, and a post-EB, which comes after it 🎁. For two adjacent encapsulated messages, the post-EB of the first message is also the pre-EB of the second message 🤝. With that in mind, two adjacent EBs with nothing between them should be treated as enclosing a null message, so two or more adjacent EBs are equivalent to one EB 🫧.

Each encapsulated message has two parts: a headers portion and a text portion. If the text portion is present, a blank line separates it from the header portion 💌.

2.3.1. The Header Portion

Minimally, there must be two header items in each message being forwarded: a Date: field and a From: field 📅. This is different from RFC-822, which requires at least one destination address (in a To: or cc: field) or a possibly empty Bcc: field 🙄. Any addresses in the header items for a message being forwarded must be fully qualified 🔍.

2.3.2. The Text Portion

This memo doesn't restrict the format of the text portion of each encapsulated message 💖. (Actually, it does restrict the format of that text portion, but those restrictions get discussed later 👀.)

Before summarizing the generation and parsing rules for message encapsulation, two issues need to be addressed 🧁.

Compatibility with Existing User Agents

The encapsulation protocol above is already used by lots of user agents in the ARPA-Internet 🌐. It was specifically designed to minimize changes to existing implementations of forwarding agents in the ARPA-Internet 🛠️.

Still, the protocol isn't exactly like the pseudo-standard used by the forwarding agents that compose digests 😬. Specifically, the post-EB of every message encapsulated in a digest is preceded and followed by a blank line. Also, the first message encapsulated in a digest has a pre-EB that's followed by a blank line, but it usually isn't preceded by one (wonderful 🙃).

This memo recommends that implementors of forwarding agents who want to stay compatible with existing bursting agents consider surrounding each EB with a blank line 🫶. It should be noted that blank lines following a pre-EB for an encapsulated message must be ignored by bursting agents. This memo also suggests that blank lines preceding a post-EB be ignored by bursting agents too 🌷.

NOTE: This recommendation is made in the interest of backwards-compatibility. A forwarding agent wishing to strictly adhere to this memo should not generate blank lines surrounding EBs 💅.

Okay so this is the second half of RFC 934, and it's where the actual stuffing rules get wild 💅✨

Blind Carbon Copies 🙈

Blind Carbon Copies

Okay so bestie, here's the thing about blind carbon copies (BCCs) 🫶. Lots of user agents have this facility, and the whole idea is that a draft has two kinds of addressees: visible recipients and blind recipients. The visible ones show up in the "To:" and "cc:" fields, and the blind ones are in the "Bcc:" fields. The magic is that copies delivered to the recipients only list the visible people, so the blind ones stay hidden 🦋

Now there's a method where you post one draft with no "Bcc:" fields and then, while posting, you talk to the MTS so copies go to both the visible and blind recipients. Cute, but there's a big problem 😭 If the blind recipients hit reply, they can accidentally include the visible recipients as addressees in the reply. Socially unacceptable, literally a disaster 💀 So the message the visible people get has to be different from the message the blind people get.

Another method is to post two drafts. The first goes to the visible recipients and is just the draft without any "Bcc:" fields. The second goes to the blind recipients and is the draft with some string stuck in front of any "To:" and "cc:" field. For example, the user agent might prepend "BCC-" so the blind folks get "BCC-To:" and "Bcc-cc:" fields and no "To:" or "cc:" fields. Accidental replies can't happen with this one, but ngl it's super confusing for the blind recipients, because it's hard to tell the draft they got came from a blind carbon copy 🌀

The method this memo suggests is posting two drafts too: a visible draft for the visible recipients, and a blind draft for the blind recipients. The visible draft is the original without any "Bcc:" fields. The blind draft holds the visible message as a forwarded message 🎀 Its headers have the minimal RFC-822 headers, and if the original had a "Subject:" field, that gets included too. The user agent might also make it clear the blind draft came from a blind carbon copy, either with a "Bcc" header or before the first encapsulating boundary in the body 🌸

Message Distribution 🌈

Message Distribution

Message distribution, which people also call redistribution or resending, is all about giving a secondary recipient, maybe someone who wasn't in the original addressees, a "true original" copy they can treat like an original in every respect ✨

This happens most often with discussion group moderators who use automated agents to just repost received messages to a distribution list. The better distribution agents add a new "Return-Path" header field so failure notices go to the discussion group's list maintainer instead of the original author 🧚 This kind of distribution is encouraged, because it delivers messages to group recipients as processable originals. It's done by trusted pseudo-MTS agents 💜

The second kind is when individuals want to send a processable copy of a received message to someone else. This one is discouraged in some newer message transfer standards, including the NBS Standard for Mail Interchange [FIPS-98] and the recent CCITT draft MHS (Mail Handling Systems) X.400 standards [X.400]. Instead of directly reposting received messages like they're brand-new drafts, the recommendation is to forward the received message in the body of a new draft, so the secondary recipient can extract it and process it further 🦋

That's the reason this standard for encapsulation/decapsulation exists 💖

References 📚

References

[RFC-822] D.H. Crocker. "Standard for the Format of ARPA-Internet Text Messages", University of Delaware. (August, 1982)

[RFC-821] J.B. Postel. "Simple Mail Transfer Protocol", USC/Information Sciences Institute. (August, 1982).

[FIPS-98] National Bureau of Standards. "Specification for Message Format for Computer Based Message Systems." (January, 1983).

[X.400] Consultative Committee on International Telephone and Telegraph. "DRAFT Recommendation X.400. Message Handling Systems: System Model-Service Elements."

Authors' Addresses 💌

Authors' Addresses

Marshall T. Rose

Department of Computer and Information Sciences University of Delaware Newark, DE 19716

MRose@UDel.ARPA

Einar A. Stefferud

Network Management Associates, Inc. 17301 Drey Lane Huntington Beach, CA 92647

Stef@UCI.ARPA