>I'm trying to get just a little better result in crafting a reply
>draft message. I'm using Ken's very nice 'replyfilter' script and
>recipe, which formats nearly all of the body of the message perfectly.
>
>But, I still get a little cruft in the body, thus
>
> On 15 August 2012 at 15:36,
> "
Kevin wrote:
> > [Ken:]
> > - Maybe a Content-Type of application/octet-stream would work?
>
> I already tried a variation on that. I gave it a fake .exe
> extension, thinking that Exchange might look more favorably on
> it. No joy there.
I didn't have any luck with it either. Or with .bin or
Sending files as ".exe" is probably not the wisest way to work around things
either, as you wil fall afoul of virus heuristics. ".bin" seems to be the
more conventional way to approach this.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lis
>> - 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
On 20 August 2012 at 12:38, Ken Hornstein wrote:
> 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?!??!".
Should I send you a photo of me with my pet dinosaur? ;-)
What can I say, I u
>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 o