To restate what I've mentioned before - if I could figure out a way to
stomp out all use of UUENCODE, I would support this. Unfortunately,
the UUENCODE issue has been a thorn in our side for a completely
different reason.
Our gateway, a MIME compliant gateway for cc:Mail naturally sells into
environments where cc:Mail is dominant. Our main competition in this
market is the Lotus (non-MIME) gateway. The last very informal
numbers that I've heard indicate that Lotus is fielding a couple
hundred gateways per month, and doubling their sales each year
(gateways included). I would suspect that Microsoft is probably
fielding similar numbers of their non-MIME gateways as well. With
each gateway representing several hundred users, the number of new
users that come into existance each month is considerable. Both of
these gateways deal with attachments using *only* UUENCODE.
But this is going to change. Microsoft's as-yet-unreleased Exchange product
uses MIME formats, and I've heard words to the effect that Lotus Communication
Server supports MIME as well. Note that the Lotus Notes SMTP gateway uses MIME
formats, although early versions were quite buggy in terms of their MIME
support.
What we have found is that the user community is DEMANDING that we
produce solutions that allow them to communicate with the existing
user base as well. There are two ways to do this - the first is that
we allow for the MIME encoding of uuencoded data, which also happens
to be properly decoded by these gateways. The other is to admit
defeat, and create a non-MIME mode for the gateway. Unfortunately,
our next release of the gateway will include a mechanism where the
gateway administrator can select which mode - MIME or non-MIME is used
based upon the recipient host. The question we are trying to answer
now however is which mode should be the default? I'm afraid that the
answer to this question will not be to our liking either, with the
non-MIME mode prefered by more than the MIME default mode.
But there is no reason to create such a "non-MIME" mode to solve your problem!
If you want to use a nonstandard encoding in MIME, fine, go ahead and use it.
Lots of other MIME software will understand if you label it as x-uuencode in
the CTE line.
We've supported this option in our software for *years*, and while it doesn't
work especially well in practice (as you are going to find out if you do it),
the problems are caused by UUENCODE not being particularly mail-safe and not
being very standard. You don't fix either of these by officially blessing
uuencode in MIME.
As such, all you need is a "non-standard MIME encoding mode". This is perfectly
legal under the existing specifications -- we don't have to standardize on some
version of uuencode (a daunting prospect for all sorts of reasons) to enable
you to do this.
It is even possible to determine what encoding to use on a per-system basis,
and to let this be configured into your products either manually or
automatically. We've supported this option for several years now as well.
In short, I understand your problem completely. I deal with it every single
day. I completely disagree, however, that the change you propose making in
the specifications would solve this problem in any way.
To show just how crazy this can be - I have a reseller working with a
client that is using our cc:Mail gateway and another vendor's MIME
compliant Microsoft Mail gateway. Both sides have to deal with
non-MIME recipients as well as MIME. It is starting to look like the
best way to solve the interoperability problems between our two MIME
gateways will be to configure both sides to think the other gateway is
a non-MIME gateway and uuencode everything between themselves
(actually I think we can receive their MIME messages, however the
other gateway drops the x-uuencode CTE on the floor). This makes no
sense to me.
The other gateway is broken and does not comply with the specifications if it
drops an unknown CTE on the floor. It can refuse to decode it if it wants to,
but dropping it on the floor is unacceptable. As such, the proper way to fix
this is to fix the other MIME gateway to comply with the specification and also
to use standard MIME when talking to it.
The whole situation is most disturbing to me. We are BTW, not the
first vendor that has come to this conclusion of having to backtrack
and build in non-MIME support for messages we generate (not just
accept). And the reason for this clearly revolves around the
extremely widespread use and acceptance of UUENCODE within the
marketplace.
Again, this is the reality that all vendors must face. But your proposed
"solution" to this problem in fact solves nothing -- it just makes the
problem much worse by officially blessing a protocol we know doesn't
interoperatge very well.
I remain convinced that the best way to deal with all this is outside the
standards process. The standards process is not the cure for all problems, you
know.
Personally, I'd prefer to find a way to support UUENCODE within the
context of MIME than having to build gateways that support both
approaches. It appears to be a lose-lose situation either way - just
which set of evils is easier to live with?
We already have exactly this sort of mechanism available to us. We don't need
changes in the specifications to get it.
Ned