MailForm Copyright 2000 Left Side Software Pty Ltd

(1)

MailForm

© Copyright 2000

Left Side Software Pty Ltd

Current Version : 1.96

(2)

i

Licence Policy and Copyright Notice

This program is distributed under the Shareware concept. You may try the fully functional evaluation version of MailForm for up to 30 days before you have to purchase the software. When you register, you will be given priority when asking for technical support, and also receive notification of new releases of this and other software.

The MailForm base registration fee is $US 35.00. This gives you a licence entitling you to use MailForm for one domain only. You can use as many different forms as you like, but they must all be within the one domain. Note that this applies to third-level as well as second-level domains.

If you wish to use MailForm on multiple domains, for example if you are a web hosting provider, then you need to purchase one domain licence for each additional domain. The fee for this is $US 15.00 per additional domain. We are also happy to negotiate bulk discounts for more than 25 domains.

Please see http://www.lss.com.au for more information on registration, or email [email protected] The MailForm software and this documentation are Copyright © 2000 Left Side Software Pty Ltd. All rights reserved.

Left Side Software Pty Ltd

PO Box 2252

Strawberry Hills, NSW 2012

Australia

(3)

2. Installing MailForm

Installing MailForm is simple provided you know your way around your web server. The MailForm executable (mailform.exe) must be copied into the cgi-bin directory for your web server. For example, on a system running Microsoft IIS, this directory might be:

c:\INetPub\wwwroot\cgi-bin

The location may be different on your system, however. If you don’t know, ask your network administrator.

If you have never installed a CGI script on your web server before, you may need to adjust the permissions settings to allow the script to be executed. Briefly, you need to configure the permissions for the cgi-bin virtual directory to allow ‘Run & Execute’. This must be modified within IIS itself, and may also need to be set for the physical cgi-bin directory through NTFS. Contact your network administration for help with this if you are having trouble.

(6)

3

3. Using MailForm

Assuming you already have a form created, the first step is to assign MailForm as the action for your form. If you are using an HTML editor like FrontPage, this will probably be configured through a GUI. The HTML code needed looks like this:

If you are going to be using the File Upload functionality of MailForm (described later), you also need to set the encoding type of the form, like this:

If you do not specifically set the encoding type, it defaults to x-url-encoded which is fine for most forms but doesn’t handle file upload.

(7)

4. Configuring MailForm with the _1_ fields

MailForm is primarily controlled by the use of hidden fields within the form. These are fields that have a name and a value like any other field, but are not actually displayed to the user. The hidden field configuration system is extremely flexible as it allows every form that you use with MailForm to have its own configuration.

Using hidden fields can cause a small security risk, however, so you can also elect to use an INI file to configure MailForm’s behaviour. This is described later.

All MailForm configuration fields begin with an underscore character, a number, and then another underscore (eg _1_). This identifies them as a MailForm field, and the number is a code used to identify the particular type of field. Currently there are five different type of MailForm fields:

_1_ System Field. This is used to control MailForm’s behaviour.

_2_ Ignore Field. Any field with this prefix will be excluded from the email that is sent. _3_ Credit Card Field. Used to check for a valid credit card number.

_4_ Required Field. MailForm will complain if a field with this prefix is not filled in. _5_ Email Field. Used to check for a valid email address.

If you are using Java or VB scripting you may encounter problems using fields that begin with underscore characters. In this case, you can replace the underscores with the letter x – for example, x1x is equivalent to _1_.

The System fields are the primary configuration fields of MailForm. The fields available are: _1_MailTo Address to email the results to

_1_MailServer SMTP server

_1_MailSubject Subject line of the email _1_MailFrom Address email is to come from

_1_CCMailFrom Email is also sent to the address in _1_MailFrom _1_INIFile Specifies an alternative ini file to use

_1_MailTemplate Specifies a template to generate the message with _1_MailIntro Sets the email introduction line (header)

_1_SuccessDocument URL to return if the operation succeeds _1_FailureDocument URL to return if the operation fails

_1_InvalidCardDocument URL to return for an invalid credit card number _1_RequiredFieldDocument URL to return if a required field is missing

_1_CardNotAcceptedDocument URL to return for a credit card that's not accepted _1_InvalidEmailDocument URL to return for an invalid email address

_1_NoHotmailDocument URL to return for a rejected anonymous email address _1_BadRefererDocument URL to return when the form is "referred" by an

unauthorised host

_1_ConditionalSuccessDocument Conditionally redirect to a different document on success

_1_FileTooBigDocument URL to return when an uploaded file exceeds the size limit you have set

_1_SortFields Set this field to cause fields to be sorted in the email _1_TextLog Set this to log all form submissions to a text file _1_HTMLLog Set this to log all form submissions to an HTML file _1_CommaDelimitedLog Set this to log all form submissions to a

comma-delimited text file

_1_StripEmptyFields Set this to cause empty fields to be removed from the email

_1_NoHotmail Set this to reject anonymous "hotmail" addresses _1_AcceptedCards Set this to specify the credit cards accepted _1_AcceptEmptyCardField Will accept an empty _3_ field as valid _1_FileUploadLimit Used to limit the size of uploaded files

(8)

5

4.1 _1_MailTo

This field is possibly the most important field in the form, as it is where you specify the email address that the message is sent it. It must be a valid email address, or the form submission will fail.

This field can contain multiple email addresses, each separated by commas. The contents of the email will be sent to each of the addresses in turn. You can also have more than one _1_MailTo field on the one form. This lets you, for instance, have one hard-coded email address (supplied as a hidden field) and a user-editable email address (supplied as a text field) on the same form.

Default Value:

none

Example:

<input type=”hidden” name=”_1_MailTo” value=”[email protected]”> Required:

(9)

4.2 _1_MailServer

This field must be set to the address of the SMTP mail server you are using to send the email. You can specify this as either a name or IP address. Form submission will fail if this field is not supplied, or if the value is incorrect. You must also make sure that the mail server you are using is actually configured to accept mail from your web server machine.

Something else to be aware of is that in these days of rampant spam, many mail servers are configured to only forward mail to certain addresses, and to only accept mail from certain people. If you find that your form emails aren’t getting through, the first thing to check is if the SMTP server actually allows you to send the mail that you are trying to send.

Default Value:

none

Example:

<input type=”hidden” name=”_1_MailServer” value=”smtp.mycompany.com”> Required:

(10)

7

4.3 _1_MailSubject

This field lets you configure the subject line of the emails that MailForm sends. If you do not supply this field, a default value is used.

Default Value:

MailForm – Form Results

Example:

<input type=”hidden” name=”_1_MailSubject” value=”Sales Order From Website”> Required:

(11)

4.4 _1_MailFrom

This field lets you set the ‘from’ address of the email message. This field does not have to be provided, but if it is, it must be a valid email address (that is, it must contain exactly one @ character). Most mail servers will reject messages with an invalid ‘from’ address.

The default ‘from’ address, if you do not supply one, is set to [email protected]. Some people see this and instantly become afraid that we are somehow intercepting your information. Rest assured, no data is sent to our servers at all. This email address is used only if you don’t provide one, and only because there has to be a valid ‘from’ address for email to work.

We can’t stress strongly enough, however, that you should set the ‘from’ address. We often (ie, all the time) receive email from people who are using MailForm (and probably had it set up for them by someone who didn’t read the instructions). The emailed forms they are receiving have [email protected] as the ‘from’ address, but they don’t notice that and instead try to reply to the message. This, of course, sends the reply to us instead of the intended recipient, who is often a customer. We could have built up quite a mailing list (and collection of credit cards numbers) from this had we been so inclined.

Set the ‘from’ address! Set the ‘from’ address! Set the ‘from’ address!

If you want the email message to appear to come from the user who actually submitted the form, you actually need to use two separate fields. The first field should be a normal text field (with or without a _5_ prefix) to enable the user to enter their email address. The second should be the _1_MailFrom field, with the value set to the name of the first field.

That is, the _1_MailFrom field can either be set to a valid email address, or to the name of another field in the form. In the latter case, MailForm will use the value of the ‘referred to’ field as the ‘from’ address of the mail.

Perhaps the following examples will explain this better :-)

Default Value:

[email protected]

Example 1:

<input type=”hidden” name=”_1_MailFrom”

value=”[email protected]”> Example 2:

<input type=”hidden” name=”_1_MailFrom” value=”_5_Email”> Required:

(12)

9

4.5 _1_CCMailFrom

If this field is set (the value doesn’t matter), then MailForm will send a copy of the email message to the ‘from’ address that you have configured with _1_MailFrom.

Default Value:

None.

Example:

<input type=”hidden” name=”_1_CCMailFrom” value=”1”> Required:

(13)

4.6 _1_INIFile

The INI file, which is a supplementary as well as alternative configuration method to the hidden fields system, is described in a later section. This field lets you configure the name of the INI file to use. You can specify just a filename, in which case MailForm will attempt to find the file by itself, or you can specify a full DOS path. You can not specify this as a URL (that is, http://…).

If you do not specify the full path, MailForm will search for the file in several places, including the cgi-bin directory, the “current directory” (depends on the web server, but often the root of the web), the Windows directory and so on.

It is often more reliable to provide the full DOS path to the file, so that MailForm knows exactly where to look.

You must also make sure that the permissions are set correctly to allow MailForm to read the file.

Default Value:

mailform.ini

Example:

<input type=”hidden” name=”_1_INIFile”

value=”c:\inetpub\wwwroot\templates\formtemplate.txt”> Required:

(14)

11

4.7 _1_MailTemplate

Normally, MailForm simply generates the email that it sends by putting one field value on each line, in the order they appear in the form (although this can be overridden by sorting). However, using the _1_MailTemplate field, you can specify an external template file that is used to generate the message. This allows you to control precisely the output of the email.

If you want to use a template, set the value of this field to the name of the external template file. Only plain text files are supported as templates – which means the filename must end in a .txt extension. You can specify just a filename, in which case MailForm will attempt to find the file by itself, or you can specify a full DOS path. You can not specify this as a URL (that is, http://…).

If you do not specify the full path, MailForm will search for the file in several places, including the cgi-bin directory, the “current directory” (depends on the web server, but often the root of the web), the Windows directory and so on. It is often more reliable to provide the full DOS path to the file, so that MailForm knows exactly where to look. You must also make sure that the permissions are set correctly to allow MailForm to read the file.

You must use a text editor such as Notepad to create the template file. The format is fairly straight-forward: plain-text, with embedded codes which control the output of form field values. Here is an example of a simple template file:

Test Template File.

Submitted at %MF_DATE% from %MF_REMOTE_ADDR%. Name: %Name%

Address: %Address%

As you can see, to insert a form field value in the email you enclose the value name with percentage signs.

Any field in the form, including hidden fields, can be used in the template. There are also several pre-defined values which can be used:

%MF_DATE% Date and time of form submission %MF_REMOTE_ADDR% User's IP address

%MF_REMOTE_USER% Remote user

%MF_USER_AGENT% The HTTP client used (web browser)

%MF_UNIQUE_ID% Unique ID number – this generates a number which is unique to each invocation of MailForm. You can use this to generate a tracking or serial number for the message

Values inserted in the email can be left or right padded with spaces. This is useful for lining up multiple fields. To pad a field, use the following notation:

%[-]xx.name%

The - sign is optional; if specified, it indicates left padding instead of right. xx is the number of spaces, and name is the value name as usual. For example,

%-20.Address% The field would be left padded to be 20 characters wide %32.Phone% The field would be right padded to be 32 characters wide

There is also a * marker, which is used for multi-line text fields. When specified, it causes all lines on the field after the first one to be automatically aligned with the first line. For example,

%*Comments% Properly align a multi-line text field

(15)

4.8 _1_MailIntro

This field allows you to change the introduction line of mail messages that MailForm sends. The default introduction line includes the IP address and date and time of submission. Using this field, you can configure to display additional information or change it altogether.

The value of this field is a string which can contain special codes to embed information in the introduction string. The available codes are:

%1 Date and time of form submission %2 User’s IP address

%3 Remote user

%4 The HTTP client used (web browser)

%5 Unique ID number – this generates a number which is unique to each invocation of MailForm. You can use this to generate a tracking or serial number for the message

Default Value:

Submitted at %1 from %2

Example:

<input type=”hidden” name=”_1_MailIntro”

value=”Form submitted from %2 using %4 at %1”> Required:

(16)

13

4.9 _1_SuccessDocument, etc.

The _1_xxxxxDocument fields all allow you to provide a URL that MailForm redirects the user to, based on the result of the form submission. The value of the fields must be a URL, either relative or absolute. It can not be a filename.

Ordinarily you will provide at a minimum the _1_SuccessDocument field. If you do not provide a URL for a given document, a default message is shown to the user – however this is very basic and looks unprofessional, so it is a good idea to provide a URL for each possible outcome.

The documents that can be provided are: _1_SuccessDocument

Shown to the user when the operation succeeds – that is, the form submission was successful and the email message was successfully sent.

_1_FailureDocument

Shown to the user when the operation fails. In reality, this document is only used when the actual email sending fails – other failures due to missing or incorrect form information trigger other documents. The email sending can fail for several reasons – see the section on the _1_MailServer field for more information.

_1_InvalidCardDocument

This document is shown to the user when the form includes a credit card field (a field prefixed with _3_), and they did not enter a valid credit card number. Of course MailForm can not actually check that the card number they entered actually exists – all it can do is verify that it “looks” like a valid credit card number (based on a standard algorithm that is used to generate the numbers for all major credit cards). This document is also shown if the user leaves a _3_ field empty and the _1_AcceptEmptyCardField system field is not specified in the form.

_1_RequiredFieldDocument

This is shown to the user when the user failed to supply data for one or more required fields (fields prefixed with _4_). MailForm does no checking on the actual content of the data – it simply checks to see if the field is empty or not.

_1_CardNotAcceptedDocument

This document is used when you have used the _1_AcceptedCards field to specify the credit cards that you will accept, and the user enters the number of a non-accepted type of credit card into a _3_ credit card field.

_1_InvalidEmailDocument

Shown to the user when they do not enter a valid looking email address into a _5_ email address field. MailForm does not check that the actual address is valid, it simply checks that the information entered “looks like” an email address.

(17)

_1_NoHotmailDocument

If you have set the _1_NoHotmail field in the form, and the user enters into a _5_ email address field an address from Hotmail, Yahoo or another “anonymous” email provider, this document is shown to them. This allows you to reject “anonymous” email addresses to cut down on credit card fraud.

_1_BadRefererDocument

This document is shown to the user if you have used the RefererCheck function of the INI file (described later) to prevent unauthorised use of your copy of MailForm, and a form submission from an “unauthorised referrer” occurs.

_1_FileTooBigDocument

If your form allows file uploads, this document is shown to the user if they attempt to upload a file exceeding the size limit you have set with the _1_FileUploadLimit (if specified).

_1_ConditionalSuccessDocument

This field lets you specify a success document, similar to the _1_SuccessDocument, however it allows you to specify different URLs which are used depending upon the value of another field in the form. The syntax for this field is:

_1_ConditionalSuccessDocument=<field name>,<match string>,<URL> For example,

_1_ConditionalSuccessDocument=_4_ProductToOrder,MailForm, http://www.company.com/confirm-mailform.html

The field name is the the name of any field in the form. The match string is any text string, that is compared against the contents of the field specified by field name. The string does not have to match exactly – a sub-string will do (for example, “Mail” would match “MailForm”). URL is the URL to redirect the user to if the field matches the supplied string.

You can have as many conditional success documents as you like. If no conditional success fields match, the default _1_SuccessDocument is used instead.

Default Value:

Simple message applicable to each condition

Example:

<input type=”hidden” name=”_1_SuccessDocument” value=”http://www.company.com/success.htm”> Required:

(18)

15

4.10 _1_SortFields

This field causes the field values in the email message to be sorted by field name. By default, the field values are simply displayed in the order they appear in the form – using this field, you can cause them to be sorted. Of course, if you are using a template to generate the email message, this field has no effect. There are two different sort methods – alphabetical, and numerical.

To enable alphabetical sorting, set the value of the _1_SortFields field to 1. For example, this would produce the following results in the email message:

Fields _1_SortFields not specified _1_SortFields = 1

UserName UserName CardNumber

HomeAddress HomeAddress EmailAddress _4_EmailAddress EmailAddress HomeAddress

_3_CardNumber CardNumber UserName

Note that the _x_ header of field names is ignored when sorting.

The second sorting method, numerical, allows you to specify exactly the order that the fields are listed in. To use this method, set the value of the _1_SortFields field to 2. Then you must prefix the names of your fields with a number specifying the order you want it to appear in the email. The number must come after the _x_ header, if applicable. For example:

Fields _1_SortFields not specified _1_SortFields = 2

3UserName UserName EmailAddress

4HomeAddress HomeAddress CardNumber

_4_1EmailAddress EmailAddress UserName _3_2CardNumber CardNumber HomeAddress

Note that neither the _x_ header or the number that you add to the field name are displayed in the email.

Default Value:

None

Example:

<input type=”hidden” name=”_1_SortFields” value=”1”> Required:

(19)

4.11 _1_TextLog, _1_HTMLLog, _1_CommaDelimitedLog

The logging options allow you to log all form submissions to a continuously growing file. There are three different types of log files - you can use any combination of logging options together, and logging to a file does not affect the sending of the form as an email message.

The log file must be specified as the full DOS path of the file – you can not supply a URL. MailForm (or the user that the web server runs as) must have write access to this file.

For security reasons, the filenames of the log files are restricted - the text and comma logs must end with a .txt extension, and the name of the HTML log must end with either .htm or .html. If the filename you specify does not comply with these restrictions, the log will be disabled.

The text and the HTML logs both log the exact contents of the email message that is sent for each form submission. The comma log, however, logs the form values as a comma-delimited file, with one form submission per line. This format is suitable for importing into a database such as Microsoft Access.

Default Value:

None

Example:

<input type=”hidden” name=”_1_TextLog” value=”c:\logs\textlog.txt”> Required:

(20)

17

4.12 _1_StripEmptyFields

This field causes all empty form fields – that is, those that the user has not supplied any data for – to be excluded from the email message. Normally, all form fields (except for the _x_ fields that are usually hidden) are included in the email, whether or not the user has supplied data for them. To enable this option, set the field value to 1. This field has no effect if you are using a template file.

Default Value:

None

Example:

<input type=”hidden” name=”_1_StripEmptyFields” value=”1”> Required:

(21)

4.13 _1_NoHotmail

This field lets you reject email addresses from “anonymous” email providers like hotmail.com, yahoo.com, bigfoot.com, etc. While we don’t have anything against these companies, our own experience has shown that not accepting sales orders from anonymous email addresses cuts our incidence of credit card fraud by about 90%.

If you have set the _1_NoHotmail field in the form, and the user enters into a _5_ email address field one of these anonymous addresses, the form submission is rejected and the user is redirected to the document specified by the _1_NoHotmailDocument field.

Default Value:

None

Example:

<input type=”hidden” name=”_1_NoHotmail” value=”1”> Required:

(22)

19

4.14 _1_AcceptedCards

This field works in conjunction with the _3_ credit card fields, which are described later. It lets you specify which credit card types you can accept. If a card number is entered into a _3_ field that is not one of your accepted types, the form submission fails and the user is redirected to the _1_CardNotAccepted document. If this field is not specified, all credit card types are accepted.

To specify the cards you can accept, you must add the required values from the following table and specify the total as the value for the _1_AcceptedCards field:

1 Mastercard 2 Visa 4 American Express 8 Diners Club 16 Discover 32 JCB

For example, a business that accepts only Mastercard (1), Visa (2) and American Express (4), would specify the value of _1_AcceptedCards as 7 (1 + 2 + 4).

Default Value:

None

Example:

<input type=”hidden” name=”_1_AcceptedCards” value=”7”> Required:

(23)

4.15 _1_AcceptEmptyCardField

Normally a _3_ credit card field also acts as a _4_ required field – if the user doesn’t specify a value at all, the form submission fails. However, if you specify the _1_AcceptEmptyCardField field, a user can leave a _3_ field blank and it will be accepted.

This might be useful if, for example, you wanted to give your customers the option of providing a credit card number online or phoning or faxing their credit card details in while still submitting the order online.

Default Value:

None

Example:

<input type=”hidden” name=”_1_AcceptEmptyCardField” value=”1”> Required:

(24)

21

4.16 _1_FileUploadLimit

MailForm supports the HTML input field type FILE, to enable the user to upload files to you via the web. The file is sent as a MIME-encoded attachment to the email message that MailForm sends.

To enable file upload, you must specify the _1_FileUploadLimit field. As its name suggests, it lets you specify a maximum size that you want to allow the user to upload. If you want to enable file uploads but do not wish to set a size limit, set the value of this field to 0. Otherwise, set it to the desired size in bytes. If this field is not supplied, MailForm will ignore FILE input fields.

If you have specified a maximum size, you should also use the _1_FileTooBigDocument field to specify the URL to redirect the user to if they try to exceed the size limitation.

For file uploads to work, you must also set the encoding type of the form to multipart/form-data. For example,

Default Value:

None

Example:

<input type=”hidden” name=”_1_FileUploadLimit” value=”100000”> Required:

(25)

5. Other field prefixes

As well as the _1_ system fields described in chapter 4, MailForm supports several other field prefixes.

_2_ Ignore Fields

The _2_ prefix can be added to the name of any fields on the form that you don’t want displayed in the email message. For example, all forms must have a Submit button that allows the user to actually send the form data, however you don’t usually want the value of the Submit button appearing in your email message. You would therefore give the Submit button the field name _2_Submit to prevent its inclusion in the email.

_3_ Credit Card Fields

The _3_ field prefix lets you verify that a credit card number entered by the user is a valid card number. Of course MailForm can not actually check that the card number they entered actually exists – all it can do is verify that it “looks” like a valid credit card number (based on a standard algorithm that is used to generate the numbers for all major credit cards). Credit card numbers can be entered with or without spaces.

If any field names begin with _3_ MailForm will check to see whether the contents are a valid credit card number. If not, the form submission will fail and the _1_InvalidCardDocument file will be served to the user. The form submission will also fail if a _3_ field is left empty and you have not specified the _1_AcceptEmptyCardField option.

_4_ Required Fields

Any fields prefixed with _4_ are treated as required fields – that is, the user must supply some data for them. The actual information provided is not checked in any way – the field just must not be left empty. If a field marked with _4_ is left empty, the form will fail and the document specified with the _1_RequiredFieldDocument will be shown to the user.

_5_ Email Field

The _5_ prefix lets you mark a field as an email address field, and MailForm will check its contents to verify that it conforms to the usual pattern of a valid email address - it must have a @ character and contain no spaces. If the field does not look like a valid email address, the form fails and the user is redirected to the URL specified by the _1_InvalidEmailDocument field. You can also use the _1_NoHotmail field to reject email addresses from anonymous email providers.

(26)

23

6. The MailForm.INI file

As well as the form field-based configuration system, MailForm has the option of using an external configuration file, known as the INI file.

There are several reasons why you might want to use an INI file instead of using hidden fields. The major reason is probably that of security – even though the fields are “hidden”, they are still able to be seen by any who loads the page simply by viewing the page source code. If you use an INI file, the configuration information is stored in a completely different file and is not able to be seen by the user.

Another reason is for convenience. If you are using MailForm to support multiple forms on your web site, you can set up one INI file with common parameters rather than having to re-configure every form with the settings for the same mail server, message intro line, etc.

The name of the INI file defaults to mailform.ini, however you can change this on a per-form basis using the _1_INIFile system field. If you use this field, you should specify the full path name (not a URL) of the INI file, otherwise the INI file should be placed either in the cgi-bin directory along with the MailForm program, or the Windows or Windows System directory.

The INI file looks much like other Windows INI files; it starts with a section header, and then consists of multiple optional name/value pairs, one per line. For example:

[Settings] MailIntro=Submitted at %1 from %2 MailServer=mail.company.com [email protected] [email protected] MailSubject=Message Subject SuccessDocument=http://www.company.com/success.htm

For the most part, the value names that the INI file supports are the same as the _1_ system field names. The following table lists the INI file value names and their system field equivalents:

INI file value System field equivalent

MailTo _1_MailTo MailServer _1_MailServer MailSubject _1_MailSubject MailFrom _1_MailFrom CCMailFrom _1_CCMailFrom MailTemplate _1_MailTemplate MailIntro _1_MailIntro SuccessDocument _1_SuccessDocument FailureDocument _1_FailureDocument InvalidCardDocument _1_InvalidCardDocument RequiredFieldDocument _1_RequiredFieldDocument CardNotAcceptedDocument _1_CardNotAcceptedDocument InvalidEmailDocument _1_InvalidEmailDocument NoHotmailDocument _1_NoHotmailDocument BadRefererDocument _1_BadRefererDocument FileTooBigDocument _1_FileTooBigDocument SortFields _1_SortFields TextLog _1_TextLog HTMLLog _1_HTMLLog CommaLog _1_CommaDelimitedLog StripEmptyFields _1_StripEmptyFields NoHotmail _1_NoHotmail AcceptedCards _1_AcceptedCards AcceptEmptyCardField _1_AcceptEmptyCardField FileUploadLimit _1_FileUploadLimit

(27)

Note that the _1_ConditionalSuccessDocument field does not have an INI file equivalent. This is because this feature is only useful if you specify more than one conditional document, and the INI file format does not support more than one value with the same name (while you can, however, have multiple form fields with the same name). Similarly, the MailTo value can not be specified more than once in the INI file, like it can in the form. It can, however, still take multiple email addresses separated by commas. There are four additional values supported in the INI file that do not have form field equivalents:

Status

This value lets you define the “status code” that is returned by MailForm to redirect the http client (browser) to a new page. By default (if it is not given in the INI file), no status code is used, and MailForm returns a parsed HTTP response. This is how you will usually leave it, as it is

supposed to work for all servers and browsers.

However, some servers seem not to like the standard output that MailForm generates. Therefore, if you specify a Status code, MailForm will produce a non-parsed HTTP response, using the status code that you supply. Again, the actual status code seems to vary from server to server. Status 303 should work (it is the one designed for this process), but some servers (eg Alibaba) don't seem to like it. Try the following codes if you are having problems: 303, 302, 301, 201, 200.

RefererCheck

This value lets you (attempt to) stop unauthorised people from using your copy of MailForm, by allowing you to specify the valid referrers that you will accept. This can stop unauthorised people setting up forms on their web sites and then using your copy of MailForm to process them. If RefererCheck is not specified, anyone can access MailForm. If you specify this value, MailForm compares it against the HTTP_REFERER value that the web server receives from the web browser. If the referrer is not an approved one, the form submission fails and the user is instead shown the _1_BadRefererDocument (or a default error message if no document is specified). The value of this field should be set to the usual web address of your web site (eg www.company.com). The comparison is performed on a sub-string level. For example, if your website address is www.biginternationalcompany.com, you could specify biginternational as the referrer string and this would be matched successfully.

If you have multiple domains that you want to allow to use MailForm on your system, specify the appropriate domain names separated by commas. You can specify up to 10 domains this way. For example,

RefererCheck=www.domainone.com,www.domaintwo.com,www.domainthree.com If you want to specify more than 10 domains, you can set the value of RefererCheck to the name (including the full DOS path – not a URL) of an external text file. This text file should contain one domain name on each line. Using this method you can specify as many domains as you need.

FooterMessage

The FooterMessage field lets you specify a text message that is added to the end of all email messages that MailForm sends. It must be specified on one line, and the maximum length of this message is 400 characters. Within the message, you can use the following escape codes:

\n New line \t Tab character

Please note that the FooterMessage field is only available if your copy of MailForm has been registered. Otherwise, an internal footer message is used.

(28)

25 IgnoreFormFields

The IgnoreFormFields field allows you to enhance the security of your MailForm configuration. If you set the value of this field to 1 in your INI file, MailForm will totally ignore any _1_ system fields that are present in the form, and will only take configuration parameters from the INI file. This allows you to prevent the situation where someone uses your copy of MailForm with their own form settings.

Both the FooterMessage and MailIntro fields can take the name of an external text file to read the value from, instead of specifying the value directly (this is useful if you want to specify multiple lines of text). To do this, the value you supply should begin with two } characters, followed immediately by the full DOS path name (not a URL) of the text file to read the information from. For example,

(29)

7. Frequently Asked Questions

• How can I get the email message to appear to come from the user who submitted it?

This is possible providing you have a field on your form for the user to enter their name. It is not possible to "pick up" the user's email address automatically.

In the simplest case, you would have two fields:

The first field provides a space for the user to enter their email address. The _5_ prefix for this field name makes MailForm check it for validity.

The second field is the system field that sets the 'from' address of the email message. In this case you are telling MailForm to get the address from the value of another field on the form, _5_EmailAddress.

• MailForm is not finding my template file!

You have probably specified the template as a URL or a relative path. Usually, you need to specify it as an absolute path for MailForm to be able to find it. For example,

<input type="hidden" name="_1_MailTemplate"

value="c:\inetpub\wwwroot\template.txt">

If you do not specify a path (eg, value="template.txt") MailForm will look for the template file in the cgi-bin directory and the root of the web, however in some situations this appears to be unreliable. Your best bet is to specify the full path. You must NOT specify the path as a URL, as this will not work.

MailForm Copyright 2000 Left Side Software Pty Ltd

MailForm

© Copyright 2000

Left Side Software Pty Ltd

Licence Policy and Copyright Notice

Left Side Software Pty Ltd

PO Box 2252

Strawberry Hills, NSW 2012

Australia

Table Of Contents

2. Installing MailForm

3. Using MailForm

4. Configuring MailForm with the _1_ fields

4.1 _1_MailTo

4.2 _1_MailServer

4.3 _1_MailSubject

4.4 _1_MailFrom

4.5 _1_CCMailFrom

4.6 _1_INIFile

4.7 _1_MailTemplate

4.8 _1_MailIntro

4.9 _1_SuccessDocument, etc.

4.10 _1_SortFields

4.11 _1_TextLog, _1_HTMLLog, _1_CommaDelimitedLog

4.12 _1_StripEmptyFields

4.13 _1_NoHotmail

4.14 _1_AcceptedCards

4.15 _1_AcceptEmptyCardField

4.16 _1_FileUploadLimit

5. Other field prefixes

6. The MailForm.INI file

7. Frequently Asked Questions