#### 3.9.3 Purpose and caveats of `decodemail`. ¶

The principal use envisioned for this program is to decode messages in batch, after they are received.

Unfortunately, some mailers prefer to encode messages in their entirety in base64 (or quoted-printable), even when the content is entirely human-readable text. This makes straightforward use of `grep` or other standard commands impossible. The idea is for `decodemail` to rectify that, by making the message text readable again.

Besides personal mail, mailing list archives are another place where such decoding can be useful, as they are often searched with standard tools.

It is generally not recommended to run `decodemail` within a mail reader (which should be able to do the decoding itself), or directly in a terminal (since quite possibly there will be 8-bit output not in the current character set).

Although the output message from `decodemail` should be entirely equivalent to the input message, apart from the decoding, it is generally not identical. Because `decodemail` parses the input message and reconstructs it for output, there are usually small differences:

- In the envelope ‘`From` ’ line, multiple spaces are collapsed to one.
- A ‘`Content-Transfer-Encoding:`’ header may be added where not previously present, or its value changed from ‘`8bit`’ to ‘`7bit`’, or vice versa. This may happen both for the message as a whole, and for a given mime part. `decodemail` looks at the actual content of the text and outputs ‘`Content-Transfer-Encoding:`’ accordingly.
- A trailing space is inserted when a long header line is broken to occupy several lines (header wrapping).

      SomeHeader:
        someextremelylongvaluethatcannotbebroken

- The non-tracing headers may be reordered, notably those that are mime-related.
- Any material before the first mime part of a mime multipart message is lost. By the standards, nothing should appear there. Typically if it does appear, it is a string such as ‘`This is a multi-part message in MIME format.`’.
- In mime parts, the charset specifications may no longer be quoted (if quoting is not necessary). For example, ‘`charset="utf-8"`’ becomes ‘`charset=utf-8`’.
- The mime boundary strings will be changed.

If a discrepancy is created which actually affects message parsing or reading, that’s most likely a bug, and please report it. Naturally, please send an exact input message to reproduce the problem.