MHN(1)

MHN(1)

mhmail Home Page User Commands Index mhparam


NAME
       mhn - display/list/store/cache MIME messages

SYNOPSIS
       mhn [+folder] [msgs] [-file file]
            [-part number]... [-type content]...
            [-show] [-noshow] [-list] [-nolist]
            [-store] [-nostore] [-cache] [-nocache]
            [-headers] [-noheaders] [-realsize] [-norealsize]
            [-serialonly] [-noserialonly] [-form formfile]
            [-pause] [-nopause] [-auto] [-noauto]
            [-rcache policy] [-wcache policy] [-check] [-nocheck]
            [-verbose] [-noverbose] [-version] [-help]

     mhn -build file
            [-ebcdicsafe] [-noebcdicsafe]
            [-rfc934mode] [-norfc934mode]

DESCRIPTION
       The mhn command allows you to  display,  list,  store,  or
       cache the contents of a MIME (multi-media) messages.

       mhn  manipulates  multi-media  messages  as  specified  in
       RFC-2045  thru  RFC-2049.   Currently  mhn  only  supports
       encodings  in  message  bodies,  and  does not support the
       encoding of message headers as specified in RFC-2047.

       The switches  `-list',  `-show',  `-store',  and  `-cache'
       direct the operation of mhn.  Any of these switches may be
       used concurrently.  These switches are used to operate  on
       the  content  of each of the named messages.  By using the
       `-part' and `-type' switches, the scope of  the  operation
       can be focused on particular subparts (of a multipart con-
       tent) and/or particular content types.

       The switch `-build' is used to construct a  MIME  message.
       It is for backward compatibility and instructs mhn to exe-
       cute the mhbuild command.  It is preferred  that  you  use
       the mhbuild command directly.  See the mhbuild(1) man page
       for details.

       The option `-file file' directs mhn to use  the  specified
       file  as  the source message, rather than a message from a
       folder.  If you specify this file as "-",  then  mhn  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 mes-
       sage.  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)).

       A part specification consists of a series of numbers sepa-
       rated  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 spe-
       cific  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.

   Checking the Contents
       The `-check' switch tells mhn to check each content for an
       integrity  checksum.   If  a  content  has such a checksum
       (specified as a Content-MD5 header field), then  mhn  will
       attempt to verify the integrity of the content.

   Listing the Contents
       The `-list' switch tells mhn to list the table of contents
       associated with the named messages.

       The `-headers' switch indicates  that  a  one-line  banner
       should  be  displayed  above the listing.  The `-realsize'
       switch tells mhn to evaluate the "native" (decoded) format
       of  each content prior to listing.  This provides an accu-
       rate 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.

   Showing the Contents
       The  `-show'  switch  tells mhn to display the contents of
       the named messages.

       The headers of each message are displayed with the mhlproc
       (usually mhl), using the standard format file mhl.headers.
       You may specify an alternate format file with  the  `-form
       formfile'  switch.   If the format file mhl.null is speci-
       fied, then the display of  the  message  headers  is  sup-
       pressed.

       The  method  used to display the different contents in the
       messages bodies will be determined by a "display  string".
       To  find  the  display  string, mhn will first search your
       profile for an entry of the form:

            mhn-show-<type>/<subtype>

       to determine the display string.  If this isn't found, mhn
       will search for an entry of the form:

            mhn-show-<type>

       to determine the display string.

       If  a  display  string is found, any escapes (given below)
       will be expanded.   The  result  will  be  executed  under
       /bin/sh,  with the standard input set to the content.  The
       display string may contain the following escapes:

            %a  Insert parameters from Content-Type field
            %e  exclusive execution
            %f  Insert filename containing content
            %F  %e, %f, and stdin is terminal not content
            %l  display listing prior to displaying content
            %p  %l, and ask for confirmation
            %s  Insert content subtype
            %d  Insert content description
            %%  Insert the character %

       For those display strings containing the e-  or  F-escape,
       mhn  will  execute at most one of these at any given time.
       Although the F-escape expands to be the filename  contain-
       ing  the  content, the e-escape has no expansion as far as
       the shell is concerned.

       When the p-escape prompts for  confirmation,  typing  INTR
       (usually control-C) will tell mhn not to display that con-
       tent.  The p-escape can  be  disabled  by  specifying  the
       switch  `-nopause'.   Further,  when mhn is display a con-
       tent, typing QUIT (usually control-\)  will  tell  mhn  to
       wrap things up immediately.

       Note that if the content being displayed is multipart, but
       not one of the subtypes listed above, then the f-  and  F-
       escapes  expand to multiple filenames, one for each subor-
       dinate content.  Further, stdin is not redirected from the
       terminal to the content.

       If  a display string is not found, mhn has several default
       values:

            mhn-show-text/plain: %pmoreproc '%F'
            mhn-show-message/rfc822: %pshow -file '%F'

       If a subtype of type text doesn't have a profile entry, it
       will be treated as text/plain.

       mhn has default methods for handling multipart messages of
       subtype mixed, alternative,  parallel,  and  digest.   Any
       unknown  subtype  of  type  multipart  (without  a profile
       entry), will be treated as multipart/mixed.

       If none of these apply, then mhn will check to see if  the
       message   has  an  application/octet-stream  content  with
       parameter "type=tar".  If so, mhn will use an  appropriate
       command.  If not, mhn will complain.

       Example entries might be:

            mhn-show-audio/basic: raw2audio 2>/dev/null | play
            mhn-show-image: xv '%f'
            mhn-show-application/PostScript: lpr -Pps

       Note  that when using the f- or F-escape, it's a good idea
       to use single-quotes around  the  escape.   This  prevents
       misinterpretation  by  the  shell  of any funny characters
       that might be present in the filename.

       Finally, mhn  will  process  each  message  serially -- it
       won't  start  showing  the next message until all the com-
       mands executed to display the current message have  termi-
       nated.  In the case of a multipart content (of any subtype
       listed above), the content contains advice  indicating  if

       the  parts  should  be  displayed serially or in parallel.
       Because this may cause confusion, particularly on uni-win-
       dow  displays,  the  `-serialonly'  switch can be given to
       tell mhn to never display parts in parallel.

   Showing Alternate Character Sets
       Because a content of type text might  be  in  a  non-ASCII
       character  set,  when mhn encounters a "charset" parameter
       for this content, it checks if your terminal  can  display
       this character set natively.  Mhn checks this by examining
       the the environment variable MM_CHARSET.  If the value  of
       this  environment  variable  is  equal to the value of the
       charset parameter, then mhn assumes it  can  display  this
       content without any additional setup.  If this environment
       variable is not set, mhn  will  assume  a  value  of  "US-
       ASCII".    If   the  character  set  cannot  be  displayed
       natively, then mhn will look for an entry of the form:

            mhn-charset-<charset>

       which should contain a command creating an environment  to
       render the character set.  This command string should con-
       taining a single "%s", which will be  filled-in  with  the
       command to display the content.

       Example entries might be:

            mhn-charset-iso-8859-1: xterm -fn '-*-*-medium-r-nor-
            mal-*-*-120-*-*-c-*-iso8859-*' -e %s
       or
            mhn-charset-iso-8859-1: '%s'

       The first example tells mhn to start xterm  and  load  the
       appropriate  character  set for that message content.  The
       second example tells mhn that your pager (or other program
       handling that content type) can handle that character set,
       and that no special processing is needed beforehand.

       Note that many pagers strip off the high-order bit or have
       problems  displaying  text  with  the  high-order bit set.
       However, the pager less has support for single-octet char-
       acter  sets.   The source to less is available on many ftp
       sites carrying free software.  In order to  view  messages
       sent in the ISO-8859-1 character set using less, put these
       lines in your .login file:

            setenv LESSCHARSET latin1
            setenv LESS "-f"

       The first line tells less to use the ISO-8859-1 definition
       for  determing whether a character is "normal", "control",
       or "binary".  The second line tells less not to  warn  you
       if  it  encounters  a  file that has non-ASCII characters.

       Then, simply set the moreproc profile entry to  less,  and
       it  will  get called automatically.  (To handle other sin-
       gle-octet character sets,  look  at  the  less (1)  manual
       entry  for  information  about the LESSCHARDEF environment
       variable.)

   Storing the Contents
       The `-store' switch tells mhn to store the contents of the
       named  messages  in "native" (decoded) format.  Two things
       must be determined: the directory to  store  the  content,
       and  the  filenames.   Files  are written in the directory
       given by the mhn-storage profile entry, e.g.,

            mhn-storage: /tmp

       If this entry isn't present, the current working directory
       is used.

       If the `-auto' switch is given, then mhn will check if the
       message contains information indicating the filename  that
       should  be  used  to  store the content.  This information
       should be specified as the  attribute  "name=filename"  in
       the  Content-Type  header for the content you are storing.
       For security reasons, this filename will be ignored if  it
       begins  with the character '/', '.', '|', or '!', or if it
       contains the character '%'.  For  the  sake  of  security,
       this switch is not the default, and it is recommended that
       you do NOT put the  `-auto'  switch  in  your  .mh_profile
       file.

       If  the  `-auto'  switch is not given (or is being ignored
       for security reasons) then mhn will  look  in  the  user's
       profile  for  a  "formatting  string" to determine how the
       different contents should be stored.  First, mhn will look
       for an entry of the form:

            mhn-store-<type>/<subtype>

       to  determine the formatting string.  If this isn't found,
       mhn will look for an entry of the form:

            mhn-store-<type>

       to determine the formatting string.

       If the formatting string starts with a "+" character, then
       content  is  stored  in  the  named  folder.  A formatting
       string consisting solely of a "+" character is interpreted
       to be the current folder.

       If  the formatting string consists solely of a "-" charac-
       ter, then the content is sent to the standard output.

       If the formatting string starts with a '|', then the  dis-
       play  string  will  represent a command for mhn to execute
       which should ultimately store the  content.   The  content
       will  be  passed  to  the  standard  input of the command.
       Before the command is executed, mhn  will  change  to  the
       appropriate  directory,  and  any escapes (given below) in
       the display string will be expanded.

       Otherwise the formatting string will represent a  pathname
       in  which  to store the content.  If the formatting string
       starts with a '/', then the content will be stored in  the
       full  path  given,  else the file name will be relative to
       the value of mhn-storage or the current working directory.
       Any escapes (given below) will be expanded, except for the
       a-escape.

       A command or pathname formatting string  may  contain  the
       following  escapes.  If the content isn't part of a multi-
       part (of any subtype listed above) content, the  p-escapes
       are ignored.

            %a  Parameters from Content-type  (only valid with command)
            %m  Insert message number
            %P  Insert part number with leading dot
            %p  Insert part number without leading dot
            %t  Insert content type
            %s  Insert content subtype
            %%  Insert character %

       If no formatting string is found, mhn will check to see if
       the content  is  application/octet-stream  with  parameter
       "type=tar".   If  so, mhn will choose an appropriate file-
       name.  If the  content  is  not  application/octet-stream,
       then  mhn  will  check to see if the content is a message.
       If so, mhn will use the value "+".  As a last resort,  mhn
       will use the value "%m%P.%s".

       Example profile entries might be:

            mhn-store-text: %m%P.txt
            mhn-store-audio/basic: | raw2audio -e ulaw -s 8000 -c 1 > %m%P.au
            mhn-store-application/PostScript: %m%P.ps

       Further,  note that when asked to store a content contain-
       ing a partial message, mhn will try to locate all  of  the
       portions and combine them accordingly.  Thus, if someone's
       sent you a message in several parts, you  might  put  them
       all in their own folder and do:

            mhn all -store

       This will store exactly one message, containing the sum of
       the parts.  Note that if mhn can not locate each part,  it
       will not store anything.

   External Access
       For  contents  of type message/external-body, mhn supports
       these access-types:

            afs
            anon-ftp
            ftp
            local-file
            mail-server

       For the "anon-ftp" and "ftp" access types, mhn  will  look
       for the mhn-access-ftp profile entry, e.g.,

            mhn-access-ftp: myftp.sh

       to  determine the pathname of a program to perform the FTP
       retrieval.  This program is invoked with these arguments:

            domain name of FTP-site
            username
            password
            remote directory
            remote filename
            local filename
            "ascii" or "binary"

       The program should terminate with an exit status  of  zero
       if the retrieval is successful, and a non-zero exit status
       otherwise.

       If this entry is not provided, then mhn will use a  simple
       built-in FTP client to perform the retrieval.

   The Content Cache
       When mhn encounters an external content containing a "Con-
       tent-ID:" field, and if the content allows  caching,  then
       depending  on  the  caching  behavior  of mhn, the content
       might be read from or written to a cache.

       The  caching  behavior  of  mhn  is  controlled  with  the
       `-rcache'  and `-wcache' switches, which define the policy
       for reading from, and writing to, the cache, respectively.
       One  of four policies may be specified: "public", indicat-
       ing that mhn should make use  of  a  publically-accessible
       content  cache; "private", indicating that mhn should make
       use of the user's private content cache; "never", indicat-
       ing that mhn should never make use of caching; and, "ask",
       indicating that mhn should ask the user.

       There are two directories where contents  may  be  cached:
       the  profile  entry mhn-cache names a directory containing
       world-readable contents, and, the profile  entry  mhn-pri-
       vate-cache  names a directory containing private contents.

       The former should be an absolute (rooted) directory  name.
       For example,

            mhn-cache: /tmp

       might  be used if you didn't care that the cache got wiped
       after each reboot of the system.   The  latter  is  inter-
       preted  relative  to  the  user's  nmh  directory,  if not
       rooted, e.g.,

            mhn-private-cache: .cache

       (which is the default value).

   Caching the Contents
       When you encounter a content of type message/external-body
       with  access  type  "mail-server", mhn will ask you if may
       send a message to a mail-server  requesting  the  content,
       e.g.,

            % show 1
            Retrieve content by asking mail-server@...

            SEND file

            ? yes
            mhn: request sent

       Regardless  of  your decision, mhn can't perform any other
       processing on the content.

       However, if mhn is allowed to request  the  content,  then
       when it arrives, there should be a top-level "Content-ID:"
       field which corresponds to the value in the original  mes-
       sage/external-body   content.   You  should  now  use  the
       `-cache' switch to tell mhn to enter the arriving  content
       into the content cache, e.g.,

            % mhn -cache 2
            caching message 2 as file ...

       You can then re-process the original message/external-body
       content, and "the right thing should happen", e.g.,

            % show 1
             ...

   Sending Files via Mail
       When you want to send a bunch of files to someone, you can
       run the viamail shell script, which is similar the tarmail
       command:

            /usr/lib/nmh/viamail mailpath "subject" files ...

       viamail will archive the directories/files you  name  with
       tar (1),  and  then  mail  the  compressed  archive to the
       `mailpath' with the given `subject'.  The archive will  be
       automatically  split up into as many messages as necessary
       in order to get past most mailers.

       Sometimes you want viamail to pause after posting  a  par-
       tial  message.  This is usually the case when you are run-
       ning sendmail and expect to generate a lot of partial mes-
       sages.  If the first argument given to viamail starts with
       a dash, then it is interpreted as the number of seconds to
       pause in between postings, e.g.,

            /usr/lib/nmh/viamail    -300    mailpath    "subject"
            files ...

       will pause 5 minutes in between each posting.

       When these messages are received, invoke  mhn  once,  with
       the  list  of messages, and the `-store' command.  The mhn
       program will then store exactly one message containing the
       archive.   You  can  then  use  `-show' to find out what's
       inside;  possibly   followed  by  `-store'  to  write  the
       archive  to  a  file where you can subsequently uncompress
       and untar it, e.g.,

            % mhn -list all
             msg part  type/subtype             size description
               1       message/partial           47K part 1 of 4
               2       message/partial           47K part 2 of 4
               3       message/partial           47K part 3 of 4
               4       message/partial           18K part 4 of 4
            % mhn -store all
            % mhn -list -verbose last
             msg part  type/subtype             size description
               5       application/octet-stream 118K
                         (extract with uncompress | tar xvpf -)
                         type=tar
                         conversions=compress
            % mhn -show last
             msg part  type/subtype             size description
               5       application/octet-stream 118K
            -- headers of message, followed by tar listing appears here
            % mhn -store last
            % uncompress < 5.tar.Z | tar xvpf -

       Alternately, by using the `-auto' switch, mhn  will  auto-

       matically do the extraction for you, e.g.,

            % mhn -list all
             msg part  type/subtype             size description
               1       message/partial           47K part 1 of 4
               2       message/partial           47K part 2 of 4
               3       message/partial           47K part 3 of 4
               4       message/partial           18K part 4 of 4
            % mhn -store all
            % mhn -list -verbose last
             msg part  type/subtype             size description
               5       application/octet-stream 118K
                         (extract with uncompress | tar xvpf -)
                         type=tar
                         conversions=compress
            % mhn -show last
             msg part  type/subtype             size description
               5       application/octet-stream 118K
            -- headers of message, followed by tar listing appears here
            % mhn -store -auto last
            -- tar listing appears here as files are extracted

       As  the  second  tar  listing  is generated, the files are
       extracted.  A prudent user will never put `-auto'  in  the
       .mh_profile  file.   The correct procedure is to first use
       `-show', to find out what will be extracted.  Then mhn can
       be  invoked  with   `-store'  and  `-auto'  to perform the
       extraction.

   User Environment
       Because the display environment in which mhn operates  may
       vary  for  different machines, mhn will look for the envi-
       ronment variable $MHN.  If  present,  this  specifies  the
       name  of  an additional user profile which should be read.
       Hence, when a user logs in on a particular display device,
       this environment variable should be set to refer to a file
       containing  definitions  useful  for  the  given   display
       device.  Normally, only entries that deal with the methods
       to display different content type and subtypes

            mhn-show-<type>/<subtype>
            mhn-show-<type>

       need be present in this additional profile.  Finally,  mhn
       will attempt to consult one other additional user profile,
       e.g.,

            /etc/nmh/mhn.defaults

       which is created automatically during nmh installation.

FILES
       $HOME/.mh_profile                    The user profile

       $MHN                                 Additional profile entries
       /etc/nmh/mhn.defaults                System-default profile entries
       /etc/nmh/mhl.headers                 The headers template

PROFILE COMPONENTS
       Path:                To determine the user's nmh directory
       Current-Folder:      To find the default current folder
       mhlproc:             Default program to display message headers
       mhn-access-ftp:      Program to retrieve contents via FTP
       mhn-cache            Public directory to store cached external contents
       mhn-charset-<charset>Template for environment to render character sets
       mhn-private-cache    Personal directory to store cached external contents
       mhn-show-<type>*     Template for displaying contents
       mhn-storage          Directory to store contents
       mhn-store-<type>*    Template for storing contents
       moreproc:            Default program to display text/plain content

SEE ALSO
       mhbuild(1) mhl(1) 
       RFC-934:
          Proposed Standard for Message Encapsulation,
       RFC-2045:
       Multipurpose Internet Mail Extensions(MIME) Part One: 
          Format of Internet Message Bodies,
       RFC-2046:
       Multipurpose Internet Mail Extensions(MIME) Part Two: 
          Media Types,
       RFC-2047:
       Multipurpose Internet Mail Extensions(MIME) Part 
       Three:
          Message Header Extensions for Non-ASCII Text,
       RFC-2048:
       Multipurpose Internet Mail Extensions(MIME) Part Four: 
          Registration Procedures,
       RFC-2049:
       Multipurpose Internet Mail Extensions(MIME) Part Five: 
          Conformance Criteria and Examples.

DEFAULTS
       `+folder' defaults to the current folder
       `msgs' defaults to cur
       `-noauto'
       `-nocache'
       `-nocheck'
       `-form mhl.headers'
       `-headers'
       `-pause'
       `-rcache ask'
       `-realsize'
       `-noserialonly'
       `-show'
       `-noverbose'
       `-wcache ask'

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

BUGS
       Partial  messages contained within a multipart content are
       not reassembled with the `-store' switch.

mhmail Home Page User Commands Index mhparam