Storing the Contents¶

The mhstore will 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.

By default (or if the -auto switch is given), mhstore uses filename information, contained in the message, if available. (This information should be specified as the attribute `name=filename' in the `Content-Type' header for the content you are storing.) Only the basename of this filename is considered. If it begins with the character '.', '|', or '!', or if it contains the character '%', automatic naming won't happen for security reasons. (See below for the fall-back.)

Files are written in the directory given by the `nmh-storage' profile entry, e.g.,

(Note that `nmh-storage' is relative to the folder that contains the message.) If this entry isn't present, the current working directory is used. Attachments will get stored in either the `nmh-storage' or the current working directory – in no case elsewhere. Existing files get silently overwritten.

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

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

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 `-' character, then the content is sent to the standard output.

If the formatting string starts with a '|', then the display string will represent a command for mhstore 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, mhstore 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 either the value of `nmh-storage', if set, or the current working directory. Existing files get silently overwritten.

A command or pathname formatting string may contain the following escapes. If the content isn't part of a multipart (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, mhstore will check to see if the content is a message. If so, mhstore will use the value `+'. As a last resort, mhstore will use the value `%m%P.%s'.

Example profile entries might be:

mhstore-store-text: %m%P.txt
mhstore-store-text: +inbox
mhstore-store-message/partial: +
mhstore-store-audio/basic: | raw2audio -e ulaw -s 8000 -c 1 > %m%P.au
mhstore-store-image/jpeg: %m%P.jpg
mhstore-store-application/PostScript: %m%P.ps

Reassembling Messages of Type message/partial¶

mhstore is also able to reassemble messages that have been split into multiple messages of type `message/partial'.

When asked to store a content containing a partial message, mhstore will try to locate all of the portions and combine them accordingly. The default is to store the combined parts as a new message in the current folder, although this can be changed using formatting strings as discussed above. Thus, if someone has sent you a message in several parts (such as the output from sendfiles), you can easily reassemble them all into a single message in the following fashion:

% mhlist 5-8


 msg part  type/subtype             size description


   5       message/partial           47K part 1 of 4


   6       message/partial           47K part 2 of 4


   7       message/partial           47K part 3 of 4


   8       message/partial           18K part 4 of 4
% mhstore 5-8
reassembling partials 5,6,7,8 to folder inbox as message 9
% mhlist 9


 msg part  type/subtype             size description


   9       application/octet-stream 118K


             (extract with uncompress | tar xvpf -)


             type=tar


             conversions=compress

This will store exactly one message, containing the sum of the parts. It doesn't matter whether the partials are specified in order, since mhstore will sort the partials, so that they are combined in the correct order. But if mhstore can not locate every partial necessary to reassemble the message, it will not store anything.

External Access¶

Mhstore does not automatically retrieve message/external-body parts (anymore), but prints the relevant information to enable the user to retrieve the files manually.

User Environment¶

Because the display environment in which mhstore operates may vary for different machines, mhstore will look for the environment variable $MHSTORE. If present, this specifies the name of an additional user profile which should be read. Hence, when a user logs in on a particular machine, this environment variable should be set to refer to a file containing definitions useful for that machine. Finally, mhstore will attempt to consult one other additional user profile, e.g.,

which is created automatically during mmh installation.