freelanceprogrammers.org Forum Index » Perl
Formmail hell - is there a way out?
Joined: 18 May 2006
Posts: 3
Formmail hell - is there a way out?
I may have just gotten unlucky here but let me share my story...
I`m somewhat new at web development but have many years experience in
programming.
I Made a website for someone. They needed a contact form. I was told
formmail.pl is the thing to use. Make a form and post that form to
formmail.pl. Great. Simple. Badda bing badda boom. Done.
Except after days of headbanging frustration I could never get it to
work and a programmer friend then sent me a PHP version of formmail
that worked immediately.
At this point you are probably thinking that the fool (me) just didn`t
understand the syntax of setting up the @referers array or the
@recipients array. Trust me I do. At this point I could write a thesis
on it! Execute permissions on the file(s)? Been there done that.
Multiple times. I made sure to educate myself on that stuff before
going on, the methodical type that I am. Yet it was one error after
another no matter what I did. Typically "HTTP Error 403 Forbidden" or
"Internal server error".
I tried formmail.pl from sourceforge.net, http://www.formmail.com/ and
from Matt`s script archive. Same issue. 403 or "Internal Server Error"
I have tried on 2 different servers: 1and1.com and ourinternet.us.
Then I tried something called formmail nms (from sourceforge),
configured it and same problem: "Internal Server Error".
I tried the old formmail.pl on a different site (hosted by 1and1) and
suddenly it *worked*. Except not on all machines. Worked on some but
others got an error 403.
At this point I was seriously frustrated and just to prove to myself
that I was not insane I copied several copies of formmail that had
failed on other servers - I thought because I didn`t understand
@referrers or @recipients and - guess what *all but one worked!* I had
not been making syntax errors after all! On one site they work (only
on some machines) on another "error 403" on all machines. I checked
the differences between machines (internet settings in IE and so forth
and could come up with nothing).
Then a friend gave me a php script to do the same thing and it worked
immediately and has not failed.
Except that it was given to him by a friend, he does not even know
where it came from originally and the documentation sounds like it was
written by a 13 year old. But it works like a champ right out of the
box and formmail does not after days of trying.
OK so here is my suspicion: big hosts like 1and1 and ourinternet are
doing something that hamstrings formmail (plausable given it`s
potential for abuse by spammers). The support reps at both hosts deny
this and insist that formmail should work but their expertise seems
(very) limited and when I try to bump the problem upstairs they say
they "don`t provide help with scripting" and *insist* that I must have
messed up the @referrers or @recipients array or set permissions
wrong. When I sent them copies proving everything was set correctly
and insisting on an answer I received *no reply back*
OK, I relized I`m in formmail hell.
So my question(s) are as follows: is formmail.pl still considered the
standard solution for the back end of a contact form? If not what is.
It seems clear that at least two major hosts are doing something to
frustrate it - the `403 forbidden` error pretty much states the obvious.
I guess I`m looking for a good standard way of doing this. Something
that does pretty much exactly what formmail.pl is supposed to do but
works - or at least is not prevented from operating by commercial hosts.
Any ideas?
Joined: 16 Jun 2004
Posts: 9
Formmail hell - is there a way out?
You probably didn`t have the correct permissions set on the host server.
They need to be given execute permissions - chmod 755 - for the server to
execute the script.
When you upload the file to the cgi-bin folder using an FTP client, you
subsequently need to select the file and use the clients` options to change
permissions.
Joined: 16 Jun 2004
Posts: 9
Formmail hell - is there a way out?
On 5/17/06 8:01 PM, n_fischer_h at nhermanc@... wrote:
> or at least is not prevented from operating by commercial hosts.
PS. Formmail is a generic form handler; it`s not a "standard" form handler
by any means, merely one available for folk who aren`t familiar with writing
their own. Once you have learned perl it`s far more effective to write your
own form handlers that do exactly what you want.
ISP hosts are really truly not bothered by formmail.pl ... Don`t worry,
there is no concerted attempt by large corporations to subvert the little
guys low-key code ...
Joined: 19 May 2006
Posts: 2
Formmail hell - is there a way out?
I don`t know much...but I know enuff to get in trouble....
I beleive the Recipient (the owner of the form) in the HTML and
the Recipient in the cgi must match.....
If you already know that... well... I don`t know what else to say.
Lou
----- Original Message -----
From: n_fischer_h
To: Perl_Official@yahoogroups.com
Sent: Friday, May 19, 2006 12:00 AM
Subject: Re: [Perl] Formmail hell - is there a way out?
No, I did indeed set the permissions to 755. Am working on a page that
will demonstrate the problems I`m having.
In the mean time I`d like to share (another) one of the problems I had
and I bet I`m not the only one. Amazingly there seems to be no
documentation on this - yet it`s critical.
When I submitted to formmail.pl like so:
<form action="http://www.somesitesomewhere.com/formmail.pl"
method="post" enctype="multipart/form-data" name="contact_form"
id="contact_form">
I got: "Error Bad/No Recipient"
even though the recipient array was set up correctly. I took out the
enctype="multipart/form-data" and it worked. I had tried about 3000
other things (of course) before I stumbled on enctype.
>From http://www.htmlcodetutorial.com I read:
"ENCTYPE determines how the form data is encoded." and "if you want to
do file uploads you should use "multipart/form-data otherwise..".
So the "Error Bad/No Recipient" was (very!) misleading. Formmail was
probably not interpreting *anything* coming into it correctly and the
first place it puked was looking for a recipient - which was probably
just garbage characters due to enctype being wrong.
This leads to a couple of questions: does a pearl script have no way
of doing data validation? Actually I can think of one obvious way: set
a hidden field in the form to a certain value, pass it to the script,
have the script check that that exact value came though if not then
give an error message indicating that there is a problem with the
passing of the data. Don`t go to square 1, don`t look for recipients,
referrers, just give an error message.
Next question: why did I use enctype="multipart/form-data" in the
first place. A: I was moving a site for a customer from one host to
another and that is how the form was set up on the old host. I didn`t
change a thing. I just copied the file to the new host and it would
not work in the new location. This leads to the REAL question here:
how did it work on his old host with the wrong enctype. I suspect
Apache settings somehow come into play: maybe it was configured in a
"forgiving" way on the old host but not on the new one. Maybe enctype
must be set in a way to match settings on the server. Or maybe it was
something else. Regardless, the enctype setting is critical to
formmail and it should be documented!
But there is no documentation on this enctype thing anywhere within 50
light years of formmail.pl. Nothing. Nada. Zip. Yet with the wrong
enctype it fails catastrophically and gives a misleading error message
to boot!
Sometimes I wonder if 99% of the programmers out there have Asperger
syndrome because this is critical stuff to know about yet no one seems
to communicate it.
And this enctype thing was just the beginning of my problems with
formmail. Tomorrow I will have a page up there that will demonstrate
some of the other ones.
Finally, sorry for the rant, I know you guys are here to help :)
--- In Perl_Official@yahoogroups.com, Mike Southern <gb1198@...> wrote:
>
> You probably didn`t have the correct permissions set on the host server.
> They need to be given execute permissions - chmod 755 - for the
server to
> execute the script.
>
> When you upload the file to the cgi-bin folder using an FTP client, you
> subsequently need to select the file and use the clients` options to
change
> permissions.
>
SPONSORED LINKS C programming language Computer programming languages Java
programming language
The c programming language C programming language Concept of
programming language
------------------------------------------------------------------------------
YAHOO! GROUPS LINKS
a.. Visit your group "Perl_Official" on the web.
b.. To unsubscribe from this group, send an email to:
Perl_Official-unsubscribe@yahoogroups.com
c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.6.1/343 - Release Date: 5/18/06
[Non-text portions of this message have been removed]
Joined: 19 May 2006
Posts: 2
Formmail hell - is there a way out?
Another thought.
I have been told that Matts Script has security issues.
but that another code that is used by my web host has
a mail form cgi that has fixed these issues.
FormMail Clone is clone of Matt Wright`s FormMail under a less restrictive
liscense. It should behave almost exactly as FormMail.cgi, but it is completely
written from scratch so there might be a few minor visual differences.
if you can get this code and rewrite it to your needs.....
just a thought.
Lou
----- Original Message -----
From: Lou Hernsen
To: Perl_Official@yahoogroups.com
Sent: Thursday, May 18, 2006 8:48 PM
Subject: Re: [Perl] Formmail hell - is there a way out?
I don`t know much...but I know enuff to get in trouble....
I beleive the Recipient (the owner of the form) in the HTML and
the Recipient in the cgi must match.....
If you already know that... well... I don`t know what else to say.
Lou
----- Original Message -----
From: n_fischer_h
To: Perl_Official@yahoogroups.com
Sent: Friday, May 19, 2006 12:00 AM
Subject: Re: [Perl] Formmail hell - is there a way out?
No, I did indeed set the permissions to 755. Am working on a page that
will demonstrate the problems I`m having.
In the mean time I`d like to share (another) one of the problems I had
and I bet I`m not the only one. Amazingly there seems to be no
documentation on this - yet it`s critical.
When I submitted to formmail.pl like so:
<form action="http://www.somesitesomewhere.com/formmail.pl"
method="post" enctype="multipart/form-data" name="contact_form"
id="contact_form">
I got: "Error Bad/No Recipient"
even though the recipient array was set up correctly. I took out the
enctype="multipart/form-data" and it worked. I had tried about 3000
other things (of course) before I stumbled on enctype.
>From http://www.htmlcodetutorial.com I read:
"ENCTYPE determines how the form data is encoded." and "if you want to
do file uploads you should use "multipart/form-data otherwise..".
So the "Error Bad/No Recipient" was (very!) misleading. Formmail was
probably not interpreting *anything* coming into it correctly and the
first place it puked was looking for a recipient - which was probably
just garbage characters due to enctype being wrong.
This leads to a couple of questions: does a pearl script have no way
of doing data validation? Actually I can think of one obvious way: set
a hidden field in the form to a certain value, pass it to the script,
have the script check that that exact value came though if not then
give an error message indicating that there is a problem with the
passing of the data. Don`t go to square 1, don`t look for recipients,
referrers, just give an error message.
Next question: why did I use enctype="multipart/form-data" in the
first place. A: I was moving a site for a customer from one host to
another and that is how the form was set up on the old host. I didn`t
change a thing. I just copied the file to the new host and it would
not work in the new location. This leads to the REAL question here:
how did it work on his old host with the wrong enctype. I suspect
Apache settings somehow come into play: maybe it was configured in a
"forgiving" way on the old host but not on the new one. Maybe enctype
must be set in a way to match settings on the server. Or maybe it was
something else. Regardless, the enctype setting is critical to
formmail and it should be documented!
But there is no documentation on this enctype thing anywhere within 50
light years of formmail.pl. Nothing. Nada. Zip. Yet with the wrong
enctype it fails catastrophically and gives a misleading error message
to boot!
Sometimes I wonder if 99% of the programmers out there have Asperger
syndrome because this is critical stuff to know about yet no one seems
to communicate it.
And this enctype thing was just the beginning of my problems with
formmail. Tomorrow I will have a page up there that will demonstrate
some of the other ones.
Finally, sorry for the rant, I know you guys are here to help :)
--- In Perl_Official@yahoogroups.com, Mike Southern <gb1198@...> wrote:
>
> You probably didn`t have the correct permissions set on the host server.
> They need to be given execute permissions - chmod 755 - for the
server to
> execute the script.
>
> When you upload the file to the cgi-bin folder using an FTP client, you
> subsequently need to select the file and use the clients` options to
change
> permissions.
>
SPONSORED LINKS C programming language Computer programming languages Java
programming language
The c programming language C programming language Concept of
programming language
------------------------------------------------------------------------------
YAHOO! GROUPS LINKS
a.. Visit your group "Perl_Official" on the web.
b.. To unsubscribe from this group, send an email to:
Perl_Official-unsubscribe@yahoogroups.com
c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.6.1/343 - Release Date: 5/18/06
[Non-text portions of this message have been removed]
SPONSORED LINKS C programming language Computer programming languages Java
programming language
The c programming language C programming language Concept of
programming language
------------------------------------------------------------------------------
YAHOO! GROUPS LINKS
a.. Visit your group "Perl_Official" on the web.
b.. To unsubscribe from this group, send an email to:
Perl_Official-unsubscribe@yahoogroups.com
c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.6.1/343 - Release Date: 5/18/06
[Non-text portions of this message have been removed]
Joined: 18 May 2006
Posts: 3
Formmail hell - is there a way out?
No, I did indeed set the permissions to 755. Am working on a page that
will demonstrate the problems I`m having.
In the mean time I`d like to share (another) one of the problems I had
and I bet I`m not the only one. Amazingly there seems to be no
documentation on this - yet it`s critical.
When I submitted to formmail.pl like so:
<form action="http://www.somesitesomewhere.com/formmail.pl"
method="post" enctype="multipart/form-data" name="contact_form"
id="contact_form">
I got: "Error Bad/No Recipient"
even though the recipient array was set up correctly. I took out the
enctype="multipart/form-data" and it worked. I had tried about 3000
other things (of course) before I stumbled on enctype.
From http://www.htmlcodetutorial.com I read:
"ENCTYPE determines how the form data is encoded." and "if you want to
do file uploads you should use "multipart/form-data otherwise..".
So the "Error Bad/No Recipient" was (very!) misleading. Formmail was
probably not interpreting *anything* coming into it correctly and the
first place it puked was looking for a recipient - which was probably
just garbage characters due to enctype being wrong.
This leads to a couple of questions: does a pearl script have no way
of doing data validation? Actually I can think of one obvious way: set
a hidden field in the form to a certain value, pass it to the script,
have the script check that that exact value came though if not then
give an error message indicating that there is a problem with the
passing of the data. Don`t go to square 1, don`t look for recipients,
referrers, just give an error message.
Next question: why did I use enctype="multipart/form-data" in the
first place. A: I was moving a site for a customer from one host to
another and that is how the form was set up on the old host. I didn`t
change a thing. I just copied the file to the new host and it would
not work in the new location. This leads to the REAL question here:
how did it work on his old host with the wrong enctype. I suspect
Apache settings somehow come into play: maybe it was configured in a
"forgiving" way on the old host but not on the new one. Maybe enctype
must be set in a way to match settings on the server. Or maybe it was
something else. Regardless, the enctype setting is critical to
formmail and it should be documented!
But there is no documentation on this enctype thing anywhere within 50
light years of formmail.pl. Nothing. Nada. Zip. Yet with the wrong
enctype it fails catastrophically and gives a misleading error message
to boot!
Sometimes I wonder if 99% of the programmers out there have Asperger
syndrome because this is critical stuff to know about yet no one seems
to communicate it.
And this enctype thing was just the beginning of my problems with
formmail. Tomorrow I will have a page up there that will demonstrate
some of the other ones.
Finally, sorry for the rant, I know you guys are here to help :)
--- In Perl_Official@yahoogroups.com, Mike Southern <gb1198@...> wrote:
>
> You probably didn`t have the correct permissions set on the host server.
> They need to be given execute permissions - chmod 755 - for the
server to
> execute the script.
>
> When you upload the file to the cgi-bin folder using an FTP client, you
> subsequently need to select the file and use the clients` options to
change
> permissions.
>
Joined: 16 Jun 2004
Posts: 9
Formmail hell - is there a way out?
On 5/19/06 12:00 AM, n_fischer_h at nhermanc@... wrote:
> No, I did indeed set the permissions to 755. Am working on a page that
> will demonstrate the problems I`m having.
>
> In the mean time I`d like to share (another) one of the problems I had
> and I bet I`m not the only one. Amazingly there seems to be no
> documentation on this - yet it`s critical.
I guess you`ve tried most things then. Sorry, I can`t help any more.
There probably isn`t much documentation; many generic and/or home-grown
general purpose scripts out there are somewhat sparse.
After a very short time, I realised that once I had access to a server that
would let me run scripts it was much easier to write my own than it was to
hack around with others` GP creations. You`ll probably end up with the same
opinion. What formmail is trying to do is not that difficult.
Joined: 03 Jul 2005
Posts: 15
Formmail hell - is there a way out?
n_fischer_h wrote:
: This leads to a couple of questions: does a [perl] script have
: no way of doing data validation?
The script gets the raw data from each field. Generally, we
use CGI.pm, not that internal form parser in formmail, to process
the field data into a usable form and then we can do what ever
validation we wish. There are some modules which ease validation
for common fields, like phone numbers and email. There`s also
Regexp::Common to quickly roll your own.
But I think you are referring to authentication, not
validation.
: Actually I can think of one obvious way: set a hidden field in
: the form to a certain value, pass it to the script, have the
: script check that that exact value came though if not then give
: an error message indicating that there is a problem with the
: passing of the data. Don`t go to square 1, don`t look for
: recipients, referrers, just give an error message.
A session can do this, but the recipient in a formmail form is
usually someone connected with the web site. There are probably
only a handful of people receiving the email. Better to write a
script for each form type and send the mail to a permanent
forwarding email box.
For example, you could set the site up with three scripts
which send mail from a form to sales@..., webmaster@...,
and customerservice@.... These boxes could be set up to
automatically forward mail only. When a web site person wants to
add a new salesperson at john@..., he just changes the email
forward to include John from the secure account control panel.
Now the recipient can be changed from a secure area without
having to go into the script or to go through the hassle of
authenticating the form. Since the three scripts are so similar,
it should be trivial to share much of the code.
Writing a script like this from scratch makes you a real hero.
The web site people can use just those scripts to process any
number of forms and call you when they need to add a new form
type. You get repeat business and the web site administrator can
control everything without calling you each time she hires or fires
someone.
: Regardless, the enctype setting is critical to formmail and it
: should be documented!
The old formmail should not be used. The nms version has a
mailing list which allows user contributions and I`ll bet you
could ask them to update those docs.
: But there is no documentation on this enctype thing anywhere
: within 50 light years of formmail.pl. Nothing. Nada. Zip. Yet
: with the wrong enctype it fails catastrophically and gives a
: misleading error message to boot!
Another reason to nail that coffin shut and not use that
script. According to Matt`s Script Archive (who`s address I will
*not* place in this mailing list), formmail v1.91 was written on
4/19/02. That`s four year old code!
: Sometimes I wonder if 99% of the programmers out there have
: Asperger syndrome because this is critical stuff to know about
: yet no one seems to communicate it.
Documentation often lags implementation in the best
organizations and you want it to be there for crappy little
scripts like formmail. You`re like that ant and the rubber plant,
aren`t you? :)
: Finally, sorry for the rant, I know you guys are here to help :)
Your story is amusing. I had similar problems wrapping my mind
around a wwwboard.pl program. I kept looking at it and saying,
"What was he thinking?" and, "Why go through all that trouble?"
Then I would remind myself just how long four years is on the
internet. That`s a really long time ago.
HTH,
Charles K. Clarkson
--
Mobile Homes Specialist
Free Market Advocate
Web Programmer
254 968-8328
Don`t tread on my bandwidth. Trim your posts.
Joined: 18 May 2006
Posts: 3
Formmail hell - is there a way out?
Thanks.
I think the lessons I`ve learned here are:
- Use newer stuff
- Write your own when it`s not to big of a deal.
- Either use your own web server or be very familiar with the one you
are using.
--- In Perl_Official@yahoogroups.com, "Charles K. Clarkson"
<cclarkson@...> wrote:
>
> n_fischer_h wrote:
>
> : This leads to a couple of questions: does a [perl] script have
> : no way of doing data validation?
>
> The script gets the raw data from each field. Generally, we
> use CGI.pm, not that internal form parser in formmail, to process
> the field data into a usable form and then we can do what ever
> validation we wish. There are some modules which ease validation
> for common fields, like phone numbers and email. There`s also
> Regexp::Common to quickly roll your own.
>
> But I think you are referring to authentication, not
> validation.
>
>
> : Actually I can think of one obvious way: set a hidden field in
> : the form to a certain value, pass it to the script, have the
> : script check that that exact value came though if not then give
> : an error message indicating that there is a problem with the
> : passing of the data. Don`t go to square 1, don`t look for
> : recipients, referrers, just give an error message.
>
> A session can do this, but the recipient in a formmail form is
> usually someone connected with the web site. There are probably
> only a handful of people receiving the email. Better to write a
> script for each form type and send the mail to a permanent
> forwarding email box.
>
> For example, you could set the site up with three scripts
> which send mail from a form to sales@..., webmaster@...,
> and customerservice@... These boxes could be set up to
> automatically forward mail only. When a web site person wants to
> add a new salesperson at john@..., he just changes the email
> forward to include John from the secure account control panel.
>
> Now the recipient can be changed from a secure area without
> having to go into the script or to go through the hassle of
> authenticating the form. Since the three scripts are so similar,
> it should be trivial to share much of the code.
>
> Writing a script like this from scratch makes you a real hero.
> The web site people can use just those scripts to process any
> number of forms and call you when they need to add a new form
> type. You get repeat business and the web site administrator can
> control everything without calling you each time she hires or fires
> someone.
>
>
> : Regardless, the enctype setting is critical to formmail and it
> : should be documented!
>
> The old formmail should not be used. The nms version has a
> mailing list which allows user contributions and I`ll bet you
> could ask them to update those docs.
>
>
> : But there is no documentation on this enctype thing anywhere
> : within 50 light years of formmail.pl. Nothing. Nada. Zip. Yet
> : with the wrong enctype it fails catastrophically and gives a
> : misleading error message to boot!
>
> Another reason to nail that coffin shut and not use that
> script. According to Matt`s Script Archive (who`s address I will
> *not* place in this mailing list), formmail v1.91 was written on
> 4/19/02. That`s four year old code!
>
>
> : Sometimes I wonder if 99% of the programmers out there have
> : Asperger syndrome because this is critical stuff to know about
> : yet no one seems to communicate it.
>
> Documentation often lags implementation in the best
> organizations and you want it to be there for crappy little
> scripts like formmail. You`re like that ant and the rubber plant,
> aren`t you? :)
>
>
> : Finally, sorry for the rant, I know you guys are here to help :)
>
> Your story is amusing. I had similar problems wrapping my mind
> around a wwwboard.pl program. I kept looking at it and saying,
> "What was he thinking?" and, "Why go through all that trouble?"
> Then I would remind myself just how long four years is on the
> internet. That`s a really long time ago.
>
>
> HTH,
>
> Charles K. Clarkson
> --
> Mobile Homes Specialist
> Free Market Advocate
> Web Programmer
>
> 254 968-8328
>
> Don`t tread on my bandwidth. Trim your posts.
>
Joined: 03 Jul 2005
Posts: 15
Formmail hell - is there a way out?
n_fischer_h wrote:
: - Write your own when it`s not [too] big of a deal.
I would amend this to:
Custom solutions are often better than general solutions.
Writing your only script can be more dangerous than using
a very well written general script.
HTH,
Charles K. Clarkson
--
Mobile Homes Specialist
Free Market Advocate
Web Programmer
254 968-8328
Don`t tread on my bandwidth. Trim your posts.
All times are GMT
Page 1 of 1
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Freelace Website Designer - Customer web design and software building.
China Wholesale - Electronics Products
Character Studio - Tutorials and Help
China Wholesale - Electronics Products
Character Studio - Tutorials and Help