Category: | |
Author/Contact Info | Apologies for literally assaulting you with my "yet another" cgi mail script. I sincerely hope no harm has been done. Vladb. |
Description: | Please use NMS scripts. |
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: CGI Contact Form / Mailer
by merlyn (Sage) on Feb 14, 2006 at 02:01 UTC | |
Your code: doesn't forbid a newline. If that newline is inserted into the header of the message, a spammer can create an arbitrary subject and sender, and then a blank line, permitting an arbitrary body. Sure, your added header and sender will be at the bottom of the message, but at that point, who cares? Also, just being able to send a message to a recipient designated by a form field is considered very bad manners in this day and age. Please discontinue the promotion of your mailscript. -- Randal L. Schwartz, Perl hacker
| [reply] [d/l] |
by vladb (Vicar) on Feb 14, 2006 at 05:26 UTC | |
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: 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 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. _____________________ "We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare. Now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California | [reply] [d/l] [select] |
by merlyn (Sage) on Feb 14, 2006 at 13:38 UTC | |
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 ...I guess my statement regarding the world not needing yet another mailform program is driven by two things: -- Randal L. Schwartz, Perl hacker
| [reply] |
Re: CGI Contact Form / Mailer
by davorg (Chancellor) on Feb 14, 2006 at 13:48 UTC | |
You might like to consider the nms formmail instead.
-- <http://dave.org.uk> "The first rule of Perl club is you do not talk about
Perl club." | [reply] |
Re: CGI Contact Form / Mailer
by chanio (Priest) on Feb 14, 2006 at 16:19 UTC | |
The whole aspect of the site is very simple and clean. And speaks a lot about what could be expected of the work done. I like the spaces left between the information. I share your pride of having your good code working as expected. I also did my own form mailer. It was my first code done with CGI::Application and HTML::Template. But I wouldn't show it here, since it might be far from being perfect in what today matters: security, ecology, style, etc.
| [reply] |
by vladb (Vicar) on Feb 14, 2006 at 16:30 UTC | |
Looking back, I don't know what devil pushed me to package it up for public consumption. I should really think twice next time.. or at the least, maybe post it in the Discussion session for some constructive criticism. _____________________ "We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare. Now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California | [reply] |
by chanio (Priest) on Feb 14, 2006 at 16:49 UTC | |
Then, other fans like me (or that just wanted to correct Matt's big and famous mistakes: NMS), rewrote all those well known scripts correcting all their security flaws and adding some tested modules. Why? Because, modules are like 'cans' of experience in specific aspects. I wouldn't dare to write better ones without spending some years in the effort. They are done by people that have to deal with certain issues because of their work and afterwards they decide to share their experience with the perl community to make all our jobs easier, better and 'safer'. Normally, after trying coding all by myself (without any module), the next step is doing a newer version all handled by modules. It is very easy after I have understood all what was required to do it on my own. It is a safer code because there are lots of security aspects to take into acount in order to put my code in the web. We all have to learn this lesson, since it is never well explained from the start. Don't worry. Next code published, try to do it simpler or with modules. That's all!
| [reply] |
by davorg (Chancellor) on Feb 15, 2006 at 11:10 UTC |