[Nmh-workers] NMH Work-arounds for Exchange server mangling (OT???)

[Kevin Cosgrove]

Hi,

I have to deal with email going through an Exchange server on
a daily basis.  A few months back that server started mangling
email my email message content.  I'm trying to use nmh to craft my 
emails such that Exchange won't mangle it.


SOME BACKGROUND (skip to QUESTION, if you wish)

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.  FWIW, my
uuencode recipe was

  uuencode file filename | mail -s filename address@hidden

I've since changed my recipe to make use of nmh-attachment.  My 
recipe is now, via shell script

  cat << EOF > ${HOME}/Mail/drafts/mupdate/1
  from: ${FROM}
  to: ${EMAIL}
  fcc: outbox
  subject: ${subject}
  nmh-attachment: ${dirname}/${basename}
  --------

  EOF

  send -draftfolder +drafts/mupdate -draftmessage 1       

That recipe works exactly fine when I email gzip'd tar files.
For those files the attachment type looks like this

  Content-Type: application/octet-stream;
          name="update-16Aug12-010501.tgz"
  Content-Description: update-16Aug12-01:05:01.tgz
  Content-Disposition: attachment; filename="update-16Aug12-010501.tgz";
          size=116955; creation-date="Thu, 16 Aug 2012 08:06:20 GMT";
          modification-date="Thu, 16 Aug 2012 08:06:20 GMT"
  Content-Transfer-Encoding: base64

But, when I email a shar file, then my UNIX newlines get
converted to DOS, and the shell scripts won't run until I
reconvert them into UNIX form.  For those files the attachment
type looks like this

  Content-Type: text/plain; name=",shar.16Aug12-01:05:01.01";
          charset="us-ascii"
  Content-Description: ,shar.16Aug12-01:05:01.01
  Content-Disposition: attachment; filename=",shar.16Aug12-01:05:01.01"

Somewhere along the way that gets translated into this

  Content-Type: text/plain; name=",shar.16Aug12-010501.01"
  Content-Description: ,shar.16Aug12-01:05:01.01
  Content-Disposition: attachment;
          filename=",shar.16Aug12-010501.01"; size=103500;
          creation-date="Thu, 16 Aug 2012 15:46:24 GMT";
          modification-date="Thu, 16 Aug 2012 15:46:24 GMT"
  Content-Transfer-Encoding: base64

Not only does the content get DOS newlines, but the filename gets 
changed to remove colons (:).  That doesn't break anything, but I'm 
against it on principle.

I unpack the TGZ or shell script emails the same way, e.g.

  mhn -store -auto <msgno>

I'm running NMH version 1.5 on Linux.


QUESTION

Is there a better way to use mhn to unpack the attachments,
converting DOS form back to UNIX form?  I suppose I could write a
shell script to alter the files after mhn unpacks them.

Is there a better way to use nmh-attachment and send to form a
message of a different type, e.g. application/octet-stream, so
that Exchange might not mangle it?

Thanks folks!

--
Kevin