< 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.
If you were to instead use a Content-Type of x-uuencode, I bet the other
gateway would be perfectly happy, AND the non-MIME gateways would also be
perfectly happy. It sounds like a win-win situation to me.
It is a MAJOR lose-lose for me -- my software doesn't know anything about a
content-type of x-uuencode, which in turn can lead to situations where things
get doubly encoded (we sometimes encode things that don't necessary need
encoding to get non-MIME gateways to see them as attachments).
Moreover, supporting
Content-type: application/x-uuencode;
real-content-type=whatever/whatever
would be very difficult for me to do, and if I ever do support I would
have to implement it as a low-level, non-reversible transform into:
Content-type: whatever/whatever
Content-transfer-encoding: x-uuencode
Ned