`write'++: !interactive: urlxenc() attachment paths (Ralph Corderoy)..
commit7a09af69391defb97190e19ff51f66af90210a32
authorSteffen (Daode) Nurpmeso <steffen@sdaoden.eu>
Thu, 6 Oct 2016 15:45:33 +0000 (6 17:45 +0200)
committerSteffen (Daode) Nurpmeso <steffen@sdaoden.eu>
Thu, 6 Oct 2016 15:58:27 +0000 (6 17:58 +0200)
tree67322050b18bcbdb8303aa38b16b3ceab86704fc
parent1657626115e29811b1aeec93cc60914bc7faa004
`write'++: !interactive: urlxenc() attachment paths (Ralph Corderoy)..

Heck.  Yes, i sneaked into the nmh ML.  Sigh.

So in the following, in non-interactive mode, a `write' would
blindly invoke the shell when saving the second attachment, which
seems like something really bad to-do.  And any path specification
in an attachment filename smells fishy, too.

All this can be circumvented by calling urlxenc() on the
attachment filename, and so henceforth S-nail will place in the
_current_ directory %2E.%2Flaber.txt,
%7Cecho%20hey_%24SHELL and A, which is at least reliable
behaviour.  The future has to bring much more control.

  MIME-Version: 1.0
  Content-Type: multipart/mixed;
   boundary="=-=4ALQnuF2gp2qHOI9MnFB4Li4_vLarc5l-p0u=-="

  This is a multi-part message in MIME format.

  --=-=4ALQnuF2gp2qHOI9MnFB4Li4_vLarc5l-p0u=-=
  Content-Type: text/plain; charset=us-ascii
  Content-Disposition: attachment; filename="../laber.txt"

  boing

  --=-=4ALQnuF2gp2qHOI9MnFB4Li4_vLarc5l-p0u=-=
  Content-Type: text/plain; charset=us-ascii
  Content-Disposition: attachment; filename="|echo hey_$SHELL"

  boom

  --=-=4ALQnuF2gp2qHOI9MnFB4Li4_vLarc5l-p0u=-=
  Content-Type: text/plain; charset=us-ascii; name*=UTF-8''%41%00%42
  Content-Disposition: attachment; filename*=UTF-8''%41%00%42

  tschak

  --=-=4ALQnuF2gp2qHOI9MnFB4Li4_vLarc5l-p0u=-=--
send.c