Hi Ken,
I don't think you're understanding the problem. There are no invalid
octets here; the issue is whether or not we perform an automatic
decode.
But now Lyndon's brought it up,
Content-Type: inode/x-empty; name*=UTF-8''%41%00%42
Content-Disposition: attachment; filename*=UTF-8''%41%00%42
`mhstore -auto' creates `./A'. Perhaps the RFCs rule out %00? But then
again, we're talking about crap that doesn't follow the RFCs. If it's
%41%2F%42 then `A/B' is created if A exists, so that seems OK.
BTW, file(1) might be happy with inode/x-empty, and nmh stores an empty
file, but I wonder if other systems complain they don't know what to do?
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers