MailForm Copyright 2000 Left Side Software Pty Ltd

MailForm Copyright 2000 Left Side Software Pty Ltd Current Version : 1.96

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 jpotter@lss.com.au 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 http://www.lss.com.au i

Table Of Contents Licence Policy and Copyright Notice...i 2. Installing MailForm...2 3. Using MailForm...3 4. Configuring MailForm with the _1_ fields...4 4.1 _1_MailTo...5 4.2 _1_MailServer...6 4.3 _1_MailSubject...7 4.4 _1_MailFrom...8 4.5 _1_CCMailFrom...9 4.6 _1_INIFile... 10 4.7 _1_MailTemplate... 11 4.8 _1_MailIntro... 12 4.9 _1_SuccessDocument, etc... 13 4.10 _1_SortFields... 15 4.11 _1_TextLog, _1_HTMLLog, _1_CommaDelimitedLog... 16 4.12 _1_StripEmptyFields... 17 4.13 _1_NoHotmail... 18 4.14 _1_AcceptedCards... 19 4.15 _1_AcceptEmptyCardField... 20 4.16 _1_FileUploadLimit... 21 5. Other field prefixes...22 6. The MailForm.INI file...23 7. Frequently Asked Questions...26 ii

1. Introduction MailForm is an easy-to-use and highly configurable CGI program for Windows that sends the results of a submitted form as an email message. MailForm requires that there be a SMTP mail server accessible from the web server machine in order to send the email. Some of the features of MailForm include: - Highly configurable using hidden form tags or an external INI file - Validity checking for any field (data supplied, valid email address, etc) - Valid credit card number checking - Able to block certain types of credit card (eg, if you don t accept Diners) - Able to reject anonymous email addresses like Hotmail - Can be made to reject unauthorised use to prevent other people using your copy of MailForm for their own forms - Text, HTML and comma-delimited logging capabilities - Conditional redirection based on the value supplied in specified fields - File upload supported using the INPUT TYPE=FILE tag Please note : MailForm requires Windows 95, 98, Millenium, NT 4.0, Win2000 or later to run. It will not run on a Unix/Linux based web server. 1

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. 2

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: <form action= /cgi-bin/mailform.exe method= post > 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: <form action= /cgi-bin/mailform.exe method= post enctype="multipart/form-data"> 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. 3

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 2 3 4 5_ System Field. This is used to control MailForm s behaviour. Ignore Field. Any field with this prefix will be excluded from the email that is sent. Credit Card Field. Used to check for a valid credit card number. Required Field. MailForm will complain if a field with this prefix is not filled in. 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 _1_MailServer _1_MailSubject _1_MailFrom _1_CCMailFrom _1_INIFile _1_MailTemplate _1_MailIntro _1_SuccessDocument _1_FailureDocument _1_InvalidCardDocument _1_RequiredFieldDocument _1_CardNotAcceptedDocument _1_InvalidEmailDocument _1_NoHotmailDocument _1_BadRefererDocument _1_ConditionalSuccessDocument _1_FileTooBigDocument _1_SortFields _1_TextLog _1_HTMLLog _1_CommaDelimitedLog _1_StripEmptyFields _1_NoHotmail _1_AcceptedCards _1_AcceptEmptyCardField _1_FileUploadLimit Address to email the results to SMTP server Subject line of the email Address email is to come from Email is also sent to the address in _1_MailFrom Specifies an alternative ini file to use Specifies a template to generate the message with Sets the email introduction line (header) URL to return if the operation succeeds URL to return if the operation fails URL to return for an invalid credit card number URL to return if a required field is missing URL to return for a credit card that's not accepted URL to return for an invalid email address URL to return for a rejected anonymous email address URL to return when the form is "referred" by an unauthorised host Conditionally redirect to a different document on success URL to return when an uploaded file exceeds the size limit you have set Set this field to cause fields to be sorted in the email Set this to log all form submissions to a text file Set this to log all form submissions to an HTML file Set this to log all form submissions to a commadelimited text file Set this to cause empty fields to be removed from the email Set this to reject anonymous "hotmail" addresses Set this to specify the credit cards accepted Will accept an empty _3_ field as valid Used to limit the size of uploaded files 4

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. none Example: <input type= hidden name= _1_MailTo value= sales@mycompany.com > Yes. 5

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. none Example: <input type= hidden name= _1_MailServer value= smtp.mycompany.com > Yes. 6

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. MailForm Form Results Example: <input type= hidden name= _1_MailSubject value= Sales Order From Website > No. 7

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 mailform@lss.com.au. 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 mailform@lss.com.au 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 :-) Example 1: Example 2: mailform@lss.com.au <input type= hidden name= _1_MailFrom value= onlinesales@mycompany.com > <input type= text name= _5_Email > <input type= hidden name= _1_MailFrom value= _5_Email > No (but please set it anyway). 8

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. None. Example: <input type= hidden name= _1_CCMailFrom value= 1 > No. 9

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. Example: mailform.ini <input type= hidden name= _1_INIFile value= c:\inetpub\wwwroot\templates\formtemplate.txt > No. 10

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 straightforward: 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 predefined values which can be used: %MF_DATE% %MF_REMOTE_ADDR% %MF_REMOTE_USER% %MF_USER_AGENT% %MF_UNIQUE_ID% Date and time of form submission User's IP address Remote user The HTTP client used (web browser) 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% %32.Phone% The field would be left padded to be 20 characters wide 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% %Comments% Properly align a multi-line text field Multi-line field would not be aligned properly 11

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 Example: Submitted at %1 from %2 <input type= hidden name= _1_MailIntro value= Form submitted from %2 using %4 at %1 > No. 12

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. 13

_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. Example: Simple message applicable to each condition <input type= hidden name= _1_SuccessDocument value= http://www.company.com/success.htm > No. 14

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. None Example: <input type= hidden name= _1_SortFields value= 1 > No. 15

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. None Example: <input type= hidden name= _1_TextLog value= c:\logs\textlog.txt > No. 16

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. None Example: <input type= hidden name= _1_StripEmptyFields value= 1 > No. 17

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. None Example: <input type= hidden name= _1_NoHotmail value= 1 > No. 18

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). None Example: <input type= hidden name= _1_AcceptedCards value= 7 > No. 19

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. None Example: <input type= hidden name= _1_AcceptEmptyCardField value= 1 > No. 20

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, <form method= POST action= /cgi-bin/mailform.exe enctype= multipart/form-data > None Example: <input type= hidden name= _1_FileUploadLimit value= 100000 > No. 21

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. 22

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 MailTo=me@company.com MailFrom=sender@company.com 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 MailTo MailServer MailSubject MailFrom CCMailFrom MailTemplate MailIntro SuccessDocument FailureDocument InvalidCardDocument RequiredFieldDocument CardNotAcceptedDocument InvalidEmailDocument NoHotmailDocument BadRefererDocument FileTooBigDocument SortFields TextLog HTMLLog CommaLog StripEmptyFields NoHotmail AcceptedCards AcceptEmptyCardField FileUploadLimit System field equivalent _1_MailTo _1_MailServer _1_MailSubject _1_MailFrom _1_CCMailFrom _1_MailTemplate _1_MailIntro _1_SuccessDocument _1_FailureDocument _1_InvalidCardDocument _1_RequiredFieldDocument _1_CardNotAcceptedDocument _1_InvalidEmailDocument _1_NoHotmailDocument _1_BadRefererDocument _1_FileTooBigDocument _1_SortFields _1_TextLog _1_HTMLLog _1_CommaDelimitedLog _1_StripEmptyFields _1_NoHotmail _1_AcceptedCards _1_AcceptEmptyCardField _1_FileUploadLimit 23