>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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
