Thanks for the catch, merlyn. But ...

if you examine the script closer, it is not mandating the use of any form fields to determine the recepient. Instead, the script is relying on internal config to determine these values. There's only an option to include the form field that is available to the user. Although, I admit, I may have to include a disclaimer about potential risks involved in using such form field. Yet, I did use similar script on some of my clients' internal company servers for feedback collection, in which case, a hidden form field containing recepient email address wouldn't pose any threat. This does appear to be a case of an older feature making it's way to the final revision. Which, as you pointed out, may not be a good thing.

In fact, the only form field "required" to run the script is the special _mf_ parameter. And even that may be omitted if the script is using the default config only. Also the parameter is retreived from the outside environment in a safe manner:

    my $mf = $cgi->param('_mf_');
    $mf =~ s/\.\/\\//g; # remove . \ / chars
    $mf ||= "default";
[download]

The rest is and should be all configured via internal .conf files, further minimizing any outside tampering with the script. Additional security measure could be to taint check the rest of 'information' fields that are being sent along with the email.

conf/default.conf

# smtp server
SMTP_HOST=mail.yourhost

SMTP_PORT=110

SMTP_TIMEOUT=60

# name form imputs which are lists (comma separated)
# FORM_INPUT_LISTS=

# recipient email
RECIPIENT=myemail@myhost.com

# sender field required
REQUIRE_SENDER=no

# sender field (from html form)
SENDER_FIELD=EMAIL

# subject (could contain html::template variables!)
SUBJECT=Contact From <TMPL_VAR NAME>, <TMPL_VAR COMPANY>

# mail template (to the recipient)
MAIL_TMPL=mail

#------------- CONFIRM ------------
# sender template (optional)
# mail to be sent to the sender
CONFIRM_MAIL_TMPL=mail_confirm

# subject of the confirmation email
CONFIRM_SUBJECT=Thank you for your interest in ...
# 
CONFIRM_REPLYTO=mycontact@myhost.com

#------------- OK -----------------
# redirect when mail was sent ok
#
REDIRECT_OK=/thankyou.shtml

# template to use on successful send
# (overrides redirect_ok)
# 
# TMPL_OK=<template path>

#------------- FAIL ---------------
# redirect when couldn't send mail and other non system errors
#
# REDIRECT_FAIL=<url path>

# template to use on failure
# (overrides redirect_fail)
#
TMPL_FAIL=fail

#----------- USER ERROR -----------
# template for usage error page
#
TMPL_USER_ERROR=user_error

# redirect url on user (usage) error
# (user_error_tmpl will be ignored)
#
# REDIRECT_USER_ERROR=<url path>
[download]

You are right on the other items though, and I admit script needs alittle rework around potential security holes.

And yet, despite of all said, I am baffled that having made the effort to package and give the script away, I'm simply asked to fold it back. It truly is a disappointing loss of my time ...

Please, don't take me wrong though. I do thoroughly appreciate the fact that unlike others who chose to -- this contribution, you actually made the effort and took some of your scarce time to include an explanation for doing so.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.