i believe there was consensus that a) this behavior was a result
of a problem with the original content encoding, and that b) the
nmh decoder should be more tolerant when decoding, and simply
pass mis-codings through untouched.
I'd have to think *real* hard about that. I suspect that
passing mis-codings through without a complaint is possibly
setting us up for a nasty security exposure. I'm not
convinced that it isn't possible to create an intentional bad
encoding that causes issues further down the line.
interesting. mh certainly wouldn't be the first mailer to make
this mistake, if what you think is true.
for instance a sourceforge message i received today had these headers:
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
and it contained the following URL,
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
this displays in mutt as:
http://sel.as-us.falkag.net/sel?cmd=lnk&kid^Q0944&bid$1720&dat^R1642
nmh aborts when it reaches the "=ln", and displays nothing at
all. i wouldn't mind an error message -- it's the aborting
that's the real nuisance.
paul
=---------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma, where it's 29.7 degrees)
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers