Provided by: mmh_0.4-2_amd64 bug

NAME

       mhlist - list information about MIME messages

SYNOPSIS

       mhlist [+folder] [msgs] [-file file] [-part number] ...  [-type content] ...  [-verbose | -noverbose]
            [-Version] [-help]

DESCRIPTION

       The mhlist command allows you to list information (essentially a table of  contents)  about  the  various
       parts of a collection of MIME (multi-media) messages.

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

       A  one-line  banner  is  displayed  above the listing.  The size of the `native' (decoded) format of each
       content is evaluated.  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.

       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 mh message.  It should NOT be in mail drop format (to convert a file in mail
       drop format to a folder of mh 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.

FILES

       $HOME/.mmh/profile         The user profile

PROFILE COMPONENTS

       Path:                To determine the user's mail storage
       Current-Folder:      To find the default current folder

SEE ALSO

       mhbuild(1), show(1), mhstore(1), sendfiles(1)

DEFAULTS

       `+folder' defaults to the current folder
       `msgs' defaults to the current message
       `-noverbose'

CONTEXT

       If  a  folder  is  given,  it  will become the current folder.  The last message selected will become the
       current message.