Tectite Forums FAQ

If you're familiar with Matt's FormMail or NMS FormMail or other FormMail clones, here are some of the main differences if you want to switch:

1. Our FormMail is written in PHP not Perl. This is generally regarded as a better choice for modern websites.
2. The email address to send form results to is specified in a field called "recipients" not "recipient" (ours is plural because you can specify any number of email addresses).
3. To redirect the user to another page, you use a field called "good_url" instead of "redirect". Similarly, in our FormMail, you can use "bad_url" to provide a custom error page.
4. The configuration is different and you need to read our documentation for advanced usage or if you don't want to use our Configuration Wizard.

If you're upgrading from Matt's FormMail, you can use the Upgrade Wizard.

You can upload (install) FormMail into any folder on your server that allows PHP scripts to run.

On most servers there are no restrictions.

A few servers demand that PHP scripts be installed in cgi-bin. In general, you should consider these types of servers "old fashioned" and consider moving to a better hosting provider. PHP scripts are not CGI scripts, so forcing PHP to run as CGI is a silly thing to do (and makes PHP scripts start more slowly).

You can install your HTML forms anywhere you want (except cgi-bin) - they are just HTML documents.

In general, we recommend you install FormMail in your "document root" - the top directory/folder for your website.

If you like to structure things differently and install FormMail in a sub-directory/child-folder, that's fine too.

There is a free Community Support Forum where you can get assistance from other FormMail users.

You're also welcome to browse the Subscription Support Forum.

If you want guaranteed help from the author of FormMail, you must subscribe for support or purchase one of our commercial products. For more information or to get started with a subscription, click here.

The easiest way is to use our FormMail Configuration Wizard. However, if you want to configure it manually, read the information below (and also check out the FormMail Documentation).

There are two important configuration settings you need to make. Use a simple text editor like Windows Notepad, WordPad, or "vi" to edit formmail.php. Some people have recommended skEdit, TextMate, and BBEdit for Macintosh users. Search for the configuration settings using the search function of the text editor you're using.

Do not use DreamWeaver or FrontPage to configure FormMail, as some versions of these programs are known to corrupt PHP scripts.

First, set DEF_ALERT to your email address. Like this:

Now, upload formmail.php and test that alerts work by opening formmail.php with your browser:

You should receive an email. If you don't receive the test alert email then there may be a problem with your server. Use the server test scripts at the top of the Formmail Support Forum.

Once alerts are working, you can now move to the second configuration setting: $TARGET_EMAIL.

$TARGET_EMAIL tells FormMail which email addresses are valid to send to. This setting protects your server, and the Internet in general, from spammers.

Inside formmail.php, just above this setting you'll find extensive information. There are also many examples that you can use.

If you want your forms to send to one to just one email address, here's how to set $TARGET_EMAIL....

Suppose you want forms to send to "jack@smithy.org", you could set $TARGET_EMAIL as follows:

Alternatively, suppose you want forms to send to any address at "smithy.org", you could set $TARGET_EMAIL as follows:

After making the $TARGET_EMAIL setting, upload formmail.php to your server and proceed by using our sample HTML form.

The answer to this question starts here.

99% of Tectite FormMail users have no problems at all - it just works on their server. If you read the forums, you're seeing posts from the small percentage of people who do have problems.

One of the common faults is that you've installed FormMail and the sample form, preferably using the Configuration Wizard, and you get no errors but no email.

If this is what you're seeing, then the fault is on your server. FormMail always displays an error if it's told there's been an error. If your server "tells lies" and says it's accepted the email for delivery, but doesn't deliver it, then you can't blame FormMail for that!

We have a document specifically about Solving Email Problems. We recommend you read that after reviewing the information below.

FormMail provides a number of configuration settings to workaround server problems.

The first step is to get FormMail alerts working (this is how FormMail tells you about errors). If FormMail can email an alert message to you, then it can also email form results to you. You can use the testalert feature to test alert messages (see the README file from the Configuration Wizard, or just "http://yourdomain/formmail.php?testalert=1").

You can also use the server test scripts at the top of the FormMail Support Forum.

The configuration settings that you may need to use to overcome your server's problems are:

• SENDMAIL_F_OPTION
• FROM_USER
• SET_SENDER_FROM_EMAIL
• INI_SET_FROM (for Windows servers only)
• PEAR Settings

Once you have FormMail alerts working, you may still have problems with getting form results. This is because FormMail attempts to send you form results with the "From" line set to the submitter of the form. For example, if Jack Smith submits your form and enters an email address of "jack@smith.com", FormMail sends you an email that says the form submission is from "jack@smith.com".

With good servers, this is not an issue. This is what most website owners want to happen. However, some servers stupidly treat this as some sort of spammer activity and refuse to send the email. (Worse still, they generally don't provide any error message - they just accept the email for delivery and then silently throw it away!) If you haven't decided on your hosting provider, check out our advice on picking a good hosting provider. A number of FormMail users have ditched their hosting providers and found better ones when they've discovered the stupid restrictions on their servers.

If you have managed to get alerts working by setting FROM_USER to an address in your own domain, but form results don't get sent, then it's likely your server is one of the stupid ones. (No offense intended - it's not your fault - it's your misguided hosting provider's fault.)

To workaround this, you can use the FromAddr option in FormMail's mail_options feature. The only problem is that all your form results will look like they've come from you instead of the submitter of the form.

Once you get alerts working, if you then get alerts from testing your form that say "Failed to send mail", this almost certainly means that your server will send email that has a From address in your domain, but will not send email that has a From address outside your domain. (At least your server is telling you it's failed...be thankful for that!) The workarounds are as described above.

If you've configured FormMail, and whenever you submit a form you receive an alert message like this:

The following error occurred in FormMail :
no_valid_recipients
 **********
Error=The form has an internal error - no valid recipients were specified.

then you've either made an error in configuring FormMail or in setting the "recipients" (note the "s") hidden field in your HTML form.

Review the FAQ on configuring FormMail.

Also, use our sample HTML form to develop your own form.

If you receive a message in your browser similar to the following:

An error occurred while processing the form.

Please contact us directly since this form is not working.
We apologize for any inconvenience this error may have caused. 
Your form submission was processed by (7.05), available from www.tectite.com. 

this indicates two things:

1. There is an error in your configuration of FormMail and/or your HTML form.
2. You haven't set DEF_ALERT in your FormMail configuration. If you had, then the message would say "Our staff have been alerted to the error." FormMail needs you to set DEF_ALERT so it can provide you with details of the error.

This is fully described in our FormMail HOW TO guides.

This is usually a configuration error in your server's PHP.

PHP must be configured to have a valid directory for creating temporary files.

If FormMail cannot create a check file, then you need to contact your hosting provider to have the problem with the temporary directory solved.

Note that the temporary directory must be configured as a directory not a URL. Your hosting provider should know the difference!

As a workaround, you can create your own directory for temporary files. Review the configuration setting in formmail.php called SCRATCH_PAD.

Another way this problem can happen is if you've changed your website user in some way. For example, if your server user ID was "myweb" and now it's "mynewweb", this could create a permission problem with re-creating or overwriting the check file.

If the check file mentioned in the error already exists, try removing it from your server. When you run FormMail again, it will be re-created with the correct access permissions.

Your final option is to disable the automatic version check. To do this, set CHECK_FOR_NEW_VERSION to false.

FormMail is trying to protect you from spammers by detecting junk in the form submission.

When you're testing you should enter fields that look real. Instead of "test", "test", "test", and so on in each field, use "Jack", "Smith", "USA", and so on.

You can also switch off abuse checking with the ENABLE_ATTACK_DETECTION setting in FormMail's configuration section. But, we recommend you switch in back on when you want to run FormMail live on your server.

During editing or upload of formmail.php you've damaged it.

This means the PHP script is corrupted and will not run.

The message can vary, but here's one example:

To resolve this problem you need to download FormMail again and be very careful when you configure it.

Use the examples provided for $TARGET_EMAIL and DEF_ALERT.

Use a simple program such as Windows NotePad. For Macintosh users, some people recommend skEdit, TextMate, and BBEdit.

Do not use DreamWeaver or FrontPage to configure FormMail, as these programs are known to corrupt PHP. Review the FAQ for Configuring FormMail for more information.

It's also much easier to use our FormMail Configuration Wizard than to edit FormMail manually.

If your HTML form works fine with FormMail and you're getting normal form submission results with no alert messages, but then you get a bunch of alerts saying "no_recipients" or "The form has an internal error - no actions or recipients were specified. ", then....

It's probably spammers!

Spammers look for other vulnerable FormMail products and try to send spam with them. Tectite FormMail is not vulnerable to these attacks.

But, FormMail doesn't know that a spammer is sending a faulty form submission. It thinks that your HTML form is sending a faulty submission, so it's telling you about it.

If FormMail didn't tell you about this problem, and you did have an error in your HTML form, then you wouldn't know what's wrong!

There are two possible solutions.

1. You can rename "formmail.php" to some other name. For example, "myfm.php". Spammers can't easily find the name of your FormMail program, so doing this might stop the problem. Try this first. Of course, you need to modify your HTML forms and change the "action" attribute in your "form" tag too (and sometimes that's how spammers find the name of your form processing script, oh well).
2. For some time, FormMail has "attack detection" built in. It looks for spammer activity and doesn't bother you with alerts. Since version 7.14 of FormMail, it's included a configuration setting called ATTACK_DETECTION_IGNORE_ERRORS. This is set to false by default to help you get your forms working properly. Once they are working, you can set this to true and FormMail won't alert you when spammers try the above attack.

If you're using PHP on Windows (and IIS), you need certain permissions so that PHP scripts (including FormMail) can execute programs.

This is particularly important for running FormMailEncoder (fmencoder.exe).

Thanks to Marcus Young for the solution....

I've been investigating this using the filemon utility from SysInternals (very handy util). And I've managed to resolve the problem. I have detailed my findings below....

The following are my findings:

1. The user IUSR and the group IIS_WPG require read and execute permissions to cmd.exe I don't know why this should be, as it strikes me as a security issue to give IUSR such access. However, filemon clearly showed that in the process of submitting the form an attempt to run cmd.exe as the IUSR and the Network Service account (which is a member of IIS_WPG) was made. This might be an issue with how fmencoder.exe is written, as my understanding is that cgi scripts should be able to run without modifying permissions on cmd.exe.
2. IIS_WPG requires read and execute permissions on the cgi-bin
3. Both IUSR and IIS_WPG require modify permissions on the ScratchPad directory

Russell's comments....

Clearly, for PHP scripts (such as FormMail) to execute programs on the server, the correct permissions must be set. It also seems clear to me that the Windows command interpreter "cmd.exe" is the first component in the process of executing commands, and, therefore, must be usable by PHP scripts (i.e. the correct permission given to it).

On Unix-based systems (e.g. Linux) the command interpreter (the shell) is executable by everyone. Why wouldn't it be? So, the fact that Windows' default is to prevent the IIS user from executing the command interpreter seems very strange to me.

You may also like to review this post with information provided by another FormMail user.

There are two ways to do this: the easy way and the harder way.

The harder way is perfectly secure (no one can get your email address from your form) and the easy way is pretty good - if you're clever about it, only a human may be able to get your email address, and spambots won't be able to.

The easy way is with the AT_MANGLE configuration.

Our Configuration Wizard automatically enables this for you and provides a sample form that uses it.

The harder way requires a little more understanding and an extra file on your server. This is the INI file feature.

We have a HOW TO forum.

We also have HOW TO guides.