X-Git-Url: https://diplodocus.org/git/nmh/blobdiff_plain/b36e2ab7892cdf30a8b33d02e00af70398013b5d..c576ad2674c37a1c63f004c71049998f38854c64:/man/mhstore.man diff --git a/man/mhstore.man b/man/mhstore.man index b7f8a5e2..ac66b86b 100644 --- a/man/mhstore.man +++ b/man/mhstore.man @@ -1,71 +1,122 @@ -.\" +.TH MHSTORE %manext1% 2015-02-06 "%nmhversion%" +. .\" %nmhwarning% -.\" $Id$ -.\" -.\" include the -mh macro file -.so %etcdir%/tmac.h -.\" -.TH MHSTORE %manext1% "%nmhdate%" MH.6.8 [%nmhversion%] +. .SH NAME -mhstore \- store contents of MIME messages into files +mhstore \- store contents of nmh MIME messages into files .SH SYNOPSIS -.in +.5i -.ti -.5i -mhstore \%[+folder] \%[msgs] \%[\-file file] -.br -\%[\-part number]... \%[\-type content]... -.br -\%[\-auto] \%[\-noauto] -\%[\-check] \%[\-nocheck] -.br -\%[\-rcache policy] \%[\-wcache policy] -.br -\%[\-verbose] \%[\-noverbose] -\%[\-version] -\%[\-help] -.in -.5i - +.HP 5 +.na +.B mhstore +.RB [ \-help ] +.RB [ \-version ] +.RI [ +folder ] +.RI [ msgs ] +.RB [ \-file +.IR file ] +.RB [ \-outfile +.IR outfile ] +.RB [ \-part +.IR number ] +\&... +.RB [ \-type +.IR content ] +\&... +.RB [ \-prefer +.IR content ] +\&... +.RB [ \-noprefer ] +.RB [ \-auto " | " \-noauto ] +.RB [ \-clobber +.IR always " | " auto " | " suffix " | " ask " | " never ] +.RB [ \-rcache +.IR policy ] +.RB [ \-wcache +.IR policy ] +.RB [ \-check " | " \-nocheck ] +.RB [ \-verbose " | " \-noverbose ] +.ad .SH DESCRIPTION -The \fImhstore\fR command allows you to store the contents of a -collection of MIME (multi-media) messages into files or other -messages. - -\fImhstore\fR manipulates multi-media messages as specified in -RFC\-2045 thru RFC\-2049. - -By default, \fImhstore\fR will store all the parts of each message. -Each part will be store in a separate file. The header fields of -the message are not stored. By using the `\-part' and `\-type' -switches, you may limit the scope of \fImhstore\fR to particular -subparts (of a multipart content) and/or particular content types. - -The option `\-file\ file' directs \fImhstore\fR to use the specified -file as the source message, rather than a message from a folder. -If you specify this file as \*(lq-\*(rq, then \fImhstore\fR 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 \fInmh\fR message. It should \fBNOT\fR -be in mail drop format (to convert a file in mail drop format to -a folder of \fInmh\fR messages, see \fIinc\fR\0(1)). - +The +.B mhstore +command allows you to store the contents of a collection of MIME +(multi-media) messages into files or other messages. +.PP +.B mhstore +manipulates multi-media messages as specified in RFC 2045 to RFC 2049. +.PP +By default, +.B mhstore +will store all the parts of each message. +Each part will be stored in a separate file. The header fields of +the message are not stored. By using the +.BR \-part , +.BR \-type , +and +.B \-prefer +switches, you may limit and reorder the set of parts to be stored, +based on part number and/or content type. +.PP +The +.B \-file +.I file +switch directs +.B mhstore +to use the specified file as the source message, rather than a message +from a folder. If you specify this file as \*(lq-\*(rq, then +.B mhstore +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 +.B nmh +message. It should +.I not +be in mail drop format (to convert a file in +mail drop format to a folder of +.B nmh +messages, see +.IR inc (1)). +.PP 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. - +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 +.B \-part +switch is effective only for messages containing a multipart content. +If a message has some other kind of content, or if the part is itself +another multipart content, the +.B \-part +switch will not prevent the content from being acted upon. +.PP +The +.B \-type +switch can also be used to restrict (or, when used in conjunction with +.BR \-part , +to further restrict) the selection of parts according to content type. +One or more +.B \-type +switches part will only select the first match from a +multipart/alternative, even if there is more than one +subpart that matches (one of) the given content type(s). +.PP +Using either +.B \-part +or +.B -type +switches alone will cause either to select the part(s) they match. +Using them together will select only the part(s) matched by both +(sets of) switches. In other words, the result is the intersection, +and not the union, of their separate match results. +.PP A content specification consists of a content type and a subtype. -The initial list of \*(lqstandard\*(rq content types and subtypes -can be found in RFC\-2046. -.ne 18 +The initial list of \*(lqstandard\*(rq content types and subtypes can +be found in RFC 2046. +.PP A list of commonly used contents is briefly reproduced here: -.sp +.PP +.RS 5 .nf -.in +.5i .ta \w'application 'u Type Subtypes ---- -------- @@ -76,150 +127,286 @@ application octet-stream, postscript image jpeg, gif, png audio basic video mpeg -.re -.in -.5i .fi -.sp +.RE +.PP A legal MIME message must contain a subtype specification. .PP To specify a content, regardless of its subtype, just use the name of the content, e.g., \*(lqaudio\*(rq. To specify a specific subtype, separate the two with a slash, e.g., \*(lqaudio/basic\*(rq. -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. - -.Uh "Checking the Contents" -The `\-check' switch tells \fImhstore\fR to check each content for -an integrity checksum. If a content has such a checksum (specified -as a Content-MD5 header field), then \fImhstore\fR will attempt to -verify the integrity of the content. - -.Uh "Storing the Contents" -The \fImhstore\fR will store the contents of the named messages in +Note that regardless of the values given to the +.B \-type +switch, a multipart content (of any subtype listed above) is always acted +upon. Further note that if the +.B \-type +switch is used, and it is desirable to act on a message/external-body +content, then the +.B \-type +switch must be used twice: once for message/external-body and once for +the content externally referenced. +.PP +The +.B \-prefer +switch will alter the part-ordering of multipart/alternative MIME sections +in order to override the sender-imposed default ordering. +The +.B \-prefer +switch is functionally most important for +.BR mhshow , +but is also implemented in +.B mhlist +and +.B mhstore +to make common part-numbering possible across all three programs. +The last of multiple +.B \-prefer +switches will have the highest priority. This allows the command line +switches to override profile entries. +See +.IR mhlist (1) +and +.IR mhshow (1) +for more information on +.BR \-prefer . +.PP +The +.B \-noprefer +switch will cancel any previous +.B \-prefer +switches. +.SS "Checking the Contents" +The +.B \-check +switch tells +.B mhstore +to check each content for an integrity checksum. +If a content has such a checksum (specified as a Content-MD5 header +field), then +.B mhstore +will attempt to verify the integrity of the content. +.SS "Storing the Contents" +.B mhstore +will store the contents of the named messages in \*(lqnative\*(rq (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 \fBnmh-storage\fR profile -entry, -.ne 6 -e.g., -.sp -.in +.5i +the directory in which to store the content, and the filenames. +Files are written in the directory given by the +\*(lqnmh-storage\*(rq profile entry, e.g., +.PP +.RS 5 nmh-storage: /tmp -.in -.5i -.sp -If this entry isn't present, -the current working directory is used. - -If the `\-auto' switch is given, then \fImhstore\fR 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 \*(lqname=filename\*(rq 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\(ruprofile file. - -If the `\-auto' switch is not given (or is being ignored for security -reasons) then \fImhstore\fR will look in the user's profile for a -\*(lqformatting string\*(rq to determine how the different contents -should be stored. First, \fImhstore\fR will look for an entry of -the form: -.sp -.in +.5i +.RE +.PP +If this entry isn't present, the current working directory is used. +.PP +If the +.B \-outfile +switch is given, its argument is used for the filename to store all +of the content, with \*(lq-\*(rq indicating standard output. If the +.B \-auto +switch is given, then +.B mhstore +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 \*(lqfilename\*(rq attribute in the +\*(lqContent-Disposition\*(rq header or as the \*(lqname\*(rq +attribute in the \*(lqContent-Type\*(rq 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 '%'. We also recommend using a \*(lqnmh-storage\*(rq profile +entry or a +.B \-clobber +switch setting other than the default of \*(lqalways\*(rq to avoid +overwriting existing files. +.PP +If the +.B \-auto +switch is not given (or is being ignored for security reasons) then +.B mhstore +will look in the user's profile for a \*(lqformatting string\*(rq to +determine how the different contents should be stored. First, +.B mhstore +will look for an entry of the form: +.PP +.RS 5 mhstore-store-/ -.in -.5i -.sp -to determine the formatting string. If this isn't found, \fImhstore\fR +.RE +.PP +to determine the formatting string. If this isn't found, +.B mhstore will look for an entry of the form: -.sp -.in +.5i +.PP +.RS 5 mhstore-store- -.in -.5i -.sp +.RE +.PP to determine the formatting string. - +.PP If the formatting string starts with a \*(lq+\*(rq character, then content is stored in the named folder. A formatting string consisting solely of a \*(lq+\*(rq character is interpreted to be the current folder. - +.PP If the formatting string consists solely of a \*(lq-\*(rq 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 \fImhstore\fR 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, -\fImhstore\fR 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 +.PP +If the formatting string starts with a '|', then it represents +a command for +.B 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, +.B mhstore +will change to the appropriate directory, and any escapes (given below) +in the formatting string will be expanded. +The use of the \*(lq%a\*(rq sequence is not recommended because +the user has no control over the Content-Type parameter data. +.PP +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 \fBnmh-storage\fR or +file name will be relative to the value of \*(lqnmh-storage\*(rq or the current working directory. Any escapes (given below) will be -expanded, except for the a-escape. - +expanded, except for the a-escape. Note that if \*(lqnmh-storage\*(rq +is not an absolute path, it will be relative to the folder that +contains the message(s). +.PP 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. -.sp +.PP +.RS 5 .nf -.in +.5i .ta \w'%P 'u -%a Parameters from Content-type (only valid with command) +%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 % -.re -.in -.5i .fi -.sp -If no formatting string is found, \fImhstore\fR will check to see -if the content is application/octet-stream with parameter -\*(lqtype=tar\*(rq. If so, \fImhstore\fR will choose an appropriate -filename. If the content is not application/octet-stream, then -\fImhstore\fR will check to see if the content is a message. If -so, \fImhstore\fR will use the value \*(lq+\*(rq. As a last resort, -\fImhstore\fR will use the value \*(lq%m%P.%s\*(rq. - -.ne 10 +.RE +.PP +If no formatting string is found, +.B mhstore +will check to see if the content is application/octet-stream with parameter +\*(lqtype=tar\*(rq. If so, +.B mhstore +will choose an appropriate filename. If the content is not +application/octet-stream, then +.B mhstore +will check to see if the content is a message. If so, +.B mhstore +will use the value \*(lq+\*(rq. As a last resort, +.B mhstore +will use the value \*(lq%m%P.%s\*(rq. +.PP Example profile entries might be: -.sp +.PP +.RS 5 .nf -.in +.5i 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 -.in -.5i .fi -.sp -.Uh "Reassembling Messages of Type message/partial" -\fImhstore\fR is also able to reassemble messages that have been +.RE +.PP +The +.B \-verbose +switch directs +.B mhstore +to print out the names of files that it stores. For backward +compatibility, it is the default. The +.B \-noverbose +switch suppresses these printouts. +.SS "Overwriting Existing Files" +The +.B \-clobber +switch controls whether +.B mhstore +should overwrite existing files. The allowed values for this switch +and corresponding behavior when +.B mhstore +encounters an existing file are: +.PP +.RS 5 +.nf +.ta \w'suffix 'u +always Overwrite existing file (default) +auto Create new file of form name-n.extension +suffix Create new file of form name.extension.n +ask Prompt the user to specify whether or not to overwrite + the existing file +never Do not overwrite existing file +.fi +.RE +.PP +With +.I auto +and +.IR suffix , +.I n +is the lowest unused number, starting from one, in the same form. If +a filename does not have an extension (following a '.'), then +.I auto +and +.I suffix +create a new file of the form +.I name-n +and +.IR name.n , +respectively. With +.I never +and +.IR ask , +the exit status of +.B mhstore +will be the number of files that were requested but not stored. +.PP +With +.IR ask , +if standard input is connected to a terminal, the user is prompted to +respond +.IR yes , +.IR no , +or +.IR rename , +to whether the file should be overwritten. The responses +can be abbreviated. If the user responds with +.IR rename , +then +.B mhstore +prompts the user for the name of the new file to be created. If it is +a relative path name (does not begin with '/'), then it is relative to +the current directory. If it is an absolute or relative path to a +directory that does not exist, the user will be prompted whether to +create the directory. If standard input is not connected to a +terminal, +.I ask +behaves the same as +.IR always . +.SS "Reassembling Messages of Type message/partial" +.B mhstore +is also able to reassemble messages that have been split into multiple messages of type \*(lqmessage/partial\*(rq. - +.PP When asked to store a content containing a partial message, -\fImhstore\fR 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 -\fIsendfiles\fR), you can easily reassemble them all into a single -message in the following fashion: -.sp +.B 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 +.BR sendfiles ), +you can easily reassemble them into a single message in the +following fashion: +.PP +.RS 5 .nf -.in +.5i % mhlist 5-8 msg part type/subtype size description 5 message/partial 47K part 1 of 4 @@ -234,47 +421,48 @@ reassembling partials 5,6,7,8 to folder inbox as message 9 (extract with uncompress | tar xvpf -) type=tar conversions=compress -.in -.5i .fi -.sp +.RE +.PP This will store exactly one message, containing the sum of the parts. It doesn't matter whether the partials are specified in -order, since \fImhstore\fR will sort the partials, so that they -are combined in the correct order. But if \fImhstore\fR can not -locate every partial necessary to reassemble the message, it will -not store anything. - -.Uh "External Access" +order, since +.B mhstore +will sort the partials, so that they are combined in the correct +order. But if +.B mhstore +can not locate every partial necessary to reassemble the message, +it will not store anything. +.SS "External Access" For contents of type message/external-body, -.ne 12 \fImhstore\fR supports these access-types: -.sp -.nf -.in +.5i +.IP \(bu 4 afs +.IP \(bu 4 anon-ftp +.IP \(bu 4 ftp +.IP \(bu 4 local-file +.IP \(bu 4 mail-server -.in -.5i -.fi -.sp +.IP \(bu 4 +url +.PP For the \*(lqanon-ftp\*(rq and \*(lqftp\*(rq access types, -\fImhstore\fR will look for the \fBnmh-access-ftp\fR -profile entry, -.ne 6 -e.g., -.sp -.in +.5i +.B mhstore +will look for the \*(lqnmh-access-ftp\*(rq +profile entry, e.g., +.PP +.RS 5 nmh-access-ftp: myftp.sh -.in -.5i -.sp +.RE +.PP to determine the pathname of a program to perform the FTP retrieval. -.ne 14 This program is invoked with these arguments: -.sp +.PP +.RS 5 .nf -.in +.5i domain name of FTP-site username password @@ -282,139 +470,164 @@ remote directory remote filename local filename \*(lqascii\*(rq or \*(lqbinary\*(rq -.in -.5i .fi -.sp +.RE +.PP 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 \fImhstore\fR will use a simple -built-in FTP client to perform the retrieval. - -.Uh "The Content Cache" -When \fImhstore\fR encounters an external content containing a +.PP +For the \*(lqurl\*(rq access types, +.B mhstore +will look for the \*(lqnmh-access-url\*(rq profile entry, e.g., +.PP +.RS 5 +nmh-access-url: curl -L +.RE +.PP +to determine the program to use to perform the HTTP retrieval. This program +is invoked with one argument: the URL of the content to retrieve. The program +should write the content to standard out, and should terminate with a status +of zero if the retrieval is successful and a non-zero exit status otherwise. +.SS "The Content Cache" +When +.B mhstore +encounters an external content containing a \*(lqContent-ID:\*(rq field, and if the content allows caching, then -depending on the caching behavior of \fImhstore\fR, the content might be -read from or written to a cache. - -The caching behavior of \fImhstore\fR 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: \*(lqpublic\*(rq, indicating that \fImhstore\fR should make use -of a publically-accessible content cache; \*(lqprivate\*(rq, indicating -that \fImhstore\fR should make use of the user's private content cache; -\*(lqnever\*(rq, indicating that \fImhstore\fR should never make use of -caching; and, \*(lqask\*(rq, indicating that \fImhstore\fR should ask -the user. - +depending on the caching behavior of +.BR mhstore , +the content might be read from or written to a cache. +.PP +The caching behavior of +.B mhstore +is controlled with the +.B \-rcache +and +.B \-wcache +switches, which define the policy for reading from, and writing to, the cache, +respectively. One of four policies may be +specified: \*(lqpublic\*(rq, indicating that +.B mhstore +should make use +of a publicly-accessible content cache; \*(lqprivate\*(rq, indicating that +.B mhstore +should make use of the user's private content cache; +\*(lqnever\*(rq, indicating that +.B mhstore +should never make use of caching; and, \*(lqask\*(rq, indicating that +.B mhstore +should ask the user. +.PP There are two directories where contents may be cached: the profile entry -\fBnmh-cache\fR names a directory containing world-readable contents, and, -the profile entry \fBnmh-private-cache\fR names a directory containing +\*(lqnmh-cache\*(rq names a directory containing world-readable contents, and, +the profile entry \*(lqnmh-private-cache\*(rq names a directory containing private contents. The former should be an absolute (rooted) directory name. -.ne 6 +.PP For example, -.sp -.in +.5i +.PP +.RS 5 nmh-cache: /tmp -.in -.5i -.sp +.RE +.PP might be used if you didn't care that the cache got wiped after each reboot of the system. The latter is interpreted relative to the user's -nmh directory, if not rooted, -.ne 6 -e.g., -.sp -.in +.5i +nmh directory, if not rooted, e.g., +.PP +.RS 5 nmh-private-cache: .cache -.in -.5i -.sp +.RE +.PP (which is the default value). - -.Uh "User Environment" -Because the environment in which \fImhstore\fR operates may vary -for different machines, \fImhstore\fR will look for the environment -variable \fB$MHSTORE\fR. If present, this specifies the name of -an additional user profile which should be read. Hence, when a -user logs in on a machine, this environment variable should be set -to refer to a file containing definitions useful for that machine. -Finally, \fImhstore\fR will attempt to consult one other additional -user profile, -.ne 6 -e.g., -.sp -.in +.5i -%etcdir%/mhn.defaults -.in -.5i -.sp -which is created automatically during nmh installation. -.Fi -^$HOME/\&.mh\(ruprofile~^The user profile +.SS "User Environment" +Because the environment in which +.B mhstore +operates may vary for different machines, +.B 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, +.B mhstore +will attempt to consult +.PP +.RS 5 +%nmhetcdir%/mhn.defaults +.RE +.PP +which is created automatically during +.B nmh +installation. +.PP +See "Profile Lookup" in +.IR mh-profile (5) +for the profile search order, and for how duplicate entries are treated. +.SH EXAMPLES +.SS Decoding RFC 2047-encoded file names +The improper RFC 2047 encoding of file name parameters can be replaced +with correct RFC 2231 encoding using +.BR mhfixmsg , +either permanently or ephemerally, e.g., +.PP +.RS +.nf +mhfixmsg -outfile - | mhstore -auto -clobber ask -file - +.fi +.RE +.PP +The +.BI \-clobber ask +is not necessary, though recommended to avoid silently overwriting an existing +file. +.SH FILES +.B mhstore +looks for additional profile files in multiple locations: absolute +pathnames are accessed directly, tilde expansion is done on usernames, +and files are searched for in the user's +.I Mail +directory as specified in their profile. If not found there, the directory +.RI \*(lq %nmhetcdir% \*(rq +is checked. +.PP +.fc ^ ~ +.nf +.ta \w'%nmhetcdir%/ExtraBigFileName 'u +^$HOME/.mh_profile~^The user profile ^$MHSTORE~^Additional profile entries -^%etcdir%/mhn.defaults~^System default MIME profile entries -.Pr +^%nmhetcdir%/mhn.defaults~^System default MIME profile entries +.fi +.SH "PROFILE COMPONENTS" +.fc ^ ~ +.nf +.ta 2.4i +.ta \w'ExtraBigProfileName 'u ^Path:~^To determine the user's nmh directory -.Ps ^Current\-Folder:~^To find the default current folder -.Ps ^nmh-access-ftp:~^Program to retrieve contents via FTP -.Ps +^nmh-access-url:~^Program to retrieve contents via HTTP ^nmh-cache~^Public directory to store cached external contents -.Ps ^nmh-private-cache~^Personal directory to store cached external contents -.Ps ^nmh-storage~^Directory to store contents -.Ps ^mhstore-store-*~^Template for storing contents -.Sa -mhbuild(1), mhlist(1), mhshow(1), sendfiles(1) -.br -RFC\-2045: -.br - \fIMultipurpose Internet Mail Extensions (MIME) Part One: -.br - Format of Internet Message Bodies\fR, -.br -RFC\-2046: -.br - \fIMultipurpose Internet Mail Extensions (MIME) Part Two: -.br - Media Types\fR, -.br -RFC\-2047: -.br - \fIMultipurpose Internet Mail Extensions (MIME) Part Three: -.br - Message Header Extensions for Non-ASCII Text\fR, -.br -RFC\-2048: -.br - \fIMultipurpose Internet Mail Extensions (MIME) Part Four: -.br - Registration Procedures\fR, -.br -RFC\-2049: -.br - \fIMultipurpose Internet Mail Extensions (MIME) Part Five: -.br - Conformance Criteria and Examples\fR. -.De -`+folder' defaults to the current folder -.Ds -`msgs' defaults to cur -.Ds -`\-noauto' -.Ds -`\-nocheck' -.Ds -`\-rcache ask' -.Ds -`\-wcache ask' -.Ds -`\-noverbose' -.Co +.fi +.SH "SEE ALSO" +.IR mhbuild (1), +.IR mhfixmsg (1), +.IR mhlist (1), +.IR mhshow (1), +.IR sendfiles (1) +.SH DEFAULTS +.nf +.RB ` +folder "' defaults to the current folder" +.RB ` msgs "' defaults to cur" +.RB ` \-noauto ' +.RB ` \-clobber\ always ' +.RB ` \-nocheck ' +.RB ` \-rcache\ ask ' +.RB ` \-wcache\ ask ' +.RB ` \-verbose ' +.SH CONTEXT If a folder is given, it will become the current folder. The last message selected will become the current message. -.Bu +.SH BUGS Partial messages contained within a multipart content are not reassembled. -.En