Sounds plausible. Can't help thinking that somewhere (ie somewhere else - not in hypermail) there must be a lump of code that does `the right thing' in terms of allowing `safe' characters.
Can't decide if DEL is a problem but I guess we do need to look out for path separators ('/', '\', others depending on host OS?)
Paul
-- Paul Haldane Unix Systems, Information Systems and Services, University of Newcastle upon TyneReceived on Tue 16 Nov 2004 05:58:01 PM GMT
> From: Peter C.McCluskey
>
> grp_at_med.uoc.gr (G G Papazoglou) writes:
...
> > our users send attachments with Greek filenames. The result
> > is that they are saved and shown as underscores:
> >
> > http://bb.med.uoc.gr/0411/0020.html
> >
> > Could you recommend some workaround on this? I am aware hypermail
> > supports greek, but on the one hand I am not sure if using
> > it will solve
>
> Greek language support should have no effect on the
> filenames. The conversion to underscores is done to avoid
> characters that might create security risks, and it looks
> like we were too cautious. We should probably alter this test
> in parse.c:
>
> if (((*np >= 'a' && *np <= 'z') || (*np >= '0' && *np <= '9') ||
> (*np >= 'A' && *np <= 'Z') || (*np == '-') || (*np == '.')
||
> (*np == ':') || (*np == '_'))
>
> to allow characters in the range 0xA0 to 0xFF under some
> conditions. I suspect this range of characters should be
> conditioned on a config option which defaults to not allowing
> them (they can be a nuisance to handle in some of the tools
> people use to maintain filesystems). I'm guessing that
> character 0xFF should not be allowed even though it is used
> as a printable character in some languages, because there
> might be some conditions under which the high order bit gets
> stripped off and we end up with 0x7F (DEL), which I suspect
> is dangerous to have in names.
>
> Does anyone see any problems with my guesses?
This archive was generated by hypermail 2.2.0 : Thu 22 Feb 2007 07:33:55 PM GMT GMT