0001
0002
0003
0004
0005
0006
0007
0008
0009
0010
0011
0012
0013
0014
0015
0016
0017
0018
0019
0020
0021
0022
0023
0024
0025
0026
0027
0028
0029
0030
0031
0032
0033
0034
0035
0036
0037
0038
0039
0040
0041
0042
0043
0044
0045
0046
0047
0048
0049
0050
0051
0052
0053
0054
0055
0056
0057
0058
0059
0060
0061
0062
0063
0064
0065
0066
0067
0068
0069
0070
0071
0072
0073
0074
0075
0076
0077
0078
0079
0080
0081
0082
0083
0084
0085
0086
0087
0088
0089
0090
0091
0092
0093
0094
0095
0096
0097
0098
0099
0100
0101
0102
0103
0104
0105
0106
0107
0108
0109
0110
0111
0112
0113
0114
0115
0116
0117
0118
0119
0120
0121
0122
0123
0124
0125
0126
0127
0128
0129
0130
0131
0132
0133
0134
0135
0136
0137
0138
0139
0140
0141
0142
0143
0144
0145
0146
0147
0148
0149
0150
0151
0152
0153
0154
0155
0156
0157
0158
0159
0160
0161
0162
0163
0164
0165
0166
0167
0168
0169
0170
0171
0172
0173
0174
0175
0176
0177
0178
0179
0180
0181
0182
0183
0184
0185
0186
0187
0188
0189
0190
0191
0192
0193
0194
0195
0196
0197
0198
0199
0200
0201
0202
0203
0204
0205
0206
0207
0208
0209
0210
0211
0212
0213
0214
0215
0216
0217
0218
0219
0220
0221
0222
0223
0224
0225
0226
0227
0228
0229
0230
0231
0232
0233
0234
0235
0236
0237
0238
0239
0240
0241
0242
0243
0244
0245
0246
0247
0248
0249
0250
0251
0252
0253
0254
0255
0256
0257
0258
0259
0260
0261
0262
0263
0264
0265
0266
0267
0268
0269
0270
0271
0272
0273
0274
0275
0276
0277
0278
0279
0280
0281
0282
0283
0284
0285
0286
0287
0288
0289
0290
0291
0292
0293
0294
0295
0296
0297
0298
0299
0300
0301
0302
0303
0304
0305
0306
0307
0308
0309
0310
0311
0312
0313
0314
0315
0316
0317
0318
0319
0320
0321
0322
0323
0324
0325
0326
0327
0328
0329
0330
0331
0332
0333
0334
0335
0336
0337
0338
0339
0340
0341
0342
0343
0344
0345
0346
0347
0348
0349
0350
0351
0352
0353
0354
0355
0356
0357
0358
0359
0360
0361
0362
0363
0364
0365
0366
0367
0368
0369
0370
0371
0372
0373
0374
0375
0376
0377
0378
0379
0380
0381
0382
0383
0384
0385
0386
0387
0388
0389
0390
0391
0392
0393
0394
0395
0396
0397
0398
0399
0400
0401
0402
0403
0404
0405
0406
0407
0408
0409
0410
0411
0412
0413
0414
0415
0416
0417
0418
0419
0420
0421
0422
0423
0424
0425
0426
0427
0428
0429
0430
0431
0432
0433
0434
0435
0436
0437
0438
0439
0440
0441
0442
0443
0444
0445
0446
0447
0448
0449
0450
0451
0452
0453
0454
0455
0456
0457
0458
0459
0460
0461
0462
0463
0464
0465
0466
0467
0468
0469
0470
0471
0472
0473
0474
0475
0476
0477
0478
0479
0480
0481
0482
0483
0484
0485
0486
0487
0488
0489
0490
0491
0492
0493
0494
0495
0496
0497
0498
0499
0500
0501
0502
0503
0504
0505
0506
0507
0508
0509
0510
0511
0512
0513
0514
0515
0516
0517
0518
0519
0520
0521
0522
0523
0524
0525
0526
0527
0528
0529
0530
0531
0532
0533
0534
0535
0536
0537
0538
0539
0540
0541
0542
0543
0544
0545
0546
0547
0548
0549
0550
0551
0552
0553
0554
0555
0556
0557
0558
0559
0560
0561
0562
0563
0564
0565
0566
0567
0568
0569
0570
Network Working Group                                      N. Borenstein
Request for Comments: 1524                                      Bellcore
Category: Informational                                   September 1993

                  A User Agent Configuration Mechanism
                 For Multimedia Mail Format Information

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   This memo suggests a file format to be used to inform multiple mail
   reading user agent programs about the locally-installed facilities
   for handling mail in various formats.  The mechanism is explicitly
   designed to work with mail systems based Internet mail as defined by
   RFC's 821 (STD 10), 822 (STD 11), 934, 1049 (STD 11), 1113, and the
   Multipurpose Internet Mail Extensions, known as MIME.  However, with
   some extensions it could probably be made to work for X.400-based
   mail systems as well.  The format and mechanism are proposed in a
   manner that is generally operating-system independent.  However,
   certain implementation details will inevitably reflect operating
   system differences, some of which will have to be handled in a
   uniform manner for each operating system.  This memo makes such
   situations explicit, and, in an appendix, suggests a standard
   behavior under the UNIX operating system.

Introduction

   The electronic mail world is in the midst of a transition from
   single-part text-only mail to multi-part, multi-media mail.  In
   support of this transition, various extensions to RFC 821 and RFC 822
   have been proposed and/or adopted, notably including MIME [RFC-1521].
   Various parties have demonstrated extremely high-functionality
   multimedia mail, but the problem of mail interchange between
   different user agents has been severe.  In general, only text
   messages have been shared between user agents that were not
   explicitly designed to work together.  This limitation is not
   compatible with a smooth transition to a multi-media mail world.

   One approach to this transition is to modify diverse sets of mail
   reading user agents so that, when they need to display mail of an
   unfamiliar (non-text) type, they consult an external file for
   information on how to display that file.  That file might say, for

Borenstein                                                      [Page 1]

RFC 1524             Multimedia Mail Configuration        September 1993

   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 be given the ability to display
   a wide variety of types of message.  Moreover, extending the set of
   media types supported at a site becomes a simple matter of installing
   a binary and adding a single line to a configuration file.  Crucial
   to this scheme, however, is that all of the user agents agree on a
   common representation and source for the configuration file.  This
   memo proposes such a common representation.

Location of Configuration Information

   Each user agent must clearly obtain the configuration information
   from a common location, if the same information is to be used to
   configure all user agents.  However, individual users should be able
   to override or augment a site's configuration.  The configuration
   information should therefore be obtained from a designated set of
   locations.  The overall configuration will be obtained through the
   virtual concatenation of several individual configuration files known
   as mailcap files.  The configuration information will be obtained
   from the FIRST matching entry in a mailcap file, where "matching"
   depends on both a matching content-type specification, an entry
   containing sufficient information for the purposes of the application
   doing the searching, and the success of any test in the "test="
   field, if present.

   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 consists of a set of entries that describe the
   proper handling of one media type at the local site.

   For example, one line might tell how to display a message in Group
   III fax format.  A mailcap file consists of a sequence of such
   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 considered comments, and are
   ignored.  Long entries may be continued on multiple lines if each
   non-terminal line ends with a backslash character ('\', ASCII 92), in
   which case the multiple lines are to be treated as a single mailcap
   entry.  Note that for such "continued" lines, the backslash must be
   the last character on the line to be continued.

Borenstein                                                      [Page 2]

RFC 1524             Multimedia Mail Configuration        September 1993

   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 consists of a number of fields, separated by
   semi-colons.  The first two fields are required, and 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 indicates the type of data
   this mailcap entry describes how to handle.  It is to be matched
   against the type/subtype specification in the "Content-Type" header
   field of an Internet mail message.  If the subtype is specified as
   "*", it is intended to match all subtypes of the named content-type.

   The second field, view-command, is a specification of how the message
   or body part can be viewed at the local site.  Although the syntax of
   this field is fully specified, the semantics of program execution are
   necessarily somewhat operating system dependent.  UNIX semantics are
   given in Appendix A.

   The optional fields, which may be given in any order, are as follows:

   -- The "compose" field may be used to specify a program that can be
      used to compose a new body or body part in the given format.  Its
      intended use is to support mail composing agents that support the
      composition of multiple types of mail using external composing
      agents.  As with the view-command, the semantics of program
      execution are operating system dependent, with UNIX semantics
      specified in Appendix A.  The result of the composing program may
      be data that is not yet suitable for mail transport -- that is, a
      Content-Transfer-Encoding may need to be applied to the data.

   -- The "composetyped" field is similar to the "compose" field, but is
      to be used when the composing program needs to specify the

Borenstein                                                      [Page 3]

RFC 1524             Multimedia Mail Configuration        September 1993

      Content-type header field to be applied to the composed data.  The
      "compose" field is simpler, and is preferred for use with existing
      (non-mail-oriented) programs for composing data in a given format.
      The "composetyped" field is necessary when the Content-type
      information must include auxilliary parameters, and the
      composition program must then know enough about mail formats to
      produce output that includes the mail type information.

   -- The "edit" field may be used to specify a program that can be used
      to edit a body or body part in the given format.  In many cases,
      it may be identical in content to the "compose" field, and shares
      the operating-system dependent semantics for program execution.

   -- The "print" field may be used to specify a program that can be
      used to 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 specified in Appendix A.

   -- The "test" field may be used to test some external condition
      (e.g., the machine architecture, or the window system in use) to
      determine whether or not the mailcap line applies.  It specifies a
      program to be run to test some condition.  The semantics of
      execution and of the value returned by the test program are
      operating system dependent, with UNIX semantics specified in
      Appendix A.  If the test fails, a subsequent mailcap entry should
      be sought.  Multiple test fields are not permitted -- since a test
      can call a program, it can already be arbitrarily complex.

   -- The "needsterminal" field indicates that the view-command must be
      run on an interactive terminal.  This is needed to inform window-
      oriented user agents that an interactive terminal is needed.  (The
      decision is not 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 is a requirement for the environment in which the
      program will be executed, and should typically cause the creation
      of a terminal window when not executed on either a real terminal
      or a terminal window.

   -- The "copiousoutput" field indicates that the output from the
      view-command will be an extended stream of output, and is to be
      interpreted as advice to the UA (User Agent mail-reading program)
      that the output should be either paged or made scrollable. Note
      that it is probably a mistake if needsterminal and copiousoutput
      are both specified.

Borenstein                                                      [Page 4]

RFC 1524             Multimedia Mail Configuration        September 1993

   -- The "description" field simply provides a textual description,
      optionally quoted, that describes the type of data, to be used
      optionally by mail readers that wish to describe the data before
      offering to display it.

   -- The "textualnewlines" field, if set to any non-zero value,
      indicates that this type of data is line-oriented and that, if
      encoded in base64, all newlines should be converted to canonical
      form (CRLF) before encoding, and will be in that form after
      decoding.  In general, this field is needed only if there is
      line-oriented data of some type other than text/* or non-line-
      oriented data that is a subtype of text.

   -- The "x11-bitmap" field names a file, in X11 bitmap (xbm) format,
      which points to an appropriate icon to be used to visually denote
      the presence of this kind of data.

   -- The "nametemplate" field gives a file name format, in which %s
      will be replaced by a short unique string to give the name of the
      temporary file to be passed to the viewing command.  This is only
      expected to be relevant in environments where filename extensions
      are meaningful, e.g., one coulld specify that a GIF file being
      passed to a gif viewer should have a name eding in ".gif" by using
      "nametemplate=%s.gif".

   Any other fields beginning with "x-" may be included for local or
   mailer-specific extensions of this format.  Implementations should
   simply ignore all such unrecognized fields to permit such extensions,
   some of which might be standardized in a future version of this
   document.

   Some of the fields above, such as "needsterminal", apply to the
   actions of the view-command, edit-command, and compose-command,
   alike.  In some unusual cases, this may not be desirable, but
   differentiation can be accomplished via separate mailcap entries,
   taking advantage of the fact that subsequent mailcap entries are
   searched if an earlier mailcap entry does not provide enough
   information:

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

   In RFC 822 modified BNF, the following grammar describes a mailcap
   entry:

Borenstein                                                      [Page 5]

RFC 1524             Multimedia Mail Configuration        September 1993

         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"
                        / "textualnewlines"
                        / "description"
                        / x-token

   Note that "type", "subtype", and "x-token" are defined in MIME.  Note
   also that while the definition of "schar" includes the percent sign,
   "%", this character has a special meaning in at least the UNIX
   semantics, and will therefore need to be quoted as a qchar to be used
   literally.

Borenstein                                                      [Page 6]

RFC 1524             Multimedia Mail Configuration        September 1993

Acknowledgements

   The author wishes 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.  If other acknowledgements were neglected,
   please let me know, as it was surely accidental.

Security Considerations

   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

Borenstein                                                      [Page 7]

RFC 1524             Multimedia Mail Configuration        September 1993

Appendix A:  Implementation Details for UNIX

   Although this memo fully specifies a syntax for "mailcap" files, the
   semantics of the mailcap file are of necessity operating-system
   dependent in four respects.  In order to clarify the intent, and to
   promote a standard usage, this appendix proposes a UNIX semantics for
   these four cases.  If a mailcap mechanism is 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 may itself be overridden by a path specified by
   the MAILCAPS environment variable.

Semantics of executable commands

   Several portions of a mailcap entry specify commands to be executed.
   In particular, the mandatory second fie ld, the view-command, takes a
   command to be executed, as do the optional print, edit, test, and
   compose fields.

   On a UNIX system, such commands will each be a full shell command
   line, including the path name for a program and its arguments.
   (Because of differences in shells and the implementation and behavior
   of the same shell from one system to another, it is specified that
   the command line be intended as input to the Bourne shell, i.e., that
   it is implicitly preceded by "/bin/sh -c " on the command line.)

   The two characters "%s", if used, will be replaced by the name of a
   file for the actual mail body data.  In the case of the edit adn
   view-command, the body part will be passed to this command as
   standard input unless one or more instances of "%s" appear in the
   view-command, in which case %s will be replaced by the name of a file
   containing the body part, a file which may have to be created before
   the view-command program is executed.  (Such files cannot be presumed
   to continue to exist after the view-command program exits.  Thus a
   view-command that wishes to exit and continue processing in the
   background should take care to save the data first.)  In the case of
   the compose and composetyped commands, %s should be replaced by the
   name of a file to which the composed data should be written by the
   programs named in the compose or composedtyped commands.  Thus, the
   calling program will look in that file later in order to retrieve the
   composed data. If %s does not appear in the compose or composetyped

Borenstein                                                      [Page 8]

RFC 1524             Multimedia Mail Configuration        September 1993

   commands, then the composed data will be assumed to be written by the
   composing programs to standard output.

   Furthermore, any occurrence of "%t" will be replaced by the content-
   type and subtype specification.  (That is, if the content-type is
   "text/plain", then %t will be replaced by "text/plain".)  A literal %
   character may be quoted as \%.  Finally, named parameters from the
   Content-type field may be placed in the command execution line using
   "%{" followed by the parameter name and a closing "}" character.  The
   entire parameter should appear as a single command line argument,
   regardless of embedded spaces.  Thus, 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

   If the content-type is "multipart" (any subtype), then the two
   characters "%n" will be replaced by an integer giving the number of
   sub-parts within the multipart entity.  Also, the two characters "%F"
   will be replaced by a set of arguments, twice as many arguments as
   the number of sub-parts, consisting of alternating content-types and
   file names for each part in turn.  Thus if multipart entity has three
   parts, "%F" will be replaced by the equivalent of "content-type1
   file-name1 content-type2 file-name2 content-type3 file-name3".

Semantics of the "test" field

   The "test" field specifies a program to be used to test whether or
   not the current mailcap line applies.  This can be used, for example,
   to have a mailcap line that only applies if the X window system is
   running, or if the user is running on a SPARCstation with a
   /dev/audio.  The value of the "test" field is a program to run to
   test such a condition.  The precise program to run and arguments to
   give it 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.

Borenstein                                                      [Page 9]

RFC 1524             Multimedia Mail Configuration        September 1993

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 will be
   executed with the command line arguments determined as specified
   above.  The data returned via its standard output will be given a
   Content-Type field that has no supplementary parameters.  For
   example, the following 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 this is unacceptable -- for example, in the case of multipart mail
   a "boundary" parameter is required -- then the "compose" field cannot
   be used.  Instead, the "composetyped" field should be used in the
   mailcap file.

Semantics of the "composetyped" field

   The "composetyped" filed 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
   will be 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, the following mailcap entry:

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

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

        Content-Type: multipart/mixed; boundary=foobar

   Note that a composition program need not 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 is not
   encouraged, it should announce that fact using a Content-Transfer-
   Encoding header in the standard manner defined by MIME.  Because such

Borenstein                                                     [Page 10]

RFC 1524             Multimedia Mail Configuration        September 1993

   encodings must be announced by such a header, they are an option only
   for composetyped programs, not for compose programs.

Appendix B: Sample Mailcap File

   The following is an example of a mailcap file for UNIX that
   demonstrates most of the syntax above.  It contains explanatory
   comments where necessary.

         # 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

Borenstein                                                     [Page 11]

RFC 1524             Multimedia Mail Configuration        September 1993

Appendix C:  A Note on Format Translation

   It has been suggested that another function of a mailcap-like
   mechanism might be to specify the locally available tools for
   document format translation.  For example, the file could designate a
   program for translating from format A to format B, another for
   translating from format B to format C, and finally a mechanism for
   displaying format C.  Although this mechanism would be somewhat
   richer than the current mailcap file, and might conceivably also have
   utility at the message transport layer, it significantly complicates
   the processing effort necessary for a user agent that simply wants to
   display a message in format A.  Using the current, simpler, mailcap
   scheme, a single line could tell such a user agent to display A-
   format mail using a pipeline of translators and the C-format viewer.
   This memo resists the temptation to complicate the necessary
   processing for a user agent to accomplish this task.  Using the
   mailcap format defined here, it is only necessary to find the correct
   single line in a mailcap file, and to execute the command given in
   that line.

References

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

     [RFC-1521] Borenstein, N., and N.  Freed, "MIME (Multipurpose
     Internet Mail Extensions) Part One: Mechanisms for Specifying and
     Describing the Format of Internet Message Bodies", RFC 1521,
     Bellcore, Innosoft, September 1993.

Borenstein                                                     [Page 12]

Search by Algolia