I don't understand why uuencode is even being considered as a
Content-Transfer-Encoding by anyone. A uuencoded file has more
information attached to it than just the encoded contents; ...
Bravo, Tony! Thank you.
This is what struck me immediately. It what you're looking for
is compatibility with "old" (here defined as pre-MIME) mail user agents,
then it doesn't matter (to the non-MIME MUAs) whether it's CT or CTE.
New (here defined as MIME) MUAs can have uuencode "hooked in" in mailcap
or some other mapping function associating CTs with applications.
Treating UUENCODE as a CT gives it the (perhaps silly) advantage
of surviving transport. After all, UUENCODE was rejected because it
doesn't survive some transport. But a UUENCODE package wrapped-up in
CTE Base64 would get through just fine.
For those of you who try and handle a CTE of uuencode or x-uuencode:
What do you do with the extra information that uuencode has in its header?
Do you just ignore it? ...
That's what I would do. If it's a CTE, I don't see that you
have any other choice.
Tony Hansen
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com
att!pegasus!hansen, attmail!tony
I think it's to everyone's advantage for UUENCODE to be
treated as a CT if supported at all.
--
Rick Troth <troth(_at_)ua1vm(_dot_)ua(_dot_)edu>, Houston, Texas, USA
http://ua1vm.ua.edu/~troth/