No, uuencode is the right solution for this simple reason that it is
very commonly available on almost everything, DOS, OS/2, Macs, various
UNIXs, even VMS/VAXen. Currently, I can send a uuencoded message to anyone
and be confident of their ability to decode it -- choosing uuencode as
the basis for an automated encoding facility ensures that even those
with 'old-style' MTA/UAs will be able to understand the message.
Er, no, you cannot be so confident. UUENCODE made some poor choices in terms of
the characters it uses, and the result is that a lot of uuencode messages get
wrecked during e-mail transit. I've spent too much time trying to reconstruct
damaged files to think otherwise. I'd be firmly behind UUENCODE except for
this, but I don't propose to further propogate encodings that cannot survive
the hostile world of e-mail, when similar encodings avoid these problems and
work very nicely.
As for the presence of lots of implementations being a compelling reason to use
a poor encoding, an implementation of the BASE64 is only a few dozen lines of
code (my code that handles BASE64, HEX, BASE85, and UUENCODE is something like
500 lines). A complete utility is only a few hundred lines. We're not talking
about a huge programming investment here.
If nobody else is willing to do it I'll be happy to write a public domain
utility in ANSI standard C that is equivalent to UUENCODE but uses BASE64.
(This presupposes that you don't have an implementation of BASE64 handy, which
you will if you use privacy enhanced mail.)
And why is it "even VMS VAXen"? My VMS version of UUENCODE at least attempts to
deal with the realities of some types of e-mail damage, which is more than I
can say for most implementations ;-)
enjoy,
leo j mclaughlin iii
ljm(_at_)ftp(_dot_)com
Ned