METAMAIL(1)

πŸ“¦ version 2.7.19, in opensuse-leap 16.0

πŸ’Œ METAMAIL(1) β€” the group chat edition πŸŽ€

okay so picture this: you're a mail-reading program and a message rolls up that is not text. what do you do?? you call metamail(1), bestie. that's the whole vibe. this is the general commands manual page and it's giving "infrastructure for mailcap-based multimedia mail handling." slay.


✨ NAME ✨

metamail β€” literally the infrastructure for mailcap-based multimedia mail handling. that's it. that's the name. πŸ’…


πŸ¦‹ SYNOPSIS πŸ¦‹

metamail[-b] [-B] [-c contenttype ...] [-d] [-e] [-E contentencoding]
[-f  from-name] [-h] [-m mailer-name] [-p] [-P] [-r] [-s subject] [-q]
[-w] [-x] [-y] [-z] [file-name]

(yeah the spacing is a little unhinged, she's an icon, we don't fix her 🫢)


🌸 DESCRIPTION 🌸

okay so the metamail program reads a "mailcap" file to figure out how to display non-text stuff at your local site. every mail-reading interface needs to call metamail whenever non-text mail is being viewed β€” unless, like, the mail is a type the mail-reading program already understands. metamail consults the mailcap file(s) to determine which program to use to show the message to the user. periodt.

here's the actual main character energy of it: at a site where all mail reading interfaces have been modified to call metamail for non-text mail, extending the local email system to handle a new media type in the mail becomes a simple matter of adding a line to a mailcap file. one line. that's it. (although this manual page will discuss only mail, metamail is equally useful in adding multimedia support to news and bulletin board reading programs β€” assuming those programs preserve the "Content-type" header or some other indication of the content type of the messages. iykyk.)

so like, in general? users will never run metamail directly. nope. instead, metamail gets invoked for the user automatically by the user's mail reading program, whenever a non-text message is to be viewed. so this manual page is not directed at end users β€” it's for two categories of readers, and honestly both of y'all are valid:

  1. those who are adding metamail support to a particular mail-reading program
  2. those who are adding lines to a mailcap file

the first group only needs to be concerned with the command line syntax of metamail. the second group can ignore the command line syntax entirely and only needs to be concerned with the mailcap file syntax, as described in a later section. see? everyone eats. πŸ“

note, bestie: Metamail determines the type of a message using the "Content-type" header, as defined in RFC 1049 and RFC-1341 (MIME). however, using the -b and -c options, metamail can be made to work with mail that is not in Internet format, including X.400 messages. also note that metamail automatically decodes mail that has been encoded for 7 bit transport if the mail includes a Content-Transfer-Encoding header as specified by RFC-1341. if data has been encoded via the "base64" encoding, it will map CRLF to local newlines for textual data, but not for other data β€” unless instructed otherwise by a "textualnewlines" field in a mailcap entry. no cap, that distinction matters. 🧚

πŸ’… OPTIONS πŸ’…

when called with no options or arguments, metamail expects to receive an RFC 822 format message on its standard input. the following options can alter that expectation. buckle up, there's a lot of them, and they're all iconic in their own way:

  • -b β€” tells metamail that the message is not in RFC 822 format, but instead is only the body of the message (i.e. there are no message headers). heads up though: the use of -b requires the use of -c. they're a package deal. πŸŽ€
  • -B β€” tells metamail that the message is to be displayed in the background, if it is non-interactive (i.e. it doesn't have the "needsterminal" attribute in the mailcap file). it cannot be used with -p or -P. pick a lane.
  • -c contenttype β€” tells metamail to use the specified content type rather than the one in the headers, if any.
  • -d β€” tells metamail not to ask any questions before running an interpreter to view the message. (by default, metamail always asks before running almost any interpreter, if it is running in an interactive terminal and the MM_NOASK environment variable is not set. however, it does not ask about the content-type "text" β€” that is, the default value for MM_NOASK is "text,text/us-ascii".)
  • -e β€” tells metamail to "eat" leading newlines in message bodies. this is particularly useful for MH-format mail. she's hungry, let her snack. πŸ™ˆ
  • -f address β€” specifies the name of the sender of the message. otherwise, this is determined from the header, if possible. this information will be placed in the environment to make it available to any interpreters called by metamail.
  • -h β€” specifies that metamail is being used for printing a message. in particular, this means that the normal mailcap "command" field will not be executed β€” instead the command specified in the "print" field will be executed. (if there is nothing in the print field, the mailcap entry will be ignored and the search will continue for a matching mailcap entry that does have a print field.) the -h option automatically turns on the -d option. two for one, we love efficiency. ✨
  • -m mailername β€” specifies the name of the mail program that called metamail. this information will be placed in the environment to make it available to any interpreters called by metamail.
  • -p β€” specifies that, if necessary, output should be shown to the user one page at a time. by default, this will cause such output to be piped through the "more" command, but the environment variable METAMAIL_PAGER can be used to specify an alternative command to use. note that one should use -p rather than piping the output of metamail through a pager β€” because some interpreters called by metamail might be interactive rather than requiring pagination, and metamail can tell whether or not to use a pager from information in the mailcap file. this option cannot be used with -B.
  • -P β€” just like -p, except it also causes metamail to print "Press RETURN to go on" and await a RETURN after it has finished with the message. this is intended for use only when metamail calls itself recursively in a new terminal window created only for that purpose. this option cannot be used with -B.
  • -q β€” tells metamail to be quiet. by default, metamail prints a few key message headers (controllable with the KEYHEADS and KEYIGNHEADS environment variables) and some other informative information, on stdout before running the interpreter β€” but this behavior is suppressed with -q. shhh. she's in her quiet era. 🀫
  • -r β€” specifies that it is OK to run as root. by default, metamail refuses to run if the real or effective user id is root. you can get the same effect using the MM_RUNASROOT environment variable. (root is not the vibe unless you say so, fr.)
  • -R β€” specifies that the /usr/ucb/reset should be executed to reset the terminal state, before any other I/O activity.
  • -s subject β€” specifies the subject of the mail message. by default, this information is obtained from the headers. this information will be placed in the environment to make it available to any interpreters called by metamail.
  • -w β€” tells metamail that instead of consulting a mailcap file to decide how to display the data, it should simply decode each part and write it to a file in its raw (possibly binary) format. depending on the circumstances in which it is called, metamail may derive the file name to use from the message headers, by asking the user, or by generating a unique temporary file name. lowkey the most "just give me the file" option ever.
  • -x β€” tells metamail that it is definitely not running on a terminal, no matter what isatty() says. this is necessary when metamail is actually running on a pseudoterminal and isatty(3) returns TRUE but there's really no terminal on which to interact with the user. the same effect as -x can also be obtained with the environment variable MM_NOTTTY. she said what she said πŸ’€
  • -y β€” tells metamail to try to "yank" a MIME-format message from the body of the message. it is useful when a MIME-format has been rejected by a mail delivery system that does not now how to format the rejection in a MIME-compliant manner. (for the convenience of those who can't control how metamail is called from their mail reader, this can also be set with the MM_YANKMODE variable.)
okay serious warning time: if you use yank mode on messages that really ARE in MIME format, or on messages that do not contain a MIME message in the body, the effects could be VERY strange. it won't hurt you, but you won't see anything very useful, either. so like… don't come crying to me. 😭
  • -z β€” tells metamail to delete its input file when finished. the -z option requires that a file name was given as an argument to metamail, i.e. that it is not reading stdin. no filename, no -z. rules are rules.
  • -T β€” this one is intended to be used by metamail recursively, to turn off the effect of the MM_TRANSPARENT environment variable. it should only be used when the metamail program restarts itself in a terminal emulator window. don't just sprinkle it around, bestie.

πŸ“ File Name Arguments πŸ“

any argument that does not start with "-" is interpreted as the name of a file to read instead of standard input. easy as that. πŸ¦‹


πŸ”₯ UNRECOGNIZED MAIL TYPES πŸ”₯

from time to time, metamail may tell you something like:

**** Unrecognized mail type: 'smell-o-vision'.  Writing to file
/tmp/metamail.1234 ****

and you're sitting there like… bestie what. what this means is that your are trying to read a message that contains data that is marked as being in "smell-o-vision" format, but that your site has not yet configured metamail to properly display that type of data. in the general case, such configuration is accomplished using the mailcap file mechanism, as described in the next section. so it's not broken, it's just… not configured yet. yet. 🌈

for unrecognized types, metamail simply removes all header and encoding information from the data, and writes it out to a temporary file. (if running interactively, it will give you more alternatives β€” writing it to a temporary file, viewing it as text, or jus skipping it.) and it is up to the user to delete such files when he or she is through with them β€” yes, you, go clean up your temp files, they're not gonna delete themselves. πŸŽ€


πŸŽ€ THE MAILCAP FILE(S) πŸŽ€

So here's the whole point of metamail, bestie: it lets a million different mail reading programs all centralize their access to multimedia info. Like, imagine every mail reader on the planet calling one single program to deal with non-text mail β€” then only that one program needs to know about all the diverse types of non-text mail that might come through. Iconic delegation, honestly.

And metamail gets extra flexible in this role through the mechanism of one or more "mailcap" files. What those files do is literally just tell metamail what program to run in order to show the user mail in a given format. Which means you can add a whole new media type to all the mail reading programs at a site just by adding one line to a mailcap file. Slay.

metamail uses a search path to find the mailcap file(s) it should consult. But heads up β€” unlike a lot of path searches, if it's necessary, metamail will read all the mailcap files on its path. Yep. It keeps reading mailcap files until it runs out of them, or until it finds a line that tells it how to handle the piece of mail it's looking at. Found a matching line? It executes the command specified in the mailcap file. Periodt.

The default search path is equivalent to:

$HOME/.mailcap:/usr/local/etc/mailcap:/usr/etc/mailcap:/etc/mailcap:/etc/mail/mailcap:/usr/public/lib/mailcap"

It can be overridden by setting the MAILCAPS environment variable.

⚠️ Note: metamail does not actually interpret environment variables such as $HOME or the ~ syntax in this path search. Just so you know before you get cute with it. πŸ’…

The format of mailcap files is explained in the manual entry for mailcap(4). Go read it, iykyk.


✨ NON-ASCII HEADER FIELDS ✨

metamail has rudimentary built-in support for the emerging Internet standards for non-ASCII data in mail headers. What that means, practically: such data will be recognized, decoded, and sent to your terminal. 🫢

Whether that's reasonable is a whole vibe check situation β€” it depends on the character set in the header data and on how capable your terminal is. But it will rarely be any worse than showing that data in its encoded form, so, lowkey, it's fine.


🌈 ENVIRONMENT 🌈

METAMAIL_TMPDIR

If set, this variable overrides "/tmp" as the name of the directory in which metamail and its associated programs will create temporary files on UNIX. πŸ“

MM_NOASK

If MM_NOASK is set to "1", metamail will never ask the user for confirmation before running an interpreter. Never ever. No cap.

Otherwise, MM_NOASK may be set to a comma-separated list of type names (no whitespace, please 🚫) for which the user does not desire confirmation. So setting MM_NOASK to "magicmail,audio" will cause the user not to be asked before running interpreters for magicmail- or audio-format mail β€” but the user will still be asked for all other types.

πŸ’‘ (If the -d command line option is given, MM_NOASK is set to 1 for spawned processes, allowing -d to work recursively. Sneaky but smart.)

KEYHEADS

The KEYHEADS variable may be set to a colon-separated list of header names, which are the only headers that metamail will print out. By default, the behavior is as if KEYHEADS were set to:

Date:From:Subject:To:CC:Content-Description

If KEYHEADS is set to the empty string, no headers are printed out. If it's set to an asterisk ("*"), all headers are printed out. 🌟

KEYIGNHEADS

The KEYIGNHEADS variable may be set to a colon-separated list of header names β€” these are the headers that metamail will not print out. This variable is only examined if KEYHEADS is not set.

If KEYIGNHEADS is set to the empty string, all headers are printed out. If it's set to an asterisk ("*"), no headers will be printed out. πŸ™ˆ

MM_NOTTTY

If MM_NOTTTY is set to any nonzero value, metamail will assume it is not running in a terminal window. MM_NOTTTY implies setting MM_NOASK to 1.

If -z is given, MM_NOTTTY is set for spawned processes, allowing -z to work recursively. πŸŒ€

MAILCAPS

This variable can be used to override the default path search for mailcap files. Simple as that. πŸ—‚οΈ

METAMAIL_PAGER

If set, this variable overrides "more" as the name of the program to run to paginate output from an interpreter, when pagination has been requested.

🚨 Note that the normal "PAGER" variable is not used, because many pagers (notably the "less" pager) interfere with the workings of termcap-based mail viewers. Rude of them honestly.

NOMETAMAIL

This variable is not actually used by metamail itself β€” it's used by most metamail-compatible mail reading interfaces. If NOMETAMAIL is set to any value, most mail reading interfaces will never call the metamail program, effectively inhibiting all multimedia functionality. πŸ’€ So set it only if that's genuinely what you want.

MM_DEBUG

If MM_DEBUG is set to any value, metamail will produce slightly more verbose output to tell you what it's doing. Detective mode: on. πŸ”

MM_QUIET

If this variable is set to "1", metamail will produce even less output than usual. In particular, it will suppress the "Executing..." line unless MM_DEBUG is set.

Otherwise, this variable can be set to a comma-separated list of short commands, and the "Executing..." line will be suppressed for those commands only.

The default setting for MM_QUIET is "cat", which means the "Executing..." line is printed for all commands executed except "cat". This makes text support look more natural without sacrificing an understanding of what's going on in more complex circumstances. Chef's kiss. πŸ‘‘

MM_YANKMODE

Setting this variable to a non-zero value has the same effect as the -y switch.

πŸ›‘ Be sure to read the caveats attached to the description of -y before you use it.

Basically, the only time you would set MM_YANKMODE is in order to re-enter a mail reader in which you can't control the way metamail is called, just to read a single rejected MIME message that was rejected by a mail agent that does not understand MIME. In such cases, you should read that message, exit, and unset this variable. In, out, done. πŸ¦‹

MM_TRANSPARENT

If this variable is set, metamail will reproduce the entire raw message on stdout, and will open up a new terminal emulator window in which to do something more intelligent.

This option supports certain brain-dead mail readers, such as mailtool, that actually depend on the output of the UNIX "Mail" program being the same as the raw message in the database. 😭 (We don't make the rules.)

MM_CHARSET

If this variable is set, it will suppress the printing of character set declarations when mail headers being printed contain text in this character set. For example, if you set MM_CHARSET to "iso-8859-8", it will suppress warnings when header output is produced in that character set. 🌸

DISPLAY

Used to create a terminal window under the X11 window system. πŸ–₯️

WINDOW_PARENT

Used to create a terminal window under the SunTools window system. β˜€οΈ

WMHOST

Used to create a terminal window under the old Andrew WM window system. πŸͺŸ


🧚 INTERPRETER ENVIRONMENT 🧚

When metamail calls an interpreter specified in a mailcap file, it sets several environment variables which the interpreter can use if it wants to. Little gift basket of context, basically. 🎁

MM_HEADERS

This variable is set to the full set of RFC822 headers, if any. πŸ“œ

MM_MAILER

This variable is set to the name of the mailer that called metamail, if the -m option was used.

MM_CONTENTTYPE

This variable is set to the content type, as named by the Content-type header or passed in via the -c option. If the content-type has a subtype and parameters, these are also included in MM_CONTENTTYPE, e.g. "multipart/mixed; boundary=foobar". 🏷️

MM_SUMMARY

This variable is set to an efficient one-line "caption" of the message, typically including its sender and subject. Cute and useful.

MM_USEPAGER

This variable is set to a non-zero value if the use of a pager has been requested for long output (e.g. the -p switch was given). If -p is given, MM_USEPAGER is set for spawned processes, allowing -p to work recursively.

⚠️ This option cannot be used with -B.

TERMINAL_CMD

This variable may be set to a string that is used to start a new terminal window if necessary. The command to be executed in that window will be APPENDED to this command.

By default, this is set to something like "xterm -e" if DISPLAY is set, or "shelltool" if WINDOW_PARENT is set. Users of Sun's OpenWindows may wish to set TERMINAL_CMD to "shelltool" if they prefer shelltool over xterm. Your window, your choice. πŸͺŸβœ¨

MM_RUNASROOT

If set to a non-zero variable, this will allow the metamail program to be run by root β€” the same effect as the "-r" switch to metamail. πŸ‘‘


πŸ’– FILES πŸ’–

  • $HOME/.mailcap:/etc/mailcap:/usr/etc/mailcap:/usr/local/etc/mailcap β€” default path for mailcap files.

πŸ‘€ SEE ALSO πŸ‘€

audiocompose(1), audiosend(1), ezview(1), getfilename(1), mailto-hebrew(1), mailto(1), metasend(1), mmencode(1), richtext(1), showaudio(1), showexternal(1), showsnonascii(1), showpartial(1), showpicture(1), mailcap(4)

okay so legal bit, but it's actually kind of sweet β€” Copyright (c) 1991 Bell Communications Research, Inc. (Bellcore) πŸŽ€

Permission to use, copy, modify, and distribute this material for any purpose and without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies β€” and that the name of Bellcore not be used in advertising or publicity pertaining to this material without the specific, prior written permission of an authorized representative of Bellcore. periodt. No sneaky name-dropping in your ad campaign, bestie, it's giving "ask first or don't" πŸ’…

BELLCORE MAKES NO REPRESENTATIONS ABOUT THE ACCURACY OR SUITABILITY OF THIS MATERIAL FOR ANY PURPOSE. IT IS PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES. 😭 so basically: it's yours, it's free, and it comes with absolutely zero promises. iconic honestly.

πŸ‘‘ AUTHOR πŸ‘‘

Nathaniel S. Borenstein β€” the main character who wrote this 🫢


and that's the whole thing, bestie!! ✨ you read the entire METAMAIL(1) page and honestly? proud of you πŸ¦‹ go send some mail, attach something cursed, write an interpreter in a language nobody asked for. this page is from the Bellcore Prototype, Release 2, and it lives under the name METAMAIL(1) β€” that's the source, the version, and the whole footer vibe, all wrapped up with a bow πŸŽ€ ngl, a 1991 banger that still slaps. love u, bye! πŸ’œπŸŒΈ

πŸ“¦ where this page comes from