Add the cgi-bin alias and .cgi file extensions manually from the Web Options page.

First, make sure the account type you're using supports CGI scripts. As of this writing, the Atto account does not, while all others do. If your account does not support CGI scripts, you will need to upgrade.

If you have upgraded to an account that supports CGI, a manual step must still be done in order for CGI to work. See the related article for more information.

Feedback forms created in Microsoft Frontpage by default rely on what are known as the Frontpage Extensions. QWK.net does not support the use of Frontpage Extensions, but you can still use feedback forms created with Frontpage by using the FormMail CGI script QWK.net provides. Instructions for altering your Frontpage form can be found at https://customers.qwk.net/docs/walkthrough/fpforms.html

The reason your email does not arrive is most likely a SPAM control issue.

When you send an email using a CGI or PHP script, Qmail (our sendmail stand-in) reads the enviroment to determine how to set the Return-Path variable. This is the email address that is reported to the recipient's email server as the sender and is not to be confused with the From: or Reply-To: headers in the actual email itself which exist for the benefit of the email client program.

The default Return-Path for CGIs is anonymous@mail.qwknetllc.com and for PHP is root@mail.qwknetllc.com. These addresses have stigmas (may be on some blacklists) attached to them due to previous abuses of CGI/PHP scripts on the QWK.net servers and also because the users anonymous and root are suspect absent of the stigmas previously mentioned. Mail servers attempting to control SPAM may silently reject email with Return-Path headers containing those addresses or even anyuser@mail.qwknetllc.com. as mail.qwknetllc.com has been sufficiently abused as a sending host. While we try our best to prevent abuse of our system it has happend and these are the consequenses.

You can avoid this stigma by setting the Return-Path environment to something different. In a Perl based CGI, add somewhere near the top of you script:

$ENV{'MAILUSER'} = 'myusername';
$ENV{'MAILHOST'} = 'mydomain.com';

In a PHP script calling the mail function, prior to the mail command, add:

putenv("MAILUSER=myusername");
putenv("MAILHOST=mydomain.com");

This will set the Return-Path to 'myusername@mydomain.com' and should allow your mail to pass through. If you are using the formmail.cgi AS SUPPLIED by the QWK.net (H-Sphere) Control Panel, you can file a support ticket at http://customers.qwk.net/ and we will add the code free of charge.

It is our intention in the future to force these variables, but for now you will need to set them in your scripts.

The two most common causes of these errors are:

- A Perl script was not uploaded in ASCII mode. Because of differences in end-of-line conventions between different system these scripts must be uploaded in ASCII mode. Compiled programs, such as those written in C, must be uploaded in binary mode.

- The Perl path in the first line of the file is not correct. The correct path to use is listed in another document in this section.

Turn PHP off and back on from the Web Options page. Be sure to click the Apply changes link if it appears.

The following paths should be used where required by your script:

Sendmail: /usr/sbin/sendmail

Perl: /usr/bin/perl

Home directory: /hsphere/local/home/username
(where "username" is your FTP username)

Web files directory: /hsphere/local/home/username/domain.com
(where "domain.com" is the domain in question)
 

Many CGI scripts will instruct you to modify the permissions on the script, its data files, and your directories. This is because, with many web hosts, you must severely relax access permissions on your files for CGI scripts to operate with them, due to the security scheme in place. (All user scripts run with the web server's "permissions" on the system.)
This is NOT necessary with QWK.Net servers. (Scripts run with your permissions, rather than the web server's.) In fact, changing some permissions on CGI scripts may cause the system to refuse to run them. Specifically, you must not change your CGI scripts to be writable by "group" or "other", or they will be rejected.

CGI scripts themselves must still be marked as executable to run, but you should not change any other permissions of the script, or your cgi-bin directory. If your software accepts a numeric permissions description, set your scripts to "755" permissions.