The Exchange server alters uuencoded content by changing
text/plain into the MS version of quoted printable text, with
"=3D" in place of "=", etc. That made shar files (shell scripts)
fail badly after transiting through that email path.
I was thinking that you really meant "base 64" instead of uuencode
... until you mentioned shar files. My next thought was, "People
still use shar files?!??!".
So, some suggestions for you, in no particular order.
- Maybe putting a Content-Transfer-Encoding: 7bit would help on your
attachents? Unfortunately we can't specify the CTE in nmh (but it's
something I always wanted to add); you'd have to add it to the draft
manually.
- Maybe a Content-Disposition of inline would work? You CAN set that via
mhbuild directives.
- Maybe a Content-Type of application/octet-stream would work? If you want
to do that via nmh-attachment ... from what I remember it looks those up
via suffixes that are listed via the normal mhn mechanism (mhn.defaults).
Hm, I see that files that end in .sh will be sent via application/x-sh;
maybe that would work?
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers