As others said: If you don't want the script to be started from the webserver, don't place it in directories accessible via the webserver.

In case of shared hosting, you are often limited to directories accessible via the web server. A .htaccess file can help. But you can also check for the environment variable GATEWAY_INTERFACE. Unless you have really messed up your setup, it is set if and only if a program is executed as CGI (i.e. from the webserver), it is set by the webserver, and it can't be changed by HTTP requests. See https://tools.ietf.org/html/rfc3875#section-4.1.4:

if (exists $ENV{'GATEWAY_INTERFACE'}) {
    # invoked as CGI
    # print out a short message and abort
    my $q=CGI->new();
    print
        $q->header(-status=>'400 Bad Request', -type=>'text/html'),
        $q->start_html(-title=>'Bad Request'),
        $q->h1('Bad Request'),
        $q->end_html();
    exit 0;
}
# not invoked as CGI if you get here
[download]

And by the way: from which digital junkyard did you copy this nonsense?

$ENV{PATH}      = "/usr/sbin/sendmail -t -i";        #for sendmail
[download]

$ENV{'PATH'} contains a ":"-separated list of directories to search for executables. Putting the name of an executable and parameters there is nonsense and won't do what you might expect. You want $ENV{'PATH'} set to a safe value, this is usually /bin:/usr/bin and nothing else.

Some more notes:

• my $brow = $ENV{'HTTP_USER_AGENT'}; - Consider the User-Agent HTTP header and the HTTP_USER_AGENT CGI environment variable to contain nothing but junk. The User-Agent identification is completely broken since the mid-1990s, and it is completely under user control. You CAN NOT RELIABLY DETECT the browser by guessing data from that header. Don't use it at all. Any code relying on that header is broken by design.
• my $ref  = $ENV{'HTTP_REFERER'}; - Consider the Referer HTTP header and the HTTP_REFERER CGI environment variable to contain nothing but junk. The referrer information is completely under user control and may contain any nonsense or attack you can (and can not yet) think of. You CAN NOT RELIABLY DETECT the page the browser came from by guessing data from that header. Don't use it at all. Any code relying on that header is broken by design.
• You don't unset $ENV{'HTTP_PROXY'}. There is a known attack on CGIs that can redirect HTTP requests issued by (not to!) CGIs to a server under control of the attacker. Especially if you are running your code on a shared hosting server, don't rely on the hoster to fix that problem for you.

Alexander