In <20040825030307(_dot_)GA9134(_at_)ender> Laird Breyer
<laird(_at_)lbreyer(_dot_)com> writes:
It is one thing to send an mbox file to somebody, who saves it to disk
as a separate file, which can be opened/read/written, or
converted/imported to another format etc. This sort of thing has been
done in the past, and works quite well by using
application/octet-stream.
However, unlike MIME, mbox is not a recursive format. It is a linear
list of "blobs'. Thus if you send an mbox attachment without encoding
the delimiters within the attachment (ie the "From_" lines etc.), then
the common practice of appending such a message to the mail spool file
can automatically destroy the original structure.
Not necessarily. The system that received the mail (containing the
application/mbox embedded within it) will presumably '>'-stuff all the
"From " lines before delivering it to its own mbox (or alternatively it
will insert a Content-Length header). A system that does not do one of
these things when delivering messages to its mbox is already severely
broken.
However, when you come to read the message with a view to extracting the
individual messages within the embedded mbox, then you find it has been
corrupted by all the '>' stuffing :-( . So you have to try to reverse the
stuffing, which may give rise to other errors.
So maybe you are right, that these things SHOULD/MUST always be base64
encoded.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave,
CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5