nms-cgi-devel — Developers discussion for NMS CGI programs

[Nms-cgi-devel] formmail newbie

[<gre...@ao...>]

 Hello, I am a webdesign student trying to figure out how to get forms to work on a webpage. How do I put this program to work? I don't know where to place the code from the "formmail.pl" file. I have Dreamweaver 8.
 
 or any basic tips that will help me make a contact form in a webpage would be very much appreciated.
 
 thanks
 Morgan
  
________________________________________________________________________
AOL now offers free email to everyone.  Find out more about what's free from AOL at AOL.com.

[Nms-cgi-devel] [ nms-cgi-Feature Requests-1630897 ] "From" options

[SourceForge.net <no...@so...>]

Feature Requests item #1630897, was opened at 2007-01-08 12:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425772&aid=1630897&group_id=39625

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: "From" options

Initial Comment:
The "from" address is the email of the person who filled out the form. This is usually blocked as spam by our email system. Would be nice to optionally have the "from" address set to the "mailto" address. That way I can easily whitelist our address and no form submissions will be blocked.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425772&aid=1630897&group_id=39625

[Nms-cgi-devel] [ nms-cgi-Feature Requests-1610440 ] way to prevent spam

[SourceForge.net <no...@so...>]

Feature Requests item #1610440, was opened at 2006-12-06 16:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425772&aid=1610440&group_id=39625

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Hanspeter Niederstrasser (nieder)
Assigned to: Nobody/Anonymous (nobody)
Summary: way to prevent spam

Initial Comment:
I've been getting (as well as the nms-cgi support form apparently), lots of spam being sent to me via my formmail install.  What I've noticed from all the spams I've gotten is that all the fields on the form are set to something by the bot.  Having a hidden form field set to nothing and then checking for a value when submitted should point out all spams since users won't be able to see that field.  Would this be something useful to incorporate into the next version of formail and/or TFmail?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425772&aid=1610440&group_id=39625

[Nms-cgi-devel] [ nms-cgi-Support Requests-1595361 ] [input_field] FOREACH directive - tfmail/NMStreq.pm line 689

[SourceForge.net <no...@so...>]

Support Requests item #1595361, was opened at 2006-11-12 20:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425770&aid=1595361&group_id=39625

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Install Problem (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Karen H (khuffman)
Assigned to: Nobody/Anonymous (nobody)
Summary: [input_field] FOREACH directive - tfmail/NMStreq.pm line 689

Initial Comment:
I've set up TFMail.pl. As a recipient defined in
default.trc, I receive the email including attachments
just find. My redirect file spage.trt works fine as
well, but I also want to send a confirmation email to
the person that submitted the email, so I set the
following in default.trc:

#
#Confirmation email to sender.
#
confirmation_template: email_confirm
confirmation_subject: Research Request - Confirmed
confirmation_email_from: my...@my...


And this is what I have in my email_confirm.trt file:
%% NMS email template file %%
Thank you for your research request submitted on {=
date =}. Below is a summary of your submission:
----------------------------------------------------------------------

{= FOREACH input_field =}
{= name =}: {= value =}

{= END =}
----------------------------------------------------------------------


But when I hit submit, I receive the following error:
Application Error

An error has occurred in the program

[input_field] cannot be used in a FOREACH directive at
tfmail/NMStreq.pm line 689. 


Not quite sure what I'm doing wrong. Any suggestions
would be appreciated. Thank you! Karen







----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425770&aid=1595361&group_id=39625

[Nms-cgi-devel] [ nms-cgi-Feature Requests-1585975 ] Display IP & host

[SourceForge.net <no...@so...>]

Feature Requests item #1585975, was opened at 2006-10-27 12:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425772&aid=1585975&group_id=39625

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Display IP & host

Initial Comment:
I would like a feature that lets me choose in the
config to display the IP and host in the guestbook or not.

for example a entry in the guestbook should look like this

Nice guestbook!
Ingrid
IP: 83.227.27.235
(c-eb1be353.1170-1-64736c10.cust.bredbandsbolaget.se)
Sweden - monday, 23 oktober, 2006 kl. 10:14:54 (CEST).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425772&aid=1585975&group_id=39625

[Nms-cgi-devel] [ nms-cgi-Feature Requests-1563012 ] Feature Requests: Result Padding / Linebreaks

[SourceForge.net <no...@so...>]

Feature Requests item #1563012, was opened at 2006-09-21 13:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425772&aid=1563012&group_id=39625

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: kwyjibo (kwyjibox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Feature Requests: Result Padding / Linebreaks

Initial Comment:
I would like to request two features for NMS Formmail.

1. A choice of padding the e-mailed results with
additional spaces, so that all of the submitted data
lines up. This provides improved readability. The
padding would be based upon the length of the longest
named field, and would be optional, set with either a
hidden input field or in the user config, but
preferrably the former.

2. Provide a way to insert a blank line into e-mailed
results, to improve readability by separating chunks of
submitted information. This would be very useful for
large forms.

Thanks. :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425772&aid=1563012&group_id=39625

Re: [Nms-cgi-devel] [Nms-cgi-support] only older versions available?

[Todd A. S. <smi...@gm...>]

On 7/30/06, Bob Peters <bo...@bo...> wrote:
>  From http://sourceforge.net/projects/nms-cgi I clicked the "Download
> nms" link to a page at http://sourceforge.net/project/showfiles.php?
> group_id=39625 which listed 3.12 as the current formmail release.
> Clicking the link gives me http://sourceforge.net/project/
> showfiles.php?group_id=39625&package_id=31936 which listed formmail
> 3.12c1 as the newest version.

You are correct. Several of those scripts appear to be outdated
versions. For the time being, use the link I provided in my previous
reply. I am copying the developer list in this reply, in case they are
unaware of this issue.

-Todd


> The FormMail.pl script it gets lists the version as 3.12c1.  The
> FormMail.pl script I've been using (renamed to "formmail.pl") lists
> it's version as 3.14c1.
>
> On Jul 30, 2006, at 11:47 AM, Todd Alan Smith wrote:
>
> > On 7/30/06, Robert Peters <bo...@bo...> wrote:
> >> Below is the result of your feedback form.  It was submitted by
> >> Robert Peters (bo...@bo...) on Sunday, July 30, 2006 at
> >> 16:42:00
> >> ---------------------------------------------------------------------
> >> ------
> >>
> >>
> >> description: I'm using nms FormMail on two websites that I have on
> >> a VPS
> >> hosting account.
> >>
> >> Just now, when checking to see if there is a newer version
> >> available than I'm
> >> using, I noted that the newest version available is 3.12 where
> >> I've been using 3.14.
> >
> > Where did you see that? The official download page for the nms project
> > has 3.14c1 and 3.14m1:
> >
> > http://nms-cgi.sourceforge.net/scripts.shtml
> >
> > -Todd
> >
> >> Have the two newest versions been recalled for some reason?
> >>
> >> enable: on
> >>
> >> ---------------------------------------------------------------------
> >> ------
> >>
> >>
> >> ---------------------------------------------------------------------
> >> ----
> >> Take Surveys. Earn Cash. Influence the Future of IT
> >> Join SourceForge.net's Techsay panel and you'll get the chance to
> >> share your
> >> opinions on IT & business topics through brief surveys -- and earn
> >> cash
> >> http://www.techsay.com/default.php?
> >> page=join.php&p=sourceforge&CID=DEVDEV
> >> _______________________________________________
> >> To unsubscribe from this mailing list visit
> >> https://lists.sourceforge.net/lists/listinfo/nms-cgi-support
> >> and follow the simple instructions.
> >>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> To unsubscribe from this mailing list visit
> https://lists.sourceforge.net/lists/listinfo/nms-cgi-support
> and follow the simple instructions.
>

[Nms-cgi-devel] [ nms-cgi-Support Requests-1505544 ] mail not received from Form Mail NMS

[SourceForge.net <no...@so...>]

Support Requests item #1505544, was opened at 2006-06-13 11:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425770&aid=1505544&group_id=39625

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: LHinson (lhinson)
Assigned to: Nobody/Anonymous (nobody)
Summary: mail not received from Form Mail NMS

Initial Comment:
No errors are received but the email does not arrive
after using the Contact Form.
http://www.littleworksusa.com/contact.html

I installed the Current Form Mail NMS from this site.
Thanks.
LHinson

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425770&aid=1505544&group_id=39625

[Nms-cgi-devel] [ nms-cgi-Support Requests-1500273 ] DNSBL instructions not really instructions...

[SourceForge.net <no...@so...>]

Support Requests item #1500273, was opened at 2006-06-04 01:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425770&aid=1500273&group_id=39625

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Install Problem (example)
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony M. Brown (mrbrown1602)
Assigned to: Nobody/Anonymous (nobody)
Summary: DNSBL instructions not really instructions...

Initial Comment:
I have a website which uses the NMS guestbook, and I get bombarded 
with spam on a daily basis. While reading over the readme to learn how to 
setup the IP blocking feature, I read about DNSBL, and figured I would try 
to set that up, so I opened the README.dnsbl file. These "instructions" are 
not really instructions at all, and are more like a background history of 
DNSBL, which has provided me with great frustration.

I'm trying to setup DNSBL on my NMS guestbook with literally no 
instruction. For @use_rbls, I have put qw(../DNSBL), which linked to a list, 
I have tried qw(sbl-xbl.spamhaus.org) to the same result.

How can I get this setup on my guestbook (keep in mind, I have 
absolutely no knowledge of Perl) so the massive spamming I receive on a 
daily basis will cease?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425770&aid=1500273&group_id=39625

Re: [Nms-cgi-devel] Mail text formatting + element name questions

[Jonathan S. <jn...@ge...>]

I've sent this to the Support list where it is more appropriate.

On Tue, 2006-05-30 at 07:41, Dan Vendel wrote:
> Hi,
> 
> I'm making a form that has lots of input fields. The resulting feedback mail
> is presently quite hard to read. The client have therefore asked me about
> this:
> 
> 1. Are there any ways to format the feedback mail in e.g. html or rtf with
> tables or tabs so that it shows columns?
> 
> 2. Can I make some text e.g. bold and/or italic using formatting of some
> sort?
> 
> 3. The input elements are names e.g. "company_name" right now. Can I use
> spaces and make it "Company name:"?
> 
> Your help is very much appreciated.
> 
> Cheers,
> Dan
> 
> 
> 
> 
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Nms-cgi-devel mailing list
> Nms...@li...
> https://lists.sourceforge.net/lists/listinfo/nms-cgi-devel
-- 

This e-mail is sponsored by http://www.integration-house.com/

[Nms-cgi-devel] Mail text formatting + element name questions

[Dan V. <hi...@da...>]

Hi,

I'm making a form that has lots of input fields. The resulting feedback mail
is presently quite hard to read. The client have therefore asked me about
this:

1. Are there any ways to format the feedback mail in e.g. html or rtf with
tables or tabs so that it shows columns?

2. Can I make some text e.g. bold and/or italic using formatting of some
sort?

3. The input elements are names e.g. "company_name" right now. Can I use
spaces and make it "Company name:"?

Your help is very much appreciated.

Cheers,
Dan

[Nms-cgi-devel] Re: [Nms-cgi-support] CSV Data format

[Jonathan S. <jn...@ge...>]

On Mon, 2006-05-22 at 23:24, Baz Smith wrote:
> Hello,
> can I just say what an excellent script this is and it works
> perfectly.
> My question is as follows:
> Is there any way to receive the data sent in the email as a CSV format
> which can then be used to import directly into a database?,
> or do you have a script that will automatically update a database that
> is held on a server?

I'm assuming you are talking about FormMail as you don't say.

NMS FormMail is not designed to send either attachments or have the body
of the email sent customized.

Our TFmail does go some of the way to fulfilling the requirement
inasmuch as it enables you to totally customize the message body to any
format that you require and also save the entries as a logfile which
could for instance be in a CVS format suitable for importing into a
database or spreadsheet.  The bit that it currently doesn't do is allow
you to send the custom formatted content as an attachment, but I think
that is something we would like to be able to do going forward so I have
added it to the TODO list (copied the developers list).

/J\
-- 

This e-mail is sponsored by http://www.integration-house.com/

[Nms-cgi-devel] Re: [Nms-cgi-support] Info request

[Jonathan S. <jn...@ge...>]

On Sun, 2006-05-14 at 22:38, Carlos wrote:
> Hello just to ask you if you have any survey or poll programs for realease soon

No, as it currently stands we don't have any survey or poll programs,
although it is something we probably would like to provide going
forward.  I've copied in the developers list in case any one has some
suitable code that they would like to contribute.

/J\
-- 

This e-mail is sponsored by http://www.integration-house.com/

[Nms-cgi-devel] [Fwd: SUBJECT: SourceForge.net: CVS service offering changes]

[Jonathan S. <jn...@ge...>]

In case anyone was wondering why the CVS wasn't working.

/J\
-----Forwarded Message-----
> From: SourceForge.net Team <no...@so...>
> To: jn...@ge...
> Subject: SUBJECT: SourceForge.net: CVS service offering changes
> Date: Thu, 11 May 2006 16:42:19 -0700
> 
> Greetings,
> 
> You are receiving this mail because you are a project admin for
> a SourceForge.net-hosted project. One of our primary services,
> CVS, suffered a series of interrelated, critical hardware failures
> in recent weeks. We understand how frustrating this CVS outage
> must be to you and your users; however, our top priority remains
> preservation of the integrity of your data.
> 
> The series of CVS hardware failures prompted us to expedite the
> deployment of planed improvements to our CVS infrastructure,
> drawing upon much of the knowledge that we gained from our
> Subversion deployment. Our improved CVS service architecture,
> which we plan to deploy tomorrow afternoon (2006-05-12), will
> offer greater performance and stability and will eliminate several
> single points of failure.
> 
> The Site Status page (https://www.sf.net/docs/A04) will be
> updated as soon as the new infrastructure is rolled out. In the
> interim, please read the important information provided below
> to learn about how these changes will affect your project.
> 
> 
> Summary of changes, effective 2006-05-12:
> 
> 
> 1. Hostname for CVS service
> 
> Old: cvs.sourceforge.net
> 
> New: PROJECT_UNIX_NAME.cvs.sourceforge.net
> 
> This change will require new working copies to be checked out of all
> repositories (so control files in the working copy will point to the
> right place). We will be updating the instructions we supply, but
> instructions that your team has written within documentation, etc. will
> need to be updated.
> 
> cvs -d:pserver:ano...@cv...:/cvsroot/gaim co gaim
> 
> would be changed to
> 
> cvs -d:pserver:ano...@ga...:/cvsroot/gaim co gaim
> 
> 
> 
> 2. ViewCVS
> 
> We are moving from ViewCVS to its successor, ViewVC. ViewVC is
> currently in use for our Subversion service.
> 
> 
> 
> 3. Sync delay
> 
> Old: CVS pserver, tarballs and ViewCVS provided against a separate
> server which is a minimum of three hours behind developer CVS.
> 
> New: ViewVC will be provided against developer CVS (it will be current).
> CVS pserver will be provided against a secondary server (not developer
> server) with a maximum expected delay of two hours.
> 
> Follow-up work is planned (this infrastructure takes us 80% of the way)
> to essentially eliminate the sync delay.
> 
> 
> 
> 4. Read-only rsync service
> 
> As a new service offering, we are now providing read-only rsync access
> against developer CVS. This allows projects to efficiently make
> on-demand backups of their entire CVS repository.
> 
> All projects should be making regular backups of their CVS repository
> contents using this service.
> 
> 
> 
> 5. Nightly tarball service
> 
> Nightly tarball service is being dropped in lieu of read-only rsync
> service. Projects which currently depend on nightly tarballs for
> repository backups will need to begin using rsync to make a backup copy
> of their repository contents.
> 
> We see this as a major functional improvement. For a number of reasons,
> tarballs have fallen out of sync with the data in the repository at
> times in the past few years. Tarballs required a substantial amount of
> additional disk, and I/O to generate. The move to read-only rsync
> allows backups to be produced on-demand, with an update frequency chosen
> by the project.
> 
> 
> 
> 6. Points of failure
> 
> In the past, developer CVS service for all projects was provided from a
> single host. CVS pserver service was provided from individual backend
> heads based on a split of the data.
> 
> Under our new design, developer CVS and most of our CVS-related services
> are provided from one of ten CVS hosts (count subject to increase with
> growth). Each host is independent, and makes a backup copy of the
> repository data of another host (which is used to provide the pserver
> CVS service).
> 
> Failure of a single host will impact only the availability of data on
> that host. Since the data is split among a larger number of hosts, the
> size of data impacted by an individual host outage is substantially
> smaller, and the time required for us to restore service will be
> substantially shorter.
> 
> This rapid architecture change has been made possible specifically using
> the research we performed for our recent launch of Subversion service.
> We've applied our best practices, produced a substantial amount of
> internal documentation, and kept an eye toward maintainability.
> This effort has allowed us to deploy this new architecture quickly
> once hardware was received, and will permit us to quickly scale
> this service horizontally as growth and demand requires. 
> 
> 
> 
> Many other minor improvements have also been made to improve the service
> offering and make it less trouble-prone. The most important of which are
> listed above. For a full description of the new service offering, and
> for information on how to use the services described above, please refer
> to the site documentation for the CVS service after the service has been
> launched: https://www.sf.net/docs/E04
> 
> 
> Thank you,
> 
> The SourceForge.net Team 
> 
> .
-- 

This e-mail is sponsored by http://www.integration-house.com/

[Nms-cgi-devel] Re: [Nms-cgi-support] TFMail: How to convert Linefeeds into <br />?

[Jonathan S. <jn...@ge...>]

On Thu, 2006-05-11 at 19:13, Claus Berghammer wrote:
> Hello NMS Supporters,
> 
> I still have the problem with the missing feature to convert linefeeds (or
> linebreaks?) into <br />. Does anyone know a quick n' dirty "hack" for the
> TFMail script, that can do that?
> 
> As I said earlier, I don't have a problem with the width of the text input,
> but with the missing <br />...
> 
> I found this codeline on the net:
> 
> ~~~~~~~~~~~~
> $input =~ s/\n/<BR>/g);
> ~~~~~~~~~~~~
> 
> This command should convert the linefeeds, but I dont know where it should
> be placed in the tfmail script. Beside that, this script makes <BR> (I
> think), but I need <br /> instead.
> 
> Does anyone know the correct codeline, and where to place it in the tfmail
> script?

There isn't a "correct codeline" that can be simply added to the program
to adjust the input in this way, the input values for the templates for
both the email and the html output are shared and consequently anything
that is done to one will be done for the other.  If one wanted to simply
do it for only the HTML output then you would have to adjust the values
stored in the template directives individually - this obviously will not
be a simple line of code and probably be as much code as doing it
properly.

As I said before the proper way to do this would be to allow access to
the 'lines' or 'paragraphs' in the inputs through the templating
mechanism, but this requires a developer having the time and inclination
to actually implement it: it is on the TODO list. I've copied in the
developers list to see if anyone feels able to pick it up.

/J\
-- 

This e-mail is sponsored by http://www.integration-house.com/

[Nms-cgi-devel] Re: NMS and Google SoC

[Nicholas C. <ni...@cc...>]

On Fri, Apr 21, 2006 at 10:09:43PM +0100, Jonathan Stowe wrote:
> On Fri, 2006-04-21 at 21:30, Nicholas Clark wrote:
> > On Fri, Apr 21, 2006 at 05:03:35PM +0100, Jonathan Stowe wrote:
> > 
> > [Much]
> > 
> > It seemed rather more text than the other project ideas have on
> > http://www.perl.org/advocacy/summerofcode/ideas.html
> > 
> > Would you be able to put this full description as a page on
> > nms-cgi.sourceforge.net, which the ideas page can link to?
> > 
> 
> Done. At http://nms-cgi.sourceforge.net/phase2.html as below.

> Yep, all good stuff.

Done. http://www.perl.org/advocacy/summerofcode/ideas.html

Nicholas Clark

[Nms-cgi-devel] Re: NMS and Google SoC

[Jonathan S. <jn...@ge...>]

On Fri, 2006-04-21 at 21:30, Nicholas Clark wrote:
> On Fri, Apr 21, 2006 at 05:03:35PM +0100, Jonathan Stowe wrote:
> 
> [Much]
> 
> It seemed rather more text than the other project ideas have on
> http://www.perl.org/advocacy/summerofcode/ideas.html
> 
> Would you be able to put this full description as a page on
> nms-cgi.sourceforge.net, which the ideas page can link to?
> 

Done. At http://nms-cgi.sourceforge.net/phase2.html as below.

Dave, I've checked the file into CVS in pub/in/phase2.html if you want
to make it better fit the house style or do any changes.

> If so, is this an acceptable summary for the ideas page?
> 
>     Create a "Web Application Toolkit" for the NMS project.
> 
>     NMS has been very successful at providing well-written re-implementations of
>     certain popular but insecure CGI scripts, but the requirement to be
>     "drop-in" replacements has constrained what could be done. The next phase
>     is to provide entirely new programs based around a "Web Application
>     Toolkit", wide variety of functionality without any programming knowledge
>     on the part of the person configuring it, and it should be simply
>     installed on the majority of shared web hosting that supports Perl CGI
>     programs.  The work has been started - 'TFmail' is the recommended
>     replacement for the 'FormMail' program.
> 
>     The project would be to write this toolkit and scripts that use it. The
>     toolkit should incorporate all TFmail's functionality, but also support
>     configurations as Guestbook, Web Discussion Board, Content Search, Link
>     Exchange, or any combination. It's likely to need code to deal with
> 
>            * Authentication
>            * Rate limiting of requests
>            * Session management
>            * Secure file handling
>            * Generalized and flexible error reporting
>            * Message threading
>            * Improved templating engine
> 
>     see http://nms-cgi.sourceforge.net/phase2.html for more information.
> 
> (is that a good URL) ?
> 

Yep, all good stuff.

> Nicholas Clark
-- 

This e-mail is sponsored by http://www.integration-house.com/

[Nms-cgi-devel] Re: NMS and Google SoC

[Nicholas C. <ni...@cc...>]

On Fri, Apr 21, 2006 at 05:03:35PM +0100, Jonathan Stowe wrote:

[Much]

It seemed rather more text than the other project ideas have on
http://www.perl.org/advocacy/summerofcode/ideas.html

Would you be able to put this full description as a page on
nms-cgi.sourceforge.net, which the ideas page can link to?

If so, is this an acceptable summary for the ideas page?

    Create a "Web Application Toolkit" for the NMS project.

    NMS has been very successful at providing well-written re-implementations of
    certain popular but insecure CGI scripts, but the requirement to be
    "drop-in" replacements has constrained what could be done. The next phase
    is to provide entirely new programs based around a "Web Application
    Toolkit", wide variety of functionality without any programming knowledge
    on the part of the person configuring it, and it should be simply
    installed on the majority of shared web hosting that supports Perl CGI
    programs.  The work has been started - 'TFmail' is the recommended
    replacement for the 'FormMail' program.

    The project would be to write this toolkit and scripts that use it. The
    toolkit should incorporate all TFmail's functionality, but also support
    configurations as Guestbook, Web Discussion Board, Content Search, Link
    Exchange, or any combination. It's likely to need code to deal with

           * Authentication
           * Rate limiting of requests
           * Session management
           * Secure file handling
           * Generalized and flexible error reporting
           * Message threading
           * Improved templating engine

    see http://nms-cgi.sourceforge.net/phase2.html for more information.

(is that a good URL) ?

Nicholas Clark

[Nms-cgi-devel] Re: NMS and Google SoC

[Jonathan S. <jn...@ge...>]

On Wed, 2006-04-19 at 09:24, Nicholas Clark wrote:
> On Wed, Apr 19, 2006 at 08:57:09AM +0100, Jonathan Stowe wrote:

<on getting a summer of code student to do something for NMS>

> > I could certainly write a specification for it.
> 
> If you could, that would be cool.

As promised. It's fairly high level but enough to get someone started. 
I have copied in the developers list in case a) there are any students
lurking on this list who might want to apply for a summer of code gig b)
we don't get the 'minion' and someone fancies doing some work on it c)
someone wants to add something.

<begin>

BACKGROUND 
==========

The NMS project was started in 2000 with the aim of providing high
quality
and secure replacements for popular Perl programs used on the web and
to provide the best support possible for those replacement programs.

More information on the project in general can be found at:

    http://nms-cgi.sf.net/

The initial development work on the replacement programs is now largely
completed and the programs are considered to be in 'maintenance mode'.

PHASE 2 OF THE PROJECT 
======================

The programs released by the NMS project have been required to be
largely
compatible with the programs that they are replacing in the sense that
for the most part they can be offered as drop in replacements and that
the
configuration should be familiar to someone who knows the older
programs;
however this imposes a limitation on the ability to provide for many
feature requests or to implement more sophisticated security features.

With this in mind the 'phase two' of the NMS project is to provide
entirely new programs without any of the legacy constraints and which
can provide a far greater degree of functionality simply through their
configuration rather than by customization. To date the only output from
this effort has been the program 'TFmail' which is the recommended 
replacement for the 'FormMail' program (and to some extent also the
guestbook program.) 

Going forward the plan is to create a "Web Application Toolkit" that
draws on the work already begun with TFmail. This should provide a
wide variety of functionality without any programming knowledge on the
part of the person configuring it, and it should be simply installed 
on the majority of shared web hosting that supports Perl CGI programs
(the current NMS constraints are discussed at

     http://nms-cgi.sourceforge.net/about.html
)

The functionality provided should incorporate everything already
available in the TFmail program but will also have features to 
support configuration (at minimum) as:

          * Guestbook 
          * Web Discussion Board
          * Content Search 
          * Link Exchange 

or any combination of the features of those. Extended features that
will be common to all of these that may be needed include:

          * Authentication
          * Rate limiting of requests
          * Session management
          * Secure file handling
          * Generalized and flexible error reporting
          * Message threading
          * Improved templating engine

The intent being to support as wide as possible range of relatively
simple web applications through a single set of program and library
files simply through individual configuration and template files.

The resulting package should have user level documentation that will
enable someone with little more experience than creating HTML pages
to be able to configure the applications as quickly as possible
including examples of configuration for the most common uses.




-- 

This e-mail is sponsored by http://www.integration-house.com/

[Nms-cgi-devel] e-mail id

[Punarjani P. <pun...@ya...>]

pun...@ya...                                       

 www.punarjani.org   E-mail: pun...@ya...    
__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Nms-cgi-devel] [ nms-cgi-Bugs-1468670 ] CookieLib - Cannot use .tv domain

[Jonathan S. <jn...@ge...>]

On Tue, 2006-04-11 at 17:21, SourceForge.net wrote:
> Bugs item #1468670, was opened at 2006-04-11 16:21

> The SetCookieDomain routine contains the following list
> of acceptable domain extensions:
>=20
> .com|.edu|.net|.org|.gov|.mil|.int
>=20
> However, here is a list of currently approved extensions:
>=20
> http://www.norid.no/domenenavnbaser/domreg.html
>=20
> I understand that the original MSA cookielib library,
> upon which this one is based, was written back when
> there were only a handful of approved extensions. It
> nevertheless poses a current problem.=20
>=20
> This limitation is not mentioned in the README.  If it
> were, I would have placed this in Feature Requests.=20
>=20

Actually the problem isn't so much with the list of top level domains in
the first regular expression (although this is obviously totally
obsolete itself as there are now more gTLDS and not all of them are
three characters - such as .info and .name) but with the na=C3=AFve
assumption in the second clause that the country specific domains are
all subdivided in a similar manner as the .uk domain (e.g. .co.uk,
.ac.uk and so forth) so the regular expression requires something of the
form of .foo.co.uk with three dots in it, this is far from being a
universal convention among country registries as you have noted with the
.tv domain (but just from ones I have seen today also .eu, .ch and so
forth).

To be honest I'm inclined to make the test for a valid domain far less
specific and test for a dot followed by at least two alphanumerics, dash
or dot a dot and then at least two alphabetic characters, something
like:

     /\.[\w\.-]{2,}\.[a-z]{2,}$/i

though I'm sure someone could come up with something better.

/J\
--=20

This e-mail is sponsored by http://www.integration-house.com/

[Nms-cgi-devel] [ nms-cgi-Bugs-1468670 ] CookieLib - Cannot use .tv domain

[SourceForge.net <no...@so...>]

Bugs item #1468670, was opened at 2006-04-11 16:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425769&aid=1468670&group_id=39625

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joel Limardo (joellimardo)
Assigned to: Nobody/Anonymous (nobody)
Summary: CookieLib - Cannot use .tv domain

Initial Comment:
The SetCookieDomain routine contains the following list
of acceptable domain extensions:

.com|.edu|.net|.org|.gov|.mil|.int

However, here is a list of currently approved extensions:

http://www.norid.no/domenenavnbaser/domreg.html

I understand that the original MSA cookielib library,
upon which this one is based, was written back when
there were only a handful of approved extensions. It
nevertheless poses a current problem. 

This limitation is not mentioned in the README.  If it
were, I would have placed this in Feature Requests. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425769&aid=1468670&group_id=39625

[Nms-cgi-devel] Re: [Nms-cgi-support] cookielib

[Jonathan S. <jn...@ge...>]

On Mon, 2006-04-10 at 17:24, Joel Limardo wrote:
> You don't mind if I use the contents of this e-mail as a PerlMonks
> (http://www.perlmonks.org) post/discussion, do you? I will not mention
> you by name.
> 

Yes _we_ would mind, if there is to be discussion of the NMS project we
would like it to be here so it is archived. Also your posting

  http://www.perlmonks.org/?node_id=541980

before asking here is impolite at best and your tone in your
communications here has been somewhat combative.

I am however going to followup to that post just to clarify matters.

This is an open source project and we are happy for contributions,
however it seems that people on the whole would rather gripe in the
background rather than actually help.

If you want to contribute please see

    http://nms-cgi.sourceforge.net/devel.html

We periodically make appeals for volunteers in a wide variety of places
but it seems that no-one actual wants to get involved.

> Sincerely,
> 
> 
> Joel Limardo
> 
> > On Mon, 2006-04-10 at 01:03, Joel Limardo wrote:
> > > Here's the problem.  You should use CGI::Cookie, I agree, but newbies
> > > have no friggin' idea how to use modules.  People read the mission of
> > > NMS and the statement about "experts" and they will assume that
> > > everything has been properly tested (I did) and works.
> > > 
> > > Here are other things that do not make sense in this library:
> > > 
> > > 1) Why in the heck does CookieLib insist on copying stuff into main?
> > > 
> > > $main::Cookies{$name} = $value;
> > > 
> > > As a developer, I typically don't want libraries exporting stuff into my
> > > main namespace. I presume this is the entire reasoning behind using
> > > EXPORT_OK versus the standard EXPORT in modules.  Why don't you just
> > > specify a package and keep those values in that, like:
> > > 
> > > $johnson::Cookies{'name'} = "whatever in the heck you want";
> > > 
> > 
> > The MSA version did exactly the same, we have no way of knowing how
> > people were using it. The rest of the regex handles the others.
> > 
> > > 
> > > 2) Why are these domain extensions hard coded?
> > > 
> > > (.com|.edu|.net|.org|.gov|.mil|.int)
> > > 
> > > There are dozens of extensions that are very popular in the US and
> > > elsewhere. For instance, .tv.  Why hard-code this at all?  Rather, just
> > > make it user-configurable?  Also, the README file does not mention that
> > > this module has a hard-coded limitation. There's probably some unwitting
> > > guy in Taiwan (.tw I think) trying to use this library who is cursing
> > > right now.
> > > 
> > 
> > No, at the time of writing these were the only three letter TLDs and
> > this is what the MSA version did.
> > 
> > 
> > > 3) This statement,
> > > 
> > > if ($_[0] =~ /(.com|.edu|.net|.org|.gov|.mil|.int)$/i &&
> > >         $_[0] =~ /\.[^.]+\.\w{3}$/) {
> > >         $cookie_config{domain} = $_[0];
> > >         return 1;
> > >     }
> > >     elsif ($_[0] !~ /(.com|.edu|.net|.org|.gov|.mil|.int)$/i &&
> > >            $_[0] =~ /\.[^.]+\.[^.]+\./) {
> > >         $cookie_config{domain} = $_[0];
> > >         return 1;
> > >     }
> > >     else
> > >     {
> > >         return 0;
> > >     }
> > > 
> > > 
> > > Could be easily rewritten to eliminate one of the elseifs in the
> > > following fashion:
> > > 
> > > sub SetCookieDomain
> > > {
> > > 
> > >     if ($_[0] =~ /(.com|.edu|.net|.org|.gov|.mil|.int)$/i &&
> > >        ($_[0] =~ /\.[^.]+\.\w{3}$/) || ($_[0] =~ /\.[^.]+\.[^.]+\./)  ) 
> > >     {
> > >         $cookie_config{domain} = $_[0];
> > >         return 1;
> > >     }
> > >     #elsif ($_[0] !~ /(.com|.edu|.net|.org|.gov|.mil|.int)$/i &&
> > >     #       $_[0] =~ /\.[^.]+\.[^.]+\./) {
> > >     #    $cookie_config{domain} = $_[0];
> > >     #    return 1;
> > >     #}
> > >     else
> > >     {
> > >         return 0;
> > >     }
> > > }
> > > 
> > > In fact, I am pretty certain that the entire regex could be rewritten as
> > > a single regex instead of three.  Something like: perl -e "$rr =
> > > q{ip.world.rocks.com}; if($rr=~m/(\.[^\.]+)+\.com/i){print 'yeah' .
> $1};"
> > > 
> > > 3) Why isn't this print statement optional:
> > > 
> > > print "Set-Cookie: ", $c, "\n";
> > > 
> > > Print statements like this in subroutines are highly undesireable. It
> > > would be better to, for backward compatibility, allow this but in
> > > reality to just return the cookie information from the routine in a
> scalar.
> > > 
> > 
> > There is no point, if it wants to behave different the people should use
> > CGI::Cookie.
> > 
> > > 4) I don't see any MD5 hashes or anything else to ensure that these
> > > libraries were not tampered with. Since the objective of the site is to
> > > make more secure scripts, I would think that, somehow, there would be a
> > > way to fingerprint them.
> > 
> > 
> > > That's pretty much all I can think of right now. As I continue to work
> > > with these libraries, I may have more.
> > > 
> > 
> > 
> > Proper patches using diff -uBb if you have any more,  I am more inclined
> > to delete the thing personally.
> > 
> > 
> > > > On Fri, 2006-04-07 at 15:13, Joel Limardo wrote:
> > > > > What in the hell is wrong with this picture? 
> > > > >  
> > > > > Your code has the following line: 
> > > > >  
> > > > >  -expires => ((exists($cookie_config{expires}) &&
> > > > > $cookie_config{expires} ==1) ? $cookie_config{expires} : undef), 
> > > > >  
> > > > > which feeds the expires key of a hash that creates a new CGI::Cookie
> > > > > object.  That object takes non-numeric values (as shown in the POD)
> > > > > like '3M' for one thing. On the other hand, if I use a value other
> > > > > than '1', IT DOESN'T WORK.  The above code clearly tests to see if
> > > > > $cookie_config{expires} EXISTS AND if ITS VALUE IS SET TO 1.  
> > > > >  
> > > > > See for yourself: 
> > > > >  
> > > > > !/usr/bin/perl -w 
> > > > > use strict; 
> > > > >  
> > > > > my %cookie_config; 
> > > > >  
> > > > > $cookie_config{expires} = 99999; 
> > > > >  
> > > > > my $ret = ((exists($cookie_config{expires}) &&
> > > $cookie_config{expires} ==1) ? $cookie_config{expires} : undef); 
> > > > >  
> > > > >     print $ret unless (!$ret); 
> > > > >  
> > > > > 1; 
> > > > >  
> > > > > You won't see anything. Maybe I am nuts or I am just missing
> something.
> > > > > 
> > > > 
> > > > No you're not missing anything, it is definitely incorrect, which is
> > > > strange because it has always been like that for four years or so.
> > > > Taking the '== 1' out would fix it.
> > > > 
> > > > To be honest we would recommend anyone who wanted to use cookies
> to use
> > > > the CGI::Cookie anyway.
> > > > 
> > > > However it needs to be fixed and I'll see to it when I get a minute.
> > > > 
> > > > /J\
> > > > -- 
> > > > 
> > > > This e-mail is sponsored by http://www.integration-house.com/
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > Sincerely,
> > > 
> > > 
> > > Joel Limardo
> > > joe...@fo...
> > > www.forwardphase.com
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> > > that extends applications into web and mobile media. Attend the live
> webcast
> > > and join the prime developer group breaking into this new coding
> territory!
> > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> > > _______________________________________________
> > > To unsubscribe from this mailing list visit
> > > https://lists.sourceforge.net/lists/listinfo/nms-cgi-support
> > > and follow the simple instructions.
> > -- 
> > 
> > This e-mail is sponsored by http://www.integration-house.com/
> > 
> > 
> > 
> 
> 
> Sincerely,
> 
> 
> Joel Limardo
> joe...@fo...
> www.forwardphase.com
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> To unsubscribe from this mailing list visit
> https://lists.sourceforge.net/lists/listinfo/nms-cgi-support
> and follow the simple instructions.
-- 

This e-mail is sponsored by http://www.integration-house.com/

[Nms-cgi-devel] RE: [Nms-cgi-support] TFMail: Wrong Filetypes (extensions) are notrejected by the script

[Jonathan S. <jn...@ge...>]

On Thu, 2006-03-30 at 11:31, Cole Bantam wrote:
>  Hello Mr. Stowe,
>=20
> Thank you for your help. The changings to the script does indeed block
> unwanted extensions. But the result is, that a simple "Application Erro=
r"
> occurs. This mesage will not make it clear to the user, that a wrong fi=
le
> type is responsible that for. To create a clear errorpage, I could exte=
nd
> the debug info. But the developers say that debug is only f=C3=BCr test=
ing, not
> for real life scenario. So is there a better way to do that? If it is t=
o
> much work to do it "quick n' dirty", is this feature planed to debut in
> future versions of TFMail?
>=20

Yes correct that is all that it was intended to do.  The feature to use
a template for the error message is on the TODO.

> To be honest, I do not understand what was the developers intention on =
the
> current "file type limitation" system. OK, executable files are renamed=
 (if
> not listed), which is good. For your example with the image it is well =
done.
> But what if the upload is for "all" files exept executables? Then you h=
ave
> to put hundreds of file extension to the list, just to block a couple...
>=20
> Wishlist for future Versons of Tfmail:
>=20
> - Possibility to configure if the File Extension list is a white or
> blacklist
> - Possibility to configure if wrong file types are rejected (with prope=
r
> errorpage) or renamed

Code contributions are gratefully accepted.

/J\
--=20

This e-mail is sponsored by http://www.integration-house.com/

[Nms-cgi-devel] RE: [Nms-cgi-support] TFMail: Wrong Filetypes (extensions) are notrejected by the script

[Cole B. <col...@gm...>]

=20
Hello Mr. Stowe,

Thank you for your help. The changings to the script does indeed block
unwanted extensions. But the result is, that a simple "Application =
Error"
occurs. This mesage will not make it clear to the user, that a wrong =
file
type is responsible that for. To create a clear errorpage, I could =
extend
the debug info. But the developers say that debug is only f=FCr testing, =
not
for real life scenario. So is there a better way to do that? If it is to
much work to do it "quick n' dirty", is this feature planed to debut in
future versions of TFMail?

To be honest, I do not understand what was the developers intention on =
the
current "file type limitation" system. OK, executable files are renamed =
(if
not listed), which is good. For your example with the image it is well =
done.
But what if the upload is for "all" files exept executables? Then you =
have
to put hundreds of file extension to the list, just to block a couple...

Wishlist for future Versons of Tfmail:

- Possibility to configure if the File Extension list is a white or
blacklist
- Possibility to configure if wrong file types are rejected (with proper
errorpage) or renamed

Best Wishes, Claus Berghammer



-----Original Message-----
From: Jonathan Stowe
Sent: Tuesday, March 28, 2006 8:58 PM
To: colebantam
Cc: NMS-CGI-Support; NMS Devel
Subject: Re: [Nms-cgi-support] TFMail: Wrong Filetypes (extensions) are
notrejected by the script

On Tue, 2006-03-28 at 17:16, Cole Bantam wrote:
> Hello there,
>=20
> When I read the readme to TFMail, I was pleased, to see the=20
> possibility not only to upload files to the E-Mail, but to limit the=20
> range of file types by its extension. But in fact file types other=20
> than "allowed" in the configfile, are NOT rejected, but only renamed=20
> to the last extension that is listed.
>=20
> Expected behaviour:
> If someone tries to upload a file with an extension that is not listed =

> in the configfile, he informed that he was to upload a file type that=20
> is not supported.
>=20
> Existing behaviour:
> If someone uploads a file with an extension, which is not listed in=20
> the configfile, the attachment is sent with no further comment, but=20
> the file
> (extension) is renamed (and so "defect" for many users).
>=20
> Does anyone knows how to get the "Expected behaviour"?
>=20

You might expect that behaviour but the existing behaviour is the =
advertised
and designed behaviour.  The problem is that the 'extension'
of the file is not a guarantee of the file type: I could quite easily =
rename
some random file with a .doc suffix and upload it and the program would =
be
none the wiser.

Of course it might be nice to have something like this as an option, you =
can
change the TFmail.pl at line 649 where there is:

         if ( $filename =3D~ m#\.(\w{1,8})$# and exists $goodext{lc $1} =
)
         {
            $bestext =3D $goodext{lc $1};
         }
         elsif ( $ct =3D~ m#^[\w\-]+/(\w{1,8})$# and exists $goodext{lc =
$1} )
         {
            $bestext =3D $goodext{lc $1};
         }

To

         if ( $filename =3D~ m#\.(\w{1,8})$# and exists $goodext{lc $1} =
)
         {
            $bestext =3D $goodext{lc $1};
         }
         elsif ( $ct =3D~ m#^[\w\-]+/(\w{1,8})$# and exists $goodext{lc =
$1} )
         {
            $bestext =3D $goodext{lc $1};
         }
	 elsif ( $treq->config('strict_extension','0') )
         {
	    die "Bad file type";
         }

and then add

   strict_extension: 1

to your .trc file which will do what you want.  I'm not sure if this is
exactly what we would put in a released version, so I am copying the
developers list to see if anyone has a better idea.

/J\
--=20

This e-mail is sponsored by http://www.integration-house.com/