[Nms-cgi-devel] RE: [Nms-cgi-support] TFMail: Wrong Filetypes (extensions) are notrejected by the script

[Cole B. <col...@gm...>]

=20
Hello Mr. Stowe,

Thank you for your help. The changings to the script does indeed block
unwanted extensions. But the result is, that a simple "Application =
Error"
occurs. This mesage will not make it clear to the user, that a wrong =
file
type is responsible that for. To create a clear errorpage, I could =
extend
the debug info. But the developers say that debug is only f=FCr testing, =
not
for real life scenario. So is there a better way to do that? If it is to
much work to do it "quick n' dirty", is this feature planed to debut in
future versions of TFMail?

To be honest, I do not understand what was the developers intention on =
the
current "file type limitation" system. OK, executable files are renamed =
(if
not listed), which is good. For your example with the image it is well =
done.
But what if the upload is for "all" files exept executables? Then you =
have
to put hundreds of file extension to the list, just to block a couple...

Wishlist for future Versons of Tfmail:

- Possibility to configure if the File Extension list is a white or
blacklist
- Possibility to configure if wrong file types are rejected (with proper
errorpage) or renamed

Best Wishes, Claus Berghammer



-----Original Message-----
From: Jonathan Stowe
Sent: Tuesday, March 28, 2006 8:58 PM
To: colebantam
Cc: NMS-CGI-Support; NMS Devel
Subject: Re: [Nms-cgi-support] TFMail: Wrong Filetypes (extensions) are
notrejected by the script

On Tue, 2006-03-28 at 17:16, Cole Bantam wrote:
> Hello there,
>=20
> When I read the readme to TFMail, I was pleased, to see the=20
> possibility not only to upload files to the E-Mail, but to limit the=20
> range of file types by its extension. But in fact file types other=20
> than "allowed" in the configfile, are NOT rejected, but only renamed=20
> to the last extension that is listed.
>=20
> Expected behaviour:
> If someone tries to upload a file with an extension that is not listed =

> in the configfile, he informed that he was to upload a file type that=20
> is not supported.
>=20
> Existing behaviour:
> If someone uploads a file with an extension, which is not listed in=20
> the configfile, the attachment is sent with no further comment, but=20
> the file
> (extension) is renamed (and so "defect" for many users).
>=20
> Does anyone knows how to get the "Expected behaviour"?
>=20

You might expect that behaviour but the existing behaviour is the =
advertised
and designed behaviour.  The problem is that the 'extension'
of the file is not a guarantee of the file type: I could quite easily =
rename
some random file with a .doc suffix and upload it and the program would =
be
none the wiser.

Of course it might be nice to have something like this as an option, you =
can
change the TFmail.pl at line 649 where there is:

         if ( $filename =3D~ m#\.(\w{1,8})$# and exists $goodext{lc $1} =
)
         {
            $bestext =3D $goodext{lc $1};
         }
         elsif ( $ct =3D~ m#^[\w\-]+/(\w{1,8})$# and exists $goodext{lc =
$1} )
         {
            $bestext =3D $goodext{lc $1};
         }

To

         if ( $filename =3D~ m#\.(\w{1,8})$# and exists $goodext{lc $1} =
)
         {
            $bestext =3D $goodext{lc $1};
         }
         elsif ( $ct =3D~ m#^[\w\-]+/(\w{1,8})$# and exists $goodext{lc =
$1} )
         {
            $bestext =3D $goodext{lc $1};
         }
	 elsif ( $treq->config('strict_extension','0') )
         {
	    die "Bad file type";
         }

and then add

   strict_extension: 1

to your .trc file which will do what you want.  I'm not sure if this is
exactly what we would put in a released version, so I am copying the
developers list to see if anyone has a better idea.

/J\
--=20

This e-mail is sponsored by http://www.integration-house.com/