Dear Ned,
Thanks for your notes regarding your experiences with UUENCODE. I am
not attempting to dispute any of your comments. I agree that my
personal experience with UUENCODE is most likely due to the groups
that I have been personally invovled with over the years. Our
experience in fielding SMTP has clearly shown the same principal in
force when we started to test our SMTP in environments that are
foreign to us.
While you are experiencing real problems with the fielding of a single
version of UUENCODE, we are seeing the problem from a different,
perspective. I would like to think we are both trying to solve the
same problem, however are approaching it from different angles.
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.
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.
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 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.
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?
Just another vendor looking for a way out of the UUENCODE jungle...
Best Regards,
Tim Kehres
International Messaging Associates Ltd