[Top] [All Lists]

Re: Re[6]: Will the real uuencode please stand up?

1995-01-03 09:30:14
     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

     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
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

     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.


<Prev in Thread] Current Thread [Next in Thread>