Comments does not require any special DLLs, run-time modules, or other support files. It is a 32-bit compiled C program.

Refer to your web server's documentation to ensure that standard CGI is enabled for the server, and that the CGI directory has the proper execute permissions.

On IIS, make sure that the IUSR_ account has Change rights in the temp directory. On other servers, ensure that the SYSTEM account, or user account under which the server runs, has Change rights in the temp directory.

Note: Enabling CGI on IIS for Windows Server 2003 and later requires additional configuration. See this article from our Knowledgebase for details.

If you are having trouble getting CGI programs to run, especially on IIS, then you might want to search our knowledgebase for help. Answers to the most-frequently asked questions are there.

Comments is invoked through the POST method on an HTML FORM. The basic syntax is

<FORM method="POST" action="/cgi-bin/comments.exe">
<INPUT TYPE="type" NAME="name" VALUE="initial value">
<INPUT TYPE="submit" VALUE=" Submit "> <INPUT TYPE="reset" VALUE=" Reset ">
</FORM>

In the examples given, we assume that your CGI directory is a virtual directory called /cgi-bin. Substitute the name of your own CGI directory when using these examples on your own system. The default virtual directory for CGI on Microsoft's IIS is /scripts.

Default Output Filename Variable

Comments writes its output to a file called comments.txt by default. The first time you run Comments, it writes this information to the registry as the Default Output Filename variable. Thereafter, Comments will use the value of this variable when assigning a default filename. If a filename is specified as part of the FORM, the specified value will override the default filename with a few exceptions:
1. If you have enabled the ForceExtension value, then Comments will always use the file extension you specify in the registry.

2. If a FORM specifies an extension of .bat, .cmd, .asp, .asa., ,pif, .wsh, .com, .exe, .vbs, .vbe, .js, .jse, .wsf, .cdx, .cer, .htr, .htw, .ida, .idc, .idq, .stm, .shtm, or .shtml, then Comments will replace the extension with .txt. This is to prevent malicious visitors from creating executable files on your server.

If you set the Default Output Filename to NUL, then Comments will not create an output file at all unless a filename is specified on the FORM.

ConfigDir Variable

By default, Comments uses c:\temp\comments as its working directory. Comments uses the system TEMP variable and the executable's filename to FORM the directory name, so if you rename comments.exe to mycomments.exe, the default output path would be c:\temp\mycomments. Comments will create this directory if it does not already exist.

The first time you run Comments 1.8, Comments will attempt to determine and create a proper working directory. This information is written to the registry as the ConfigDir variable. You may use Registry Editor to change this value to any legal path on your machine. Caution: You should not set the path to a directory that can be reached by your web or ftp server unless you fully understand the security issues involved. If your output file contains any sensitive information, and you make it available to visitors, you are opening a serious security hole on your system.

The ConfigDir directory is used for:

1. Output files
2. Template files (if used)
3. The debug file (if any)

Example 1: <FORM method="POST" action="/cgi-bin/comments.exe">
This tells Comments to write its output to the Default Output Filename (usually comments.txt) in the ConfigDir directory (usually c:\temp\comments).

Example 2: <FORM method="POST" action="/cgi-bin/comments.exe/myfile.txt">
This tells Comments to write its output to a file called myfile.txt in the ConfigDir directory.

Example 3: <FORM method="POST" action="/cgi-bin/comments.exe/otherdir/myfile.txt">
This tells Comments to write its output to a file called myfile.txt in the ConfigDir/otherdir directory. If ConfigDir is set to c:\temp\comments, the full filename will be c:\temp\comments\otherdir\myfile.txt. Note that Comments will not create the otherdir subdirectory. Except for the main directory set in the ConfigDir variable, paths must be pre-existing.

Example 4: <FORM method="POST" action="/cgi-bin/comments.exe/NUL">
This tells Comments to write its output to the NUL device (that is, no output file at all).

Note that for security reasons, you cannot normally specify an absolute path or a UNC path. If you specify a path, it must be a subdirectory under the ConfigDir directory, and the subdirectory must already exist.

HTML Variables

• Template
  Allows you to specify a file to use as an output format template for email. For example, <INPUT TYPE=HIDDEN NAME=template VALUE="sales.tem"> would tell Comments to use the file sales.tem (located in the ConfigDir directory) as the template to use when formatting email output. See Templates for details.

• ErrorPage
  Works in conjunction with the Required tag (see below). If this variable is present, Comments uses your own HTML pages for error messages about missing required variables. If this variable is absent, Comments generates simple error messages on the fly instead. (See Example 5 for a demonstration.) For example, if you have variables called phone and name and both are required, you could use <INPUT TYPE=HIDDEN NAME=errorpage VALUE="http://www.yourcompany.com/errorpages/*.html"> to have Comments display http://www.yourcompany.com/errorpages/phone.html when the phone field is left blank, and http://www.yourcompany.com/errorpages/name.html when the name field is missing. Comments substitutes the name of the missing field for the asterisk (*) in the URL you provide. If you don't include an asterisk, for example, <INPUT TYPE=HIDDEN NAME=errorpage VALUE="http://www.yourcompany.com/whoopsie.html"> then Comments adds a pound sign and the name of the missing field to the end of the URL, to FORM a reference to a section within the page. For example, if the phone field is missing, Comments would redirect the browser to http://www.yourcompany.com/whoopsie.html#phone.

  You may choose (by including or omitting the asterisk) whether to use one file for all of your error messages, or a separate file for each error. If you use one file (no asterisk in the ErrorPage URL), then you should include one <a NAME="fieldname"> tag within your file for each field that can generate an error. If you use multiple files (with an asterisk in the ErrorPage URL), then you must have one file for each field that can generate an error.

• MailFromErrorPage
  Special error-handling tag to catch SMTP response when the sender's email address is unacceptable. Use <INPUT TYPE=HIDDEN NAME=MailFromErrorPage VALUE="http://yourserver.com/path/pagename.html"> if you want to provide a custom error notification page for this error. If this HIDDEN tag is not present, Comments will generate a standard error page.

• MailToErrorPage
  Special error-handling tag to catch SMTP response when one or more of the recipient email addresses is unacceptable. Use <INPUT TYPE=HIDDEN NAME=MailToErrorPage VALUE="http://yourserver.com/path/pagename.html"> if you want to provide a custom error notification page for this error. If this HIDDEN tag is not present, Comments will generate a standard error page.

• Required
  If this variable is present, Comments will generate an error if the specified fields are not filled out by the visitor. For example, <INPUT TYPE=HIDDEN NAME=required VALUE="name,address"> would require the visitor to enter something in both the name and address fields. You may enter as many field names as you want. Separate fields with a comma.

• Autonumber
  If this variable is present, Comments will generate a unique number based on the date and time, and include this number in the output file (and email, if email is used). The value may be blank. If the value is not blank, it is used to preface the generated number. For example, <INPUT TYPE=HIDDEN NAME=autonumber VALUE=Inv> would produce something like this in the output file: Autonumber=Inv19960609-104617-444.

• CopySender
  If this tag is present on an email FORM, a copy of the email is automatically sent to the person filling out the FORM. The tag may be a HIDDEN field -- <INPUT TYPE=HIDDEN NAME=copysender VALUE=yes> -- or a checkbox -- <INPUT TYPE=checkbox NAME=copysender>. In the first case, the webmaster is in control of whether or not CopySender is enabled. In the second case, the user may choose (by checking the box) whether or not to get a copy.

• Debug
  If this variable is present, with a value of yes, then Comments will write a trace of all SMTP transactions to comments.log in the CGI directory. To enable debugging, include <INPUT TYPE=HIDDEN NAME=debug VALUE=yes> in your FORM code. To disable debugging, either remove the line or set the value to no.

• MailTo
  If this special variable is present, Comments will attempt to mail the output to the value provided. For example, <INPUT TYPE=HIDDEN NAME=mailto VALUE=techsupport@greyware.com> would mail the output to techsupport@greyware.com. You can use either "mailto" or "to" as the variable name. Note: When MailTo is present, Comments also requires email to be present and filled in by the user or a HIDDEN variable. You must also set the SMTP host value before the first time you use Comments to send email.

  You may include more than one name in the value of the mailto tag. Names must be separated by a comma. For example, <INPUT TYPE=HIDDEN NAME=mailto VALUE=name1@greyware.com,name2@somewhere.else> would send the email to name1@greyware.com and name2@somewhere.else.

  Note: If you set the registry varible Mail To Email Address to anything other than blank (the default), then Comments will use the value in the registry and ignore any MailTo on the FORM.

• Email
  If the MailTo variable is present, Comments expects this variable to be the email address of the sender. It should therefore be filled in by the user. For example, Your Email Address: <INPUT TYPE=text NAME=email> would prompt the user to fill in his email address. You may use "email," "e-mail", or "mail" as the name of this variable.

  Note: If you set the registry varible Mail From Email Address to anything other than blank (the default), then Comments will use the value in the registry and ignore any Email address on the FORM.

• From
  If the MailTo variable is present, the value of the From variable is taken to be the user's name. You may use either "from" or "name" as the name of this variable. This variable isn't required, and only has special meaning if MailTo is present.

  Note: If you set the registry varible Mail From Email Name to anything other than blank (the default), then Comments will use the value in the registry and ignore any From address on the FORM.

• Subject
  Specifies the subject line of the email. It only has special meaning if MailTo is also present. You may abbreviate the variable to "sub" or "subj" if you want.

  Example: <input type="hidden" name="subject" value="This is an email!">

• NextPage
  If this special variable is present, Comments will use the value provided as the next page to display after accepting user input. If the value is absent, Comments will display a generic "Thank you for your comments" response, and the user will have to use the browser's back button to navigate out. The syntax for this field is: <INPUT TYPE=HIDDEN NAME=nextpage VALUE=URL>. For example, to set the next page to http://your.machine.com/replies/thanks.html, you'd enter <INPUT TYPE=HIDDEN NAME=nextpage VALUE="http://your.machine.com/replies/thanks.html"> somewhere on the FORM.

• Posted
  Comments will always include a variable called Posted whose value is the date and time the comments were posted. The value will be formated like this: "Posted=Sat 06 Jan 1996 at 09:56."

• FORM Variables
  Any FORM variables are automatically included in the output with the FORM variable name=variable value. For example, if your FORM includes an input field called "Email" and the user fills in "john@doe.com," the output would contain "Email=john@doe.com."

• CGI Variables
  CGI variables are not included automatically. You choose which ones you want to show by including a HIDDEN input field with the following syntax: <INPUT TYPE=HIDDEN NAME=variable name VALUE=CGI.variable name>. For example, to include the HTTP_USER_AGENT variable and have it be called "Browser" in the output, you'd include the line <INPUT TYPE=HIDDEN NAME=Browser VALUE=CGI.HTTP_USER_AGENT>. This would produce something like "Broswer=Lynx 2.39" or "Broswer=Mozilla." To include the HTTP_REFERER variable and have it called HTTP_REFERER, you'd include the line <INPUT TYPE=HIDDEN NAME=HTTP_REFERER VALUE=CGI.HTTP_REFERER>.

  Comments looks at all input variables and, if a variable's value starts with "CGI." (uppercase "CGI" and a period), it evaluates everything following the period as the name of a CGI environment variable. It writes the value of the CGI environment variable to the output file, using the variable name provided. If Comments cannot resolve the CGI environment variable name, or if the variable is not set, it returns "Not provided" as the value.

  Note:You cannot return system variables such as USERNAME, HOMEDRIVE, or SYSTEMROOT with this syntax. Comments automatically filters out these requests and will always report the value as "Not provided."

Templates

Comments can use a template file to format its email output. Template files do not affect the formatting of the text output files Comments writes to disk.

A template file is a plain text file. The extension must be .TEM for security reasons. For example, signup.tem. Variables are indicated by using the variable name surrounded by percent signs. For example, %visitor%. Comments will substitute the value of any named variable at run time. Any other text is passed through unchanged.

Here is a sample template file:

Dear %firstname%,


Thank you for writing to ask about %productname%. One of
our representatives will call you at %phonenumber% shortly.


Sincerely,
The %productname% support team


(Your message was posted on %posted% from %remote_addr%)


Assuming you use this template with a FORM having variables called firstname, productname, and phonenumber, the email output would look something like this:

Dear John,


Thank you for writing to ask about Comments 1.8. One of
our representatives will call you at 972-555-1212 shortly.


Sincerely,
The Comments 1.8 support team


(Your message was posted on Thu 21 Dec 2000 at 01:45 from 206.207.208.201)


Note that your FORM does not have to include variables for remote_addr or posted, since the both are always present. You can use any server or FORM variable.

Command-line Parmameters

You can set many of Comments' parameters from the command line. You may specify any number of command-line parameters in any order. Case is irrelevant ("hostname" and "HOSTNAME" and "HostName" are all treated the same way.)

To check settings and status, run COMMENTS without any parameters.

To set a parameter, run COMMENTS PARMNAME=PARMVALUE, as follows:

• COMMENTS HOST=hostname
  This sets your SMTPHost name in the registry. You only need to do this once, or when you change hosts. Example: comments host=mail.mydomain.com

• COMMENTS TIMEOUT=value
  This sets the timeout value Comments uses to negotiate with other instances of itself (when fighting for access to a file), and when talking to SMTP servers (when trying to send email). Enter a number between 5 and 360. The number represents seconds; the default is 30. You probably will never have to change from the default, but you may adjust this value to suit your system's requirements. Example: comments timeout=120

• COMMENTS REGISTRATION=registration_key
  When you pay for a registration of comments, Greyware will issue you a registration key. Enter this key exactly, and Comments will upgrade itself to a registered version. Note: The only difference between the shareware and registered versions is that the shareware version will stop working after 21 days. You may then register the product by paying the registration fee and obtaining a registration key. Example: comments registration=334400,0003

• COMMENTS CONFIGDIR=drive:\path
  Tells Comments to use the drive and path (may be UNC) you specify as the root directory when looking for template files or writing output files.

You may specify most normal parameters this way, or you may set them directly in the registry if you prefer. The parameter names match the entries in the registry.

Examples

Try out Comments and see what it looks like. Remember, the appearance of the FORM and what variables get stored are up to you. Feel free to examine the source of the sample FORM to see what we did. There are four examples on the sample page, showing different features.
• Test Comments
  
• Examine the Output from Example 1
• Examine the Output from Example 2
• Examine the Output from Example 3
• Examine the Output from Example 4
• Examine the SMTP trace log from Example 3

Hints & Tips

If Comments appears to be set up correctly when you run it from the command line, but can't find the SMTP host, or thinks it's not registered, or has other problems when you run it as a CGI program, then you have a permissions problem in the system registry. Here's how to fix it:

Use regedt32.exe to grant "everyone" "read" in the following two registry keys (and check the box to include any existing subkeys): HKEY_LOCAL_MACHINE\Software\Classes\GAP HKEY_LOCAL_MACHINE\Software\Greyware

Registry Keys

Comments stores its user variables in the Registry:
   HKEY_LOCAL_MACHINE
      \Software
         \Greyware
            \Comments
               \Parameters


If you need to run multiple copies of Comments with different settings, simply make a copy of comments.exe called something else (e.g., copy comments.exe to feedback.exe, then look for \Software\Greyware\Feedback\Parameters in the registry).

Comments will create the registry keys and populate them with the default values the first time you run it. Use REGEDT32.EXE to change these values. Please be careful when you edit the registry using REGEDT32. Don't muck about with things you don't understand. You can easily make your system unbootable, or lose all your data. If you don't know how to use REGEDT32, ask a certified technician for assistance.

• HTTP Referers
  REG_MULTI_SZ. Defaults to blank
  If this value is blank, Comments will process requests from any WWW server. To restrict Comments to just your own server, or a list of servers, fill in the value with the name(s) of the server(s) you want to authorize. If any names are provided, only those names will be valid. This prevents people at other servers from running your CGI and using your mail host. Example: www.yourhost.com

• SMTPHost
  REG_SZ. Defaults to blank
  This is the name (or IP number) of the "smart host," or SMTP host you want to use to send mail. Comments will open a conversation with this host and ask it to send the mail. If you use the "mailto" variable without setting this registry value, the user will get a configuration error message. Set it to the name or IP number of a machine running Sendmail where you have privileges to send mail. For example, "sendmail.mydom.com" or "172.16.199.4" (substituting, of course, the real name or IP number of your host.)

• Field Separator
  REG_SZ. Defaults to 13,10
  This value value controls what Comments uses to separate fields in the output file. A field is a single combination of variable NAME=value. The collection of all fields from a given run is called a record. Records are always terminated by a CRLF pair. By default, each field is also terminated by a CRLF. You may, however, change this to suit your requirements. You may specify any numeric value (taken to be the decimal ASCII value of a character), or any quoted string. For example, to end each field with a vertical bar, set the Field Separator to "|" (including the quotation marks). This would produce a single-line record, with each field separated by the vertical bar, and the entire record terminated by a CRLF. You may combine quoted strings and numeric values. For example, to have the vertical bar and a single CR, use "|",13 (that's a quoted vertical bar, a comma, and 13). Pretty much any combination is legal: 13,10,"--wooga--",255 would produce a CRLF followed by --wooga-- followed by the unprintable character 255.

• Value Separator
  REG_SZ. Defaults to "=" (that's an equals sign enclosed in quotation marks)
  This value controls how Comments separates the keyword from its value in the output file and email output. The default is an equals sign, yielding something like "NAME=joe" for the variable name. You may change this value in the registry to something else -- for instance you could use 9,": " (the decimal ASCII for "tab", followed by a comma, then a colon and a space inside quotation marks), yielding something like "name       : joe" in the output. The rules for what you may use are the same as for the Field Separator above.

• SMTP EOL
  REG_SZ. Defaults to 13,10
  This value dictates how Comments terminates each line of text sent to the SMTP server. If you have trouble getting Comments to work with your SMTP host, try changing this value to either just 10 or just 13. Parsing of this field is identical to the way the Field Separator variable is parsed (see above), so you can use almost any combination of characters and control codes here. In most cases, you will not ever have to adjust this setting.

• TimeOut
  REG_SZ. Defaults to 30
  This value controls how long Comments will wait to gain exclusive access to the output file. Although on a busy web site, multiple instances of Comments may be running at the same time, they must take turns writing to the output file to prevent jumbled output. 30 seconds should be more than enough time for most sites.

• ForceExtension
  REG_SZ. Defaults to TRUE as of version 1.8.
  If set to TRUE, Comments will force all output filenames to have the extension specified by the Extension registry setting. File extensions provided via HTML will be ignored (that is, no error is generated; Comments just fixes the filename).

• Extension
  REG_SZ. Defaults to .txt as of version 1.8.
  This setting has no effect unless ForceExtension is set to TRUE. When used, this setting specifies the filename extension Comments uses for all output files. For example, setting this value to .TXT will force all output files to have the extension .TXT, no matter what is specified in the HTML.

• ConfigDir
  REG_SZ. Defaults to c:\temp\comments (or your system temp directory if not c:\temp).
  This setting specifies the directory where Comments will look for template files, and where it should write its output files. If you set this value to, say, c:\commentfiles, and your FORM specifies <FORM method=post action=/scripts/comments.exe/outfile.txt>, then Comments will write its output to c:\commentfiles\outfile.txt.

• Default Output Filename
  REG_SZ. Defaults to comments.txt as of version 1.8
  Comments will use this filename if no filename is specified on the form.

• Mail From Email Address
  REG_SZ. Defaults to blank
  If this setting is not blank, Comments will use this value as the email address portion of the sender's return address. This setting overrides whatever may be present in the Email variable on the form. For example, if this setting is fflintstone@bedrock.com, then the sender's return address will be Example <fflinstone@bedrock.com>, with the "Example" portion varying according to other settings.

• Mail From Email Name
  REG_SZ. Defaults to blank
  If this setting is not blank, Comments will use this value as the name portion of the sender's return address. This setting overrides whatever may be present on the form in the Name or From variables. For example, if this setting is Fred Flintstone, then the sender's return address will be Fred Flintstone <example@example.com>, with the "example@example.com" portion varying according to other settings.

• Mail To Email Address
  REG_SZ. Defaults to blank
  If this setting is not blank, Comments will use this value as the recipient's email address. This setting overrides whatever may be present on the form in the MailTo variable. You may provide multiple addresses by separating them with commas. For example, barney@bedrock.com,wilma@bedrock.com,bambam@bedrock.com.

• AllowAbsolutePaths
  REG_SZ. Defaults blank, or FALSE
  See "Discussion about Paths" below.

• AllowRelativePaths
  REG_SZ. Defaults to blank, or FALSE
  See "Discussion about Paths" below.

• DocumentRoot
  REG_SZ. Defaults to blank.
  See "Discussion about Paths" below.

• UseRefererPath
  REG_SZ. Defaults to blank.
  See "Discussion about Paths" below.

Discussion about Paths

Normally, Comments only allows its output files to be created in the ConfigDir directory, or a pre-existing directory "below" the ConfigDir directory.

This behavior is for the security of the files on your web server and other machines on your network. DO NOT CHANGE THIS BEHAVIOR UNLESS YOU HAVE THOUGHT THROUGH THE CONSEQUENCES CAREFULLY. We have provided options to override this security measure at customer request, but WE DO NOT RECOMMEND USING ANY OF THE FOLLOWING OPTIONS.

• AllowAbsolutePaths
  Set AllowAbsolutePaths to TRUE (use the characters "True" or the digit "1") to allow forms to use absolute paths for the output file. For example, if AllowAbsolutePaths is TRUE, then Comments will allow constructions such as <FORM method=post action="/scripts/comments.exe/c:\comments.txt">, and write its output file to c:\comments.txt.

  An absolute path begins with a drive letter-colon-backslash, or with two backslashes (a UNC file spec). For security reasons, if AllowAbsolutePaths is enabled, the output file MUST end in ".TXT"

  NOTE: THIS IS A VERY DANGEROUS OPTION. IT OPENS YOUR ENTIRE NETWORK TO THE INTERNET. WE STRONGLY DISCOURAGE USING THIS OPTION.

• AllowRelativePaths
  Set AllowRelativePaths to TRUE (use the characters "True" or the digit "1") to allow forms to use relative paths for the output file. For example, if AllowRelativePaths is TRUE, then Comments will allow constructions such as <FORM method=post action="/scripts/comments.exe/../comments.txt">. If comments.exe is located in d:\webroot\scripts, then the output file will be d:\webroot\comments.txt.

  NOTE: THIS IS A VERY DANGEROUS OPTION. IT OPENS YOUR ENTIRE NETWORK TO THE INTERNET. WE STRONGLY DISCOURAGE USING THIS OPTION.

  A relative path begins with either ".\" (relative to the current directory), or "..\" (relative to the parent directory), or contains any number of "." or ".." path specifiers within the path. For security reasons, if AllowRelativePaths is enabled, the output file MUST end in ".TXT"

  NOTE: Not all web servers will parse relative paths correctly. You may not be able to use this feature with your web server.

• DocumentRoot
  This setting is used in conjunction with UseRefererPath to allow the writing of output files into directories specified by the HTTP_REFERER variable. If your web server root directory is d:\webroot, and the HTTP_REFERER variable is /users/johnny/myFORM.html, then the output file will be written to d:\webroot\users\johnny.

• UseRefererPath
  This setting is used in conjunction with DocumentRoot to allow the writing of output files into directories specified by the HTTP_REFERER variable. If your web server root directory is d:\webroot, and the HTTP_REFERER variable is /users/johnny/myFORM.html, then the output file will be written to d:\webroot\users\johnny.

  NOTE: It is very easy for visitors to your web site to fake up an HTTP_REFERER variable, and end up writing to the wrong directory. This option is less dangerous than using AllowAbsolutePaths or AllowRelativePaths, but can still cause corrupted data or unintended results if the HTML is wrong or a malicious visitor causes mischief. WE STRONGLY DISCOURAGE USING THIS OPTION.

Security Enhancements in Version 1.8

Comments version 1.8 changes the default behavior of Comments to a more secure setting. Previous versions of Comments defaulted to generic settings and expected the administrator to (a) read all of the documentation, and (b) pay attention to and understand all of the security warnings.
• Comments now makes the ConfigDir mandatory, and defaults to a relatively safe location. The administrator must deliberately override this location in order to have output files and template files relocated to a vulnerable place.

• Comments now defaults the ForceExtension feature to TRUE, and sets the default extension to .txt. The administrator must deliberately override these two settings to allow Comments to create potentially executable files.

Version 1.8 also introduces some new checks to validate the input from the form, and defend against hacker attacks.

• Comments now checks for known executable extensions (.cmd, .bat, .wsh, and others), and replaces the extension with .txt even if the administrator has allowed these extentions or even specified one of them as the default extension.

• Comments now provides registry values to specify the mail envelope. If these values are set by the administrator, they will override any values provided on the form.

• Comments now ensures that filenames do not contain references to DOS devices (such as CON, PRN, Conout$, Conin$, and so forth) and replaces any such references with the default filename. Note that NUL is allowed, and is perfectly valid. Using a device name other than NUL is unlikely to compromise server security, but could cause Comments to stop responding for an extended period of time, and thus be used as a denial-of-service attack.