Syntax
FormMail++ will read somewhat differently than Matt Wright's original script. Perl 5 no longer requires associative
array hash references to contain quotes within the braces. Global variables have been minimized and are designated
as global by a single uppercase letter in the name. Constants are also introduced using the all-uppercase convention. Lastly,
local() has been replaced by the more efficient my(). Other stylistic changes include complete
variable declaration at the start of each block and alignment of braces around blocks, which is simply a personal
preference for visual identification.
Associative Arrays
FormMail++ associative arrays are significantly different. Incoming data is first screened for legacy
"config" fields and discarded if found. Incoming data is then screened for legacy mail fields and,
if encountered, re-mapped as appropriate. All data is then placed into a single array, during which time key mail
fields are also copied into an array for mail headers so that they can be properly sanitized against malicious
intent.
| void: |
This array defines keys for legacy Config fields for FormMail (redirect, env_report,
sort, print_config, print_blank_fields, title, return_link_url, return_link_title, missing_fields_redirect,
background, bgcolor, text_color, link_color, vlink_color, alink_color). The %void{} array also suppresses
the common "submit" and "cancel" buttons. |
| trap: |
This array catches and maps the legacy Config fields for "realname" and
"email" which are mapped to "name" and "sender," respectively, and stored in the
Data and Mail associative arrays. |
| data: |
Unlike the original script, FormMail++ stores all fields in %Data{} for
easier printing and seeding into html output. |
| mail: |
During %Data{} population, name, sender, recipient, and subject are copied
to %Mail{} and all %Mail{} are subsequently scrubbed for malicious characters. FormMail++ adds optional %Mail{}
fields for cc and priority. |
CPAN Modules
FormMail++ employs five CPAN modules:
CGI::Carp,
Time::HiRes,
POSIX,
Email::Valid,
LWP::Simple, and
CGI::apacheSSI. If needed,
these modules are easily imported to the ubiquitous cPanel. Alternatively, they may be uploaded to a user's file space and
their location specified with the use lib '/...' statement). These
modules, in turn, use or require the following: CGI, vars, Fcntl, strict, warnings, IO::File, File::Spec,
Mail::Address, Scalar::Util, LWP::UserAgent, HTTP::Status, HTTP::Date, Carp, Exporter, DynaLoader, XSLoader, APR::Pool,
ModPerl::Util, Apache2::Response, Apache2::RequestRec, Apache2::RequestIO, Apache2::RequestUtil, IO::CaptureOutput,
Net::DNS, Net::Domain::TLD, and Tie::Hash. This is provided as information only and no action should be required with
respect to these modules.
Limitations
FormMail++ cannot elegantly return a php source page since php is compiled by the daemon at the time of the request.
However, this is unlikely to be an issue since php developers will probably be using a php form handler. But, the
limitation can be remedied using LWP
to load the php source page via loopback. The confirmation html should be outputted as a massive string, assigned to
a variable, and inserted back into the LWP-retrieved html via a s/<form.*form>/$output/m substitution.
FormMail++ also expects the entire <form action...> tag to appear on a single line. There can only be
one <form action...> directed at the script. If the page designer really wants two such forms on the
page (weird?), the action attribute of each form must point to a unique script name. This means that there must be
two FormMail++ scripts with different names. Otherwise, only the first <form action...> will be substituted.