Originally CGIMLS was purely for handling subscription/unsubscriptions to email lists, but now it's evolved into something more... A full fledged email scripting tool - perfect for not only ListServers, but for form submissions, 'Send a link to a friend' buttons, or anything else you can imagine!

AnalogX CGIMLS is designed to work with any SMTP server, whether they run on NT or Unix - but keep in mind that you can ONLY run CGIMLS from a Windows machine, NOT from anything else. It works find with any webserver, from IIS to Apache to AnalogX SimpleServer:WWW. This version introduces the use of a unique configuration file and HTML file, which are both stored in a directory called /mlsdata (normally this would be in /cgi-bin/mlsdata/). Here's a rundown of the commands that are currently supported:

LOG: This is what will be stored in the log, if enabled SUCCESSFUL: This is the full URL that the user will be redirected to if everything goes fine. If this is left out, then it will optionally use the HTML section 'successful' REQUIRED: This can be used to specify any form parameters that MUST be returned in order to be considered successful. Each entry should be delimited by commas. SERVER: This should be your SMTP mail server TONAME: This should be the verbose name the email is addressed to. (ex; John Doe) TOEMAIL: This should be the address the email should be sent. FROMNAME: Same as TO, except this is who it's from. FROMEMAIL: Same as TO, except this is the email address it's from. SUBJECT: The subject line of the email BODY: This is the body of the email. Enclosed with the executable are two example configurations, listserver.txt, which has sample settings for a listserver, and tellfrnd.txt, for a 'Send this link to a Friend'.

So how does it work? Simple, any parameter in a form is scriptable inside the config, so in the example:

    TO:     "{Config.ToName}" <{Config.ToEmail}>

 
This will take the parameter 'ToName' and place it inside the quotes, and the parameter 'ToEmail' and place it inside the <>, so if you had the following:

    <input type="hidden" name="ToName" value="Billy" />


    <input type="hidden" name="ToEmail" value="bill@domain.com" />

 
it would be translated into:

    TO:     "Billy" <bill@domain.com>

 
If it's confusing, then I recommend installing the program and experiment with your email address as the target, at typing in other things - you'll quickly get the hang of things. You're not limited in the number of parameters you make, or their size, so it should scale well to just about any application. There are also two special cases that should be pointed out - if the parameter name contains the word 'email', then it will check to ensure that the email address entered is valid. Also, if you have a parameter that ends with the word 'DoubleCheck', it will compare it against the stripped version of the name, and fail if they don't match. For example; if you have a parameter name 'ToEmailDoubleCheck', not only is it going to be checked to ensure the address is valid, but it's going to look for a parameter called 'ToEmail' (the parameter minus the DoubleCheck), and ensure that they match as well.

For each associated config file, there also is a html file which is used in case an error is encountered. If you look inside the html file you'll see that it contains comments which look like this:

    <!-- BEGINPAGE:header -->

 
These delineate the different sections of the file, and also customize error messages returned. When an error message is returned, it starts with the error immediately followed by the parameter which cause the error. For example, if you had a parameter called UserEmail which was invalid, it would look for this tag:

    <!-- BEGINPAGE:InvalidUserEmail -->

 
(case doesn't matter) The errors returned are the following:

    No          = A required parameter was not found
    Invalid     = Only on email addresses; does not conform to valid email
    Bad         = A DoubleCheck failed - Bad is only returned in conjunction with the DoubleCheck parameter

There are also several predefined sections:

    header      = This is displayed before everything else
    footer      = This is displayed after everything else
    successful  = This is displayed if the config doesn't have a successful URL in it
    senderror   = The SMTP (mailer) couldn't send the mail for some reason
    body        = This is the main body of the html (usually this contains your form to fill out)

If an error is encountered, it will output in the following order:

    header -> error message -> body -> footer

If it is successful, then it will output:

    header -> successful -> footer

or alternately redirect to the successful URL.

When calling CGIMLS, you must specify the two fields, one called Config which specifies what config file to use. The second field is Mode, which can be either 'Display', in order to display the current page without any processing, or 'Send' to have the page be processed and sent if successful.

Also, if you create a dir called 'logs' inside /mlsdata, then it will log all of the CGIMLS operations performed by users, which can be handy in gauging how many users are subscribing to your list vs. unsubscribing, or where emails are getting sent.

If you need to check the version number, you can get it by typing the following at the command prompt:

    cgimls /?

it will display the version, subversion, and release status.

It's been extensively tested with Ipswitch IMail Server and Microsoft IIS 5.0 and with AnalogX SimpleServer:WWW without any snags, but it should be able to work with any webserver and any other listserver programs that support the same command arguments.