Laird Breyer wrote:
Because the mbox file format is not well defined, any incidental
reformatting of an attached mbox file during mail transport would be
harmful.
Specifically, From stuffing and any special treatment of control
characters can cause problems with delimiters. In the specific
case of a Content-Length delimiter, *any* change to the content
which changes its length (e.g. adding or removing trailing
whitespace on lines) will cause problems.
So it seems to me that an mbox media type should always require a
protective content encoding, either QP or Base64.
Perhaps.
Of those two encodings, Base64 seems much preferable, because the QP
encoding can allow the mbox format delimiters (From_) to stay
unencoded.
Note that "From" is valid base64 output and that transport can
result in addition of trailing whitespace.
This could make proper parsing of, e.g. a QP encoding of
an mbox file attached to a message saved in an mbox archive,
needlessly difficult for common tools such as e.g. formail, especially
if the tool happens to be not MIME aware.
I'm not sure I understand your point; processing of an attached
media type has several prerequisites:
1. a user indicates that processing may proceed (N.B. no
automatic execution!)
2. a MIME-aware application decodes any transfer encoding &
extracts the attachment
3. some application capable of processing the content -- it
need not be MIME-aware
The MIME-aware application (typically a MUA) may pass
additional information (from parameters) to the media-
specific application