In <9412200150(_dot_)AA27967(_at_)femail(_dot_)NeXT(_dot_)COM> Dan Grillo
<Dan_Grillo(_at_)next(_dot_)com> writes:
hansen(_at_)pegasus(_dot_)att(_dot_)com writes:
For those of you who try and handle a CTE of uuencode or x-uuencode: What d
o
you do with the extra information that uuencode has in its header? Do you
just ignore it? Or do you blindly pass the content body to the uudecode
program? And when you generate it, what do you put in the uuencode header?
dan_grillo(_at_)next(_dot_)com writes:
My software just ignores the extra information in the uuencode header.
It uudecodes a stream, just like un-q-p or un-base64'ing something.
It uses any mode or file name information on the Content-Type or
Content-Disposition lines, with reasonable defaults based on MIME type.
It doesn't use "uudecode" at all.
For those non-MIME mailers out there, we believe it's important to maintain
the integrity of an incoming UUENCODEd message, as well as sending out
valid UUENCODEd attachments (so these can be understood by non-MIME mailers
which recognize UUENCODE).
1. For incoming CTE x-uuencode messages, we assume (correctly, I believe)
that the UUENCODE which follows contains a valid UUENCODE header, and the
user will see "ATTACHMENT # xxx, NON-TEXT MESSAGE" along with the actual
filename which appears on the UUENCODEd header.
2. For outgoing UUENCODED messages we enclose JUST THAT under the CTE
x-uuencode header (a valid UUENCODE message, "BEGIN" and all).
The CTE x-uuencode should be re-named if it is NOT meant to describe a
"standalone" UUENCODE document.