mhlist manipulates MIME (multi-media messages) as specified in RFC 2045 to RFC 2049 (See mhbuild(1)).

The -headers switch indicates that a one-line banner should be displayed above the listing.

The -realsize switch tells mhlist to evaluate the ``native'' (decoded) format of each content prior to listing. This provides an accurate count at the expense of a small delay.

If the -verbose switch is present, then the listing will show any ``extra'' information that is present in the message, such as comments in the ``Content-Type'' header.

If the -disposition switch is present, then the listing will show any relevant information from the ``Content-Disposition'' header.

The option -file file directs mhlist to use the specified file as the source message, rather than a message from a folder. If you specify this file as ``-'', then mhlist will accept the source message on the standard input. Note that the file, or input from standard input should be a validly formatted message, just like any other nmh message. It should NOT be in mail drop format (to convert a file in mail drop format to a folder of nmh messages, see inc(1)).

By default, mhlist will list information about the entire message (all of its parts). By using the -part and -type switches, you may limit the scope of this command to particular subparts (of a multipart content) and/or particular content types.

A part specification consists of a series of numbers separated by dots. For example, in a multipart content containing three parts, these would be named as 1, 2, and 3, respectively. If part 2 was also a multipart content containing two parts, these would be named as 2.1 and 2.2, respectively. Note that the -part switch is effective for only messages containing a multipart content. If a message has some other kind of content, or if the part is itself another multipart content, the -part switch will not prevent the content from being acted upon.

A content specification consists of a content type and a subtype. The initial list of ``standard'' content types and subtypes can be found in RFC 2046.

A list of commonly used contents is briefly reproduced here:

Type         Subtypes
----         --------
text         plain, enriched
multipart    mixed, alternative, digest, parallel
message      rfc822, partial, external-body
application  octet-stream, postscript
image        jpeg, gif, png
audio        basic
video        mpeg

A legal MIME message must contain a subtype specification.

To specify a content, regardless of its subtype, just use the name of the content, e.g., ``audio''. To specify a specific subtype, separate the two with a slash, e.g., ``audio/basic''. Note that regardless of the values given to the -type switch, a multipart content (of any subtype listed above) is always acted upon. Further note that if the -type switch is used, and it is desirable to act on a message/external-body content, then the -type switch must be used twice: once for message/external-body and once for the content externally referenced.

The parts of a multipart/alternative part are listed in the reverse order of their placement in the message. The listing therefore is in decreasing order of preference, as defined in RFC 1521.