<arg choice="opt">
<option>-f charset</option>
</arg>
+ <arg choice="opt">
+ <option>-H|--host=hostname</option>
+ </arg>
<arg choice="opt">
<option>-d header</option>
</arg>
<arg choice="opt">
<option>-p header:param</option>
</arg>
+ <arg choice="opt">
+ <option>-r header</option>
+ </arg>
+ <arg choice="opt">
+ <option>-R header:param</option>
+ </arg>
+ <arg choice="opt">
+ <option>--remove-params=header</option>
+ </arg>
<arg choice="opt">
<option>-beit mask</option>
</arg>
<title>DESCRIPTION</title>
<para>
Mail users, especially in non-English countries, often find that mail
-messages arrived in different formats, with different content types, in
-different encodings and charsets. Usually it is good because it allows to use
-an appropriate format/encoding/whatever. Sometimes, though, some unification is
-desirable. For example, one may want to put mail messages into an archive,
-make HTML indices, run search indexer, etc. In such situations converting
-messages to text in one character set and skipping some binary attachments is
-much desirable.
+ messages arrived in different formats, with different content types, in
+ different encodings and charsets. Usually it is good because it allows to
+ use an appropriate format/encoding/whatever. Sometimes, though, some
+ unification is desirable. For example, one may want to put mail messages
+ into an archive, make HTML indices, run search indexer, etc. In such
+ situations converting messages to text in one character set and skipping
+ some binary attachments is much desirable.
</para>
<para>
</para>
<para>
- It is a program to decode MIME messages. The program expects one input file
-(either on the command line or on stdin) which is treated as an RFC822 message,
-and decoded to stdout. If the file is not an RFC822 message it is just piped to
-stdout as is. If the file is a simple RFC822 message it is just decoded as one
-part. If it is a MIME message with multiple parts ("attachments") all parts are
-decoded recursively. Decoding can be controlled by the command-line options.
+ This is a program to decode MIME messages. The program expects one input
+ file (either on command line or on stdin) which is treated as an RFC822
+ message, and decodes to stdout or an output file. If the file is not an
+ RFC822 message it is just copied to the output one-to-one. If the file is a
+ simple RFC822 message it is decoded as one part. If it is a MIME message
+ with multiple parts ("attachments") all parts are decoded. Decoding can be
+ controlled by command-line options.
</para>
<para>
- First, Subject and Content-Disposition headers are examined. If any of those
-exists, it is decoded according to RFC2047. Content-Disposition header is not
-decoded - only its "filename" parameter. Encoded header parameters violate
-the RFC, but widely deployed anyway, especially in the M$ Ophice GUI (often
-referred as "Windoze") world, where programmers are often ignorant lamers who
-never even heard about RFCs. Correct parameter encoding specified by RFC2231.
-This program decodes RFC2231-encoded parameters, too.
+ First, for every part the program removes headers and parameters listed with
+ -r and -R options. Then, Subject and Content-Disposition headers (and all
+ headers listed with -d and -p options) are examined. If any of those exists,
+ they are decoded according to RFC2047. Content-Disposition header is not
+ decoded - only its "filename" parameter. Encoded header parameters violate
+ the RFC, but widely deployed anyway by ignorant coders who never even heard
+ about RFCs. Correct parameter encoding specified by RFC2231. This program
+ decodes RFC2231-encoded parameters, too.
</para>
<para>
Then the body of the message (or the current part) is decoded. Decoding
-starts with looking at header Content-Transfer-Encoding. If the header
-specifies non-8bit encoding (usually base64 or quoted-printable), the body
-converted to 8bit. Then, if its content type is multipart (multipart/related or
-multipart/mixed, e.g) every part is recursively decoded. If it is not
-multipart, mailcap database is consulted to find a way to convert the body to
-plain text. (I have no idea how mailcap could be configured on said M$ Ophice
-GUI, please don't ask me; real OS users can consult my example at
-<ulink url="http://phdru.name/Software/dotfiles/mailcap.html">http://phdru.name/Software/dotfiles/mailcap.html</ulink>).
-The decoding process uses first copiousoutput filter it can find. If there is
-no any filter the body just passed unconverted.
+ starts with looking at header Content-Transfer-Encoding. If the header
+ specifies non-8bit encoding (usually base64 or quoted-printable), the body
+ converted to 8bit. Then, if its content type is multipart (multipart/related
+ or multipart/mixed, e.g) every part is recursively decoded. If it is not
+ multipart, mailcap database is consulted to find a way to convert the body
+ to plain text. (I have no idea how mailcap can be configured on OSes other
+ than POSIX, please don't ask me; real OS users can consult my example at
+ <ulink url="http://phdru.name/Software/dotfiles/mailcap.html">http://phdru.name/Software/dotfiles/mailcap.html</ulink>).
+ The decoding process uses the first copiousoutput filter it can find. If
+ there are no filters the body just passed as is.
</para>
<para>
- Then Content-Type header consulted for charset. If it is not equal to
-current default charset the body text recoded. Finally message headers and body
-flushed to stdout.
+ Then Content-Type header is consulted for charset. If it is not equal to the
+ current locale charset and recoding is allowed the body text is recoded.
+ Finally message headers and the body are flushed to stdout.
</para>
</refsect1>
<term>-c</term>
<listitem>
<para>
- Recode different character sets in message body to current default
- charset; this is the default.
+ Recode different character sets in message bodies to the current
+ default charset; this is the default.
</para>
</listitem>
</varlistentry>
<term>-C</term>
<listitem>
<para>
- Do not recode character sets in message body.
+ Do not recode character sets in message bodies.
</para>
</listitem>
</varlistentry>
</listitem>
</varlistentry>
+ <varlistentry>
+ <term>-H hostname</term>
+ <term>--host=hostname</term>
+ <listitem>
+ <para>
+ Use this hostname in X-MIME-Autoconverted headers instead of the
+ current hostname.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term>-d header</term>
<listitem>
<para>
Add the header to a list of headers to decode; initially the list
- contains headers "From" and "Subject".
+ contains headers "From", "To", "Cc", "Reply-To", "Mail-Followup-To"
+ and "Subject".
</para>
</listitem>
</varlistentry>
<term>-p header:param</term>
<listitem>
<para>
- Add the (header, param) pair to a list of headers' parameters to
- decode; initially the list contains header "Content-Disposition",
- parameter "filename".
+ Add the pair (header, param) to a list of headers parameters to
+ decode; initially the list contains header "Content-Type",
+ parameter "name" and header "Content-Disposition", parameter
+ "filename".
</para>
</listitem>
</varlistentry>
<term>-P</term>
<listitem>
<para>
- Clear the list of headers' parameters to decode (make it empty).
+ Clear the list of headers parameters to decode (make it empty).
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>-r header</term>
+ <listitem>
+ <para>
+ Add the header to a list of headers to remove completely; initially
+ the list is empty.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>-R header:param</term>
+ <listitem>
+ <para>
+ Add the pair (header, param) to a list of headers parameters to
+ remove; initially the list is empty.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>--remove-params=header</term>
+ <listitem>
+ <para>
+ Add the header to a list of headers from which all parameters will
+ be removed; initially the list is empty.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
- The 4 list options (-beit) require more explanation. They allow a user
-to control body decoding with great flexibility. Think about said mail
-archive; for example, its maintainer wants to put there only texts, convert
-Postscript/PDF to text, pass HTML and images as is, and ignore everything
-else. Easy:
+ The 4 list options (-beit) require more explanation. They allow a user to
+ control body decoding with great flexibility. Think about said mail archive;
+ for example, its maintainer wants to put there only texts, convert
+ Postscript/PDF to text, pass HTML and images as is, and ignore everything
+ else. Easy:
</para>
<para>
</para>
<para>
- When the program decodes a message (or its part), it consults
-Content-Type header. The content type is searched in all 4 lists, in order
-"text-binary-ignore-error". If found, appropriate action performed. If not
-found, the program search the same lists for "type/*" mask (the type of
-"text/html" is just "text"). If found, appropriate action performed. If not
-found, the program search the same lists for "*/*" mask. If found,
-appropriate action performed. If not found, the program uses default
-action, which is to decode everything to text (if mailcap specifies
-a filter).
+ When the program decodes a message (non-MIME or a non-multipart subpart of a
+ MIME message), it consults Content-Type header. The content type is searched
+ in all 4 lists, in order "text-binary-ignore-error". If found, appropriate
+ action performed. If not found, the program search the same lists for
+ "type/*" mask (the type of "text/html" is just "text"). If found,
+ appropriate action performed. If not found, the program search the same
+ lists for "*/*" mask. If found, appropriate action performed. If not found,
+ the program uses default action, which is to decode everything to text (if
+ mailcap specifies a filter).
</para>
<para>
<title>BUGS</title>
<para>
The program may produce incorrect MIME message. The purpose of the program
-is to decode whatever it is possible to decode, not to produce absolutely
-correct MIME output. The incorrect parts are obvious - decoded Subject headers
-and filenames. Other than that output is correct MIME message. The program does
-not try to guess whether the headers are correct. For example, if a message
-header states that charset is iso8859-5, but the body is actually in koi8-r -
-the program will recode the message to the wrong charset.
+ is to decode whatever it is possible to decode, not to produce absolutely
+ correct MIME output. The incorrect parts are obvious - decoded
+ From/To/Cc/Reply-To/Mail-Followup-To/Subject headers and filenames. Other
+ than that output is correct MIME message. The program does not try to guess
+ whether the headers are correct. For example, if a message header states
+ that charset is iso8859-5, but the body is actually in utf-8 the program
+ will recode the message with the wrong charset.
</para>
</refsect1>