> > 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, [EMAIL PROTECTED] (arlington, ma, where it's 29.7 degrees)
_______________________________________________
Nmh-workers mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/nmh-workers
