RFC 1343

RFC 1343: A User Agent Configuration Mechanism For Multimedia Mail Format Information 💌

• RFC number: 1343
• Title: A User Agent Configuration Mechanism For Multimedia Mail Format Information
• Author: N. Borenstein, Bellcore
• Group: Network Working Group
• Date: June 1992
• Category: Informational (it's an informational memo)
• Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates

---

Status of This Memo 📝

Okay bestie, first things first 💅 this is an informational memo for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶. It does not specify an Internet standard, so it's not a rulebook, it's more of a vibe check with receipts. Distribution is unlimited, so share away 🦋.

Abstract ✨

So this memo suggests a file format 📄 that lots of mail reading user agent programs can use to learn about the mail-handling stuff installed locally for different formats 🧚. It's explicitly designed to work with mail systems based on Internet mail as defined by RFC's 821, 822, 934, 1049, 1113, and the Multipurpose Internet Mail Extensions, known as MIME 💌. With some extensions it could probably work for X.400-based mail systems too 👀.

The format and mechanism are proposed to be generally operating-system independent. However, certain implementation details will inevitably reflect operating system differences, and some of those will have to be handled in a uniform manner for each operating system 🖥️. This memo makes those situations explicit, and in an appendix it suggests a standard behavior under the UNIX operating system 🍓.

Introduction 🌷

The electronic mail world is in the middle of a whole glow-up 💖, going from single-part text-only mail to multi-part, multi-media mail. To support that, extensions to RFC 821 and RFC 822 have been proposed and/or adopted, most notably MIME [RFC-1341]. Lots of parties have shown off super high-functionality multimedia mail 🤩, but mail interchange between different user agents has been a huge mess 💀. Generally, only text messages have been shared between user agents that weren't explicitly designed to work together. That limitation is not compatible with a smooth transition to a multi-media mail world, and that's a problem 😭.

One approach to this transition is to modify a bunch of different mail reading user agents so that, when they hit mail of an unfamiliar (non-text) type, they check an external file for info on how to display it ✨. That file might say, for example, that if the content-type of a message is foo, it can be displayed to the user via the displayfoo program 🎀.

This approach means that, with a one-time modification, a wide variety of mail reading programs can get the power to display a wide variety of message types 🧚‍♀️. Extending the set of media types at a site becomes a simple matter of installing a binary and adding a single line to a configuration file 💅. The crucial part is that all of the user agents agree on a common representation and source for that configuration file 👑, and this memo proposes exactly that.

Location of Configuration Information 🗺️

Each user agent MUST clearly get its configuration info from a common location, if the same info is going to configure all the user agents 🫶. But individual users SHOULD be able to override or augment a site's configuration, because main character energy 👑. So the configuration info SHOULD therefore be pulled from a designated set of locations 🌈.

The overall configuration comes from the virtual concatenation of several individual configuration files, known as mailcap files 🎀. The info comes from the FIRST matching entry in a mailcap file. "Matching" depends on a matching content-type specification, an entry with enough info for the app doing the searching, and the success of any test in the test= field, if there is one 🔥.

The precise location of the mailcap files is operating-system dependent. A standard location for UNIX is specified in Appendix A 🍓.

Overall Format of a Mailcap File 📜

Each mailcap file is a set of entries that describe how to properly handle one media type at the local site 💖. For example, one line might tell you how to display a message in Group III fax format 📠. A mailcap file is a sequence of these individual entries, separated by newlines (according to the operating system's newline conventions). Blank lines and lines that start with the # character (ASCII 35) are comments, and they get ignored 🙈.

Long entries MAY be continued on multiple lines, as long as each non-terminal line ends with a backslash character ('\', ASCII 92). Those lines then get treated as one mailcap entry 🧵. Note that for these "continued" lines, the backslash MUST be the last character on the line to be continued 🚨.

Thus the overall format of a mailcap file is given, in the modified BNF of RFC 822, as:

                 Mailcap-File = *Mailcap-Line

                 Mailcap-Line = Comment / Mailcap-Entry

                 Comment = NEWLINE  /  "#" *CHAR NEWLINE

                 NEWLINE = <newline as defined by OS convention>

Note that the above specification implies that comments MUST appear on lines all to themselves, with a # character as the first character on each comment line 💅.

Format of a Mailcap Entry 💌

Each mailcap entry is made up of a bunch of fields, separated by semi-colons. The first two fields are REQUIRED, and they MUST occur in the specified order 🔒. The remaining fields are OPTIONAL and MAY appear in any order ✨.

The first field is the content-type, which says what type of data this mailcap entry describes how to handle 🎀. It gets matched against the type/subtype specification in the Content-Type header field of an Internet mail message. If the subtype is specified as *, it's meant to match all subtypes of the named content-type 🌸.

The second field, view-command, is a spec for how the message or body part can be viewed at the local site 👀. The syntax is fully specified, but the semantics of program execution are kinda operating-system dependent 😵‍💫. UNIX semantics are in Appendix A.

The OPTIONAL fields, which MAY be given in any order, go like this 💅:

• compose 🎨: The compose field MAY be used to specify a program that can compose a new body or body part in the given format. It's for mail composing agents that support composing multiple types of mail using external composing agents. Like the view-command, the semantics of program execution are operating system dependent, with UNIX semantics in Appendix A 🍓. The result of the composing program MAY be data that isn't suitable for mail transport yet, which means a Content-Transfer-Encoding MAY need to be applied to the data 📮.
• composetyped 🧶: This is similar to compose, but it's for when the composing program needs to specify the Content-type header field to be applied to the composed data 📝. compose is simpler and is preferred for existing (non-mail-oriented) programs that compose data in a given format 🫶. composetyped is necessary when the Content-type information MUST include auxiliary parameters, and then the composition program MUST know enough about mail formats to produce output that includes the mail type information 🤓.
• edit ✏️: This field MAY be used to specify a program that can edit a body or body part in the given format 🖊️. In many cases it MAY be identical in content to the compose field, and it shares the operating-system dependent semantics for program execution 💭.
• print 🖨️: This field MAY be used to specify a program that can print a message or body part in the given format 📄. As with the view-command, the semantics of program execution are operating system dependent, with UNIX semantics in Appendix A 🍓.
• test 🧪: This field MAY be used to test some external condition (like the machine architecture, or the window system in use) to figure out whether or not the mailcap line applies 🔍. It specifies a program to run to test that condition. The semantics of execution, and of the value the test program returns, are operating system dependent, with UNIX semantics in Appendix A 🌈. If the test fails, a subsequent mailcap entry SHOULD be sought 🏃‍♀️. Multiple test fields are not permitted, because a test can call a program, so it can already be arbitrarily complex 🙅‍♀️.
• needsterminal 💻: This field indicates that the view-command MUST be run on an interactive terminal 🖥️. It's needed to tell window-oriented user agents that an interactive terminal is needed. (The decision isn't left exclusively to the view-command, because in some circumstances it MAY not be possible for such programs to tell whether or not they are on interactive terminals 🤷‍♀️.) The needsterminal command SHOULD be assumed to apply to the compose and edit commands too, if they exist 🙌. Note that this is NOT a test. It's a requirement for the environment the program will run in, and it SHOULD typically cause the creation of a terminal window when not executed on either a real terminal or a terminal window 🪟.
• copiousoutput 📜: This field indicates that the output from the view-command will be an extended stream of output. It's basically advice to the UA (User Agent mail-reading program) that the output SHOULD be either paged or made scrollable 📖. Note that it's probably a mistake if needsterminal and copiousoutput are both specified 🙈.

Okay so the "description" field is the cutest little label 💖 It's just a textual description, quotes optional, that mail readers can use to describe the data before they offer to display it. Totally up to the reader whether they bother 🎀

• The description field simply provides a textual description, optionally quoted, that describes the type of data. Mail readers may use it to describe the data before offering to display it.
• The x11-bitmap field names a file in X11 bitmap (xbm) format, which points to an appropriate icon to visually denote the presence of this kind of data 🦋
• Any other fields beginning with x- may be included for local or mailer-specific extensions ✨ Implementations should simply ignore all such unrecognized fields so those extensions can exist, and some of them might get standardized in a future version of this document 🌈

Some of the fields above, like needsterminal, apply to the actions of the view-command, edit-command, and compose-command alike. Ngl, that's not always what you want 💀 But you can split things up with separate mailcap entries, because subsequent mailcap entries get searched if an earlier one doesn't give enough info:

application/postscript; ps-to-terminal %s; \
    needsterminal
application/postscript; ps-to-terminal %s; \
    compose=idraw %s

In RFC 822 modified BNF, the grammar for a mailcap entry looks like this 🧚

Mailcap-Entry = typefield ; view-command
                    [";" 1#field]

typefield = propertype / implicit-wild

propertype = type "/" wildsubtype

implicitwild = type

wildsubtype = subtype / "*"

view-command = mtext

mtext = *mchar

mchar = schar / qchar

schar = * <any CHAR except
           ";", "\", and CTLS>

qchar = "\" CHAR ; may quote any char

field = flag / namedfield

namedfield = fieldname "=" mtext

flag = "needsterminal"   ; All these literals are to
     / "copiousoutput"   ; be interpreted as
     / x-token           ; case-insensitive

fieldname =    / "compose"      ;Also all of these
               / "composetyped" ;are case-insensitive.
               / "print"
               / "edit"
               / "test"
               / "x11-bitmap"
               / "description"
               / x-token

Note that "type", "subtype", and "x-token" are defined in MIME. Also, while the definition of "schar" includes the percent sign, "%", this character has a special meaning in at least the UNIX semantics, so it has to be quoted as a qchar if you want to use it literally.

⚠️ bestie, the percent sign is sneaky. If you want a literal %, quote it as a qchar or it'll get interpreted as something else 💅

---

Appendix A: Implementation Details for UNIX 🍓

Okay, so this memo fully specifies a syntax for "mailcap" files, but the semantics of a mailcap file are operating-system dependent in four respects, and that's just how it is 🫶 To make the intent clear and encourage standard usage, this appendix proposes UNIX semantics for those four cases. If a mailcap mechanism gets implemented on non-UNIX systems, similar semantic decisions should be made and published ✨

Location of the Mailcap File(s)

For UNIX, a path search of mailcap files is specified. The default path search is specified as including at least the following:

$HOME/.mailcap:/etc/mailcap:/usr/etc/mailcap:/usr/local/etc/mailcap

However, this path can itself be overridden by a path specified by the MAILCAPS environment variable 🌸

Semantics of executable commands

Several parts of a mailcap entry specify commands to be executed. The mandatory second field, the view-command, takes a command to be executed, and so do the optional print, edit, test, and compose fields 💖

On a UNIX system, each of these commands is a full shell command line, including the path name for a program and its arguments. Shells differ from each other, and the same shell can behave differently from one system to another, so it's specified that the command line is intended as input to the Bourne shell. In other words, it's implicitly preceded by /bin/sh -c on the command line 🦋

The two characters %s, if used, get replaced by the name of a file for the actual mail body data. For the edit and view-command, the body part is passed to the command as standard input, unless one or more instances of %s appear in the view-command. In that case, %s gets replaced by the name of a file containing the body part, and that file may have to be created before the view-command program runs. Those files can't be presumed to keep existing after the view-command program exits, so a view-command that wants to exit and keep going in the background should take care to save the data first 🫠

For the compose and composetyped commands, %s gets replaced by the name of a file where the composing programs should write the composed data. The calling program then looks in that file later to retrieve it. If %s doesn't appear in the compose or composetyped commands, the composed data is assumed to be written by the composing programs to standard output 💅

Furthermore, any occurrence of %t gets replaced by the content-type and subtype specification. For example, if the content-type is text/plain, then %t becomes text/plain 🎀 A literal % character can be quoted as \%. Finally, named parameters from the Content-type field can be placed in the command execution line using %{ followed by the parameter name and a closing } character. The whole parameter should show up as a single command line argument, even if it has embedded spaces 🌈

Here's the vibe. If the message has a Content-type line of:

Content-type:  multipart/mixed; boundary=42

and the mailcap file has a line of:

multipart/*; /usr/local/bin/showmulti \
  %t %{boundary}

then the equivalent of the following command should be executed:

/usr/local/bin/showmulti multipart/mixed 42

Semantics of the "test" field

The "test" field specifies a program that's used to test whether or not the current mailcap line applies. This is handy if you want a mailcap line that only applies when the X window system is running, or when the user is on a SPARCstation with a /dev/audio 👑 The value of the "test" field is the program to run to check that condition. The precise program and its arguments are determined as specified in the previous section. The test program should return an exit code of zero if the condition is true, and a non-zero code otherwise 🧚

Semantics of the "compose" field

On UNIX, the composing program is expected to produce a data stream for such a body part as its standard output. The program is executed with the command line arguments determined as specified above. The data returned via its standard output gets a Content-Type field that has no supplementary parameters. For example, this mailcap entry:

audio/basic; /usr/local/bin/showaudio %t
 compose = /usr/local/bin/recordaudio

would result in tagging the data composed by the "recordaudio" program as:

Content-Type: audio/basic

If that's unacceptable (for example, with multipart mail, where a "boundary" parameter is required), then the "compose" field can't be used. Instead, the "composetyped" field should be used in the mailcap file 😭

Semantics of the "composetyped" field

The "composetyped" field is much like the "compose" field, except that it names a composition program that produces, not raw data, but data that includes a MIME-conformant type specification 🦋 The program is executed with the command line arguments determined as specified above. The data returned via its standard output must begin with a Content-Type header, followed optionally by other Content-* headers, and then by a blank line and the data. For example, this mailcap entry:

multipart/mixed; /usr/local/bin/showmulti %t \
  %{boundary}; \
  composetyped = /usr/local/bin/makemulti

would result in executing the "makemulti" program, which is expected to begin its output with a line of the form:

Content-Type: multipart/mixed; boundary=foobar

Note that a composition program doesn't need to encode binary data in base64 or quoted-printable. It remains the responsibility of the software calling the composition program to encode such data as necessary. However, if a composing program does encode data (which isn't encouraged), it should announce that fact using a Content-Transfer-Encoding header, in the standard manner defined by MIME. Because such encodings must be announced by such a header, they're an option only for composetyped programs, not for compose programs 💜

Appendix B: Sample Mailcap File ✨

okay so this one is the cutest bit because it's literally a real example mailcap file for UNIX 🐚💖 it's the one that shows off most of the syntax we've been talking about, and it has little comments explaining each line so you don't have to guess what's happening 🧚

# Mailcap file for Bellcore lab 214.
#
# The next line sends "richtext" to the richtext
program
text/richtext; richtext %s; copiousoutput
#
# Next, basic u-law audio
audio/*; showaudio; test=/usr/local/bin/hasaudio
#
# Next, use the xview program to handle several image
formats
image/*; xview %s; test=/usr/local/bin/RunningX
#
# The ATOMICMAIL interpreter uses curses, so needs a
terminal
application/atomicmail; /usr/local/bin/atomicmail %s; \
    needsterminal
#
# The next line handles Andrew format,
#   if ez and ezview are installed
x-be2; /usr/andrew/bin/ezview %s; \
   print=/usr/andrew/bin/ezprint %s ; \
   compose=/usr/andrew/bin/ez -d %s \;
   edit=/usr/andrew/bin/ez -d %s; \;
   copiousoutput
#
# The next silly example demonstrates the use of
quoting
application/*; echo "This is \\"%t\\" but \
   is 50 \% Greek to me" \; cat %s; copiousoutput

---

Appendix C: A Note on Format Translation 🦋

okay so somebody once floated the idea that a mailcap-like thing could also list the tools you have locally for translating documents between formats 🌈 like, file says "use this program to go from format A to B, this other one to go from B to C, and then a viewer for C" 😭 it's giving ambitious!! but ngl the authors said no: that version is way more complicated, and it would make life harder for a user agent that just wants to show a format A message 🙈 it could be useful at the message transport layer too, but the extra complexity isn't worth it for this memo 💅

the point is that the simple mailcap scheme already handles it: one line could tell the user agent to show A-format mail using a whole pipeline of translators plus the C-format viewer 🍓 this memo refuses to make the processing harder, so with the mailcap format defined here, all you do is find the right single line in a mailcap file and run the command on it ✨ iconic simplicity, periodt 👑

---

References 📚

[RFC 822] Crocker, D., "Standard for the format of ARPA Internet text messages", RFC 822, UDEL, August, 1982.

[RFC 1341] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, Bellcore, June, 1992.

---

Acknowledgements 🫶

the author wants to thank Malcolm Bjorn Gillies, Dan Heller, Olle Jaernefors, Keith Moore, Luc Rooijakkers, and the other members of the IETF task force on mail extensions for their comments on earlier versions of this draft 💜 and if they forgot anyone, the author says please let them know, because it was surely an accident 🥺

---

Security Considerations 🔥

⚠️ okay this part is serious, bestie 💀 Security issues are not discussed in this memo. However, the use of the mechanisms described in this memo can make it easier for implementations to slip into the kind of security problems discussed in the MIME document. Implementors and mailcap administrators should be aware of these security considerations, and in particular should exercise caution in the choice of programs to be listed in a mailcap file for automatic execution.

---

Author's Address 🌸

Nathaniel S. Borenstein MRE 2D-296, Bellcore 445 South St. Morristown, NJ 07962-1910

Email: nsb@bellcore.com Phone: +1 201 829 4270 Fax: +1 201 829 7019