Sunday, April 11, 2010
FormMail Character Revue, Part 1
Like a storybook, FormMail has
a cast of characters. These
character determine the character
of FormMail itself.
FormMail is really a character-
driven story. It is the characters
that move the story along.
In this particular case, I'm referring
specifically to NMS FormMail,
though, when it comes to a cast of
characters, any FormMail will do. That
is to say, each version of FormMail will
also have a cast of characters, though
not precisely the same as these characters.
The first character we should consider
is the @allow_mail_to array. More
than being a single person, this is an
association of sorts. It's a club.
Everyone in this club can receive a
copy of the submitted form. This is
very similar to the To Field in
an email. The @allow_mail_to array
determines who can receive the filled-out
form as an email.
The @allow_mail_to array determines
who can receive the form as email, not
who will. In this sense it is like a
country club where all club members are
are eligible to play golf but not all
will.
The next character to consider is the
%recipient_alias hash array.
This character works just like the
@allow_mail_to array except that
this character works undercover.
Whereas the @allow_mail_to array
openly publishes its membership, the
%recipient_alias hash array is
secretive about its membership. Basically,
the %recipient_alias hash array is
a secret society.
Again, %recipient_alias hash array,
is a recipient array only in terms of potential.
Not everyone on the list will receive the filled-out
form as an email.
Why? Because in the case of both the @allow_mail_to array
and the %recipient_alias hash array receivership
is determined by who actually gets their email address
listed in the HTML form itself.
That's where secrecy comes in handy. If you would
like to hide your email address from spambot harvesters,
you will prefer the %recipient_alias hash array
over the @allow_mail_to array. The %recipient_alias
hash array hides your email address by describing it
with an alias rather than publishing it directly in
the HTML of your form. This foils spammers who
would like to put you on their list to receive more
spam.
What's the lesson here? Know who you can trust. If
you know you can't trust everyone, you will not be
inclined to publish your email address in a place
where it can be read publicly.
Your website and consequently, your HTML Form
is a public place. Anyone can read it as HTML Anyone
can pick up your email address this way.
Using the %recipient_alias hash array
solves the problem. This array keeps things
simple for you. Only the FormMail program
itself knows your email address, not the general
public.
Ed Abbott
Monday, April 5, 2010
Enabling CGI to Get FormMail.pl Working
I just encountered something new. I'm
doing some work at a web hosting company
where I've never ever tried to get a CGI
script working before.
The name of the hosting company I'll withhold;
however, I've been happy with them in the
past, and so I'm back again having chosen them
as the web hosting company for the website
I'm currently working on.
I asked their support team, via online chat,
why the supplied test scripts that are found
in cgi-bin are not working. Turns out
that cgi-bin needs to be enabled.
Can't say I blame them for requiring this. This
is just one more layer of defense against having
the web hosting account hijacked by the bad guys.
Here's what their support team said to me via
online chat:
CGI scripts require the cgi-bin directory to be
enabled for your site, otherwise they will not
work. To enable the cgi-bin:
- Log into your Hsphere control panel @ http://www.hosting.com/login.html
- Click on web options.
- Click on "Add" next to CGI dir
- Enter /cgi-bin as the directory alias.
- Click "Changes need to be applied".
Once you have done this, your scripts should
start working within 30 minutes.
Since this may be a layer of defense (a very
minor layer of defense) for the hosting company
in question, I've decided not to publish their
name.
However, the principle could possibly be fairly
universal. If the simplest of simple CGI scripts
does not work, it could be that CGI has to be
enabled in the web hosting account control panel.
Seems that setting up the simplest of CGI forms
can be time-consuming for this reason. In spite
of the simplicity of CGI, because of its power
and versatility, it often seems to be hobbled
in some way or another by the web hosting company.
This may be to keep the CGI folder from being obvious
to the bad guys.
Finding out how to get even the simplest CGI
script, such as FormMail, can be time-consuming
until it is realized that it is not intended
to work without intervention.
What's the lesson?
Situations that appear to be identical may not
be identical at all. Assuming that a cgi-bin
directory will actually work may not be a safe
assumption. It may turn out that what appears
to be a normal situation requires further investigation.
Each situation, no matter how similar
it may appear to be to a prior situation,
is, in reality, its own situation.
Ed Abbott
How to Do Email Forwarding From a Web Form
Email forwarding is when one
email account is forwarded
to another:
Here are some of the advantages
of email forwarding:
- When you change email addresses,
you can forward the old email address
to the new email address - If you have more than one email
address, you can forward all email
to one email address - Form mail can be received
at an email account native to
the website form but then forwarded
to a non-native email account.
What is a native email account? It
is youremail@yourdomain.com.
What is a non-native email account? It
is youremail@someoneelsesdomain.com.
See the difference? A native account
has your domain name included in the email
addresss. A non-native account has
a domain name other than your domain
name included in the email address.
By definition, a Gmail account is a
non-native account. By definition,
your.name@gmail.com is non-native.
That is, unless you own the domain name
gmail.com. Nobody does. It's
a corporate name owned by Google.
Corporate domain names are non-native
and the domain name that you personally
own is native. Why ami I making such
a big deal about this?
I'm making a big deal about it because
it can make the difference between
getting your form to work and not having
it work. At many hosting companies, sending
your email form to a non-native email account
is not allowed.
It's a form of spam protection. By disallowing
non-native email accounts, the web hosting
company protects themselves from being used
as a spam relay.
It's hard to relay spam if the only place the
spam ever goes to is the domain name that
is native to your website and not any
other place. That's not much of a coup
for a spammer.
More later.
Ed Abbott
Subscribe to:
Posts (Atom)