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

[Nms-cgi-devel] Re: [Nms-cgi-support] TFMail: File Upload results in wrong errorpage if filesize extends value of "CGIPostMax"

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

On Tue, 2006-03-28 at 17:16, Cole Bantam wrote:
> Hello there,
> 
> If I upload files with tfmail, and the filesize extends the value given in
> "CGIPostMax", the "missing fields" Errorpage is presented, instead of an
> "Filesize exceeds maximum quota" (or something comparable).
> 

This is actually the correct behaviour as it stands.  The CGI perl
module, as soon as the POST data exceeds $CGI::POST_MAX (and bear in
mind this includes the form fields as well as uploaded files), will stop
reading the body data from the http request immediately and doesn't
return any parameters, so "missing fields" is exactly what the program
sees as none of the 'fields' from the form are present.

> Does anyone know how to get a correct "Errorpage", that forces the user to
> attach a file that is within the limitation.

Currently TFmail doesn't check that this has happened. It can be made to
throw an error by adding:

   if ( $treq->cgi()->cgi_error() =~ /413 POST/i )
   {
      die "Document too large";
   }
at around line 110 of the TFmail.pl

but that is unlikely something we will want to put in a release version
and someone will take a look at implementing it with a proper message
page.

/J\
-- 

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

[Nms-cgi-devel] Re: [Nms-cgi-support] TFMail: Wrong Filetypes (extensions) are not rejected by the script

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

On Tue, 2006-03-28 at 17:16, Cole Bantam wrote:
> Hello there,
> 
> When I read the readme to TFMail, I was pleased, to see the possibility not
> only to upload files to the E-Mail, but to limit the range of file types by
> its extension. But in fact file types other than "allowed" in the
> configfile, are NOT rejected, but only renamed to the last extension that is
> listed.
> 
> 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 is not
> supported.
> 
> Existing behaviour:
> If someone uploads a file with an extension, which is not listed in the
> configfile, the attachment is sent with no further comment, but the file
> (extension) is renamed (and so "defect" for many users).
> 
> Does anyone knows how to get the "Expected behaviour"?
> 

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 =~ m#\.(\w{1,8})$# and exists $goodext{lc $1} )
         {
            $bestext = $goodext{lc $1};
         }
         elsif ( $ct =~ m#^[\w\-]+/(\w{1,8})$# and exists $goodext{lc $1} )
         {
            $bestext = $goodext{lc $1};
         }

To

         if ( $filename =~ m#\.(\w{1,8})$# and exists $goodext{lc $1} )
         {
            $bestext = $goodext{lc $1};
         }
         elsif ( $ct =~ m#^[\w\-]+/(\w{1,8})$# and exists $goodext{lc $1} )
         {
            $bestext = $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\
-- 

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

[Nms-cgi-devel] Re: [Nms-cgi-support] suggestion for feature to facilitate statistical analyses of form data received

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

On Wed, 2006-03-22 at 14:54, Jay Jones-Doyle wrote:
> perfect, default_<fieldname>: <value> is exactly what I meant.
>  
> for my part i added conditional javascript statements to my form
> validator that added the default values before submission, but the
> above solution would be preferable.
>  
> Do you need any help with the FAQ section?
> 

I think we'd prefer help with the actual coding, we have too few active
developers and not enough time.

>  
> On 3/22/06, Jonathan Stowe <jn...@ge...> wrote: 
>         On Mon, 2006-03-20 at 14:47, Jay Jones-Doyle wrote:
>         > Hey all.
>         >
>         > I recently configured a form using TFMail to return to me
>         the results 
>         > from an online survey for my bachelors thesis.  One
>         requiredment of
>         > such a survey is that, for the purposes of statistical
>         analyses, ALL
>         > fields must have a value: meaning that if a user did not
>         fill in / 
>         > answer a certain question, the program still requires there
>         to be a
>         > value (picture a spreadsheet-like program).
>         >
>         > anyways, i'm here because certain questions were
>         conditional, meaning
>         > " 2) If yes, blahblah, if no skip to question 5." 
>         >
>         > The problem was that questions 3 & 4 needed a value of '0'
>         just to
>         > show that the user provided no response.  This cannot be
>         done
>         > clientside because of security issues relating to "filling
>         out the 
>         > form for the user".
>         >
>         > i was to that serverside I would need something like (for a
>         radio
>         > button):
>         >
>         > my $toolsYesNo = $query->param('name taken from radio
>         button');
>         > if $toolsYesNo = ""; { 
>         > $toolsYesNo = 0;
>         > }
>         >
>         > I thought you might want to include such options in the
>         script, but
>         > broaden in to "What would you like submitted if a button /
>         text area
>         > is not filled in? 
>         >
>         > i see it as something like:
>         >
>         > user config area:
>         > -----------------------
>         > button / text area name: value / message
>         >
>         > script:
>         > --------
>         >
>         > my $toolsYesNo = $query->param('name taken from radio
>         button'); 
>         > if $toolsYesNo = ""; {
>         > $toolsYesNo = 0;
>         > }
>         >
>         > any thoughts?
>         
>         I think what you meant to suggest was 'the ability to provide
>         a default
>         value for input fields', your actual suggestion is to closely
>         tied to 
>         your own requirements and is not generally useful.
>         
>         I would see having something like:
>         
>         default_<fieldname>: <value>
>         
>         in the configuration and using the values from there if none
>         is supplied 
>         in the form values.
>         
>         We can add something like this to the TODO list, but it needs
>         some keen
>         develo0per to pick it up.
>         
>         /J\
>         --
>         
>         This e-mail is sponsored by http://www.integration-house.com/
-- 

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

[Nms-cgi-devel] [Fwd: Formmail attacks]

[Dave C. <da...@us...>]

Does anyone have any idea whether Richard's idea below would be feasible?

Dave...

-------- Original Message --------
Subject: Formmail attacks
Date: Tue, 21 Mar 2006 08:53:44 -0000 (GMT)
From: benjymous <ben...@gr...>
To: da...@us...

This is just a quick question.  I've been using the NMS version of
Formmail on my site for a few years now, and every so often I'll get a
barage of emails from a spammer trying to hijack formmail to send spam.
Thankfully they seem to give up after about half a dozen mails, but that
doesn't stop somebody else trying a few days later.

So is there any way that formmail could detect that fake mail headers have
been added into the message, and just silently reject those messages? (and
so save me the hassle of wading through and deleting the junk comments)

Thanks in advance,

Richard Munn


-- 
Help me!  I'm turning into a grapefruit!


-- 
nms project - http://nms-cgi.sourceforge.net/
Web Programs Written By Experts

[Nms-cgi-devel] Re: [Nms-cgi-support] suggestion for feature to facilitate statistical analyses of form data received

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

On Mon, 2006-03-20 at 14:47, Jay Jones-Doyle wrote:
> Hey all.
>  
> I recently configured a form using TFMail to return to me the results
> from an online survey for my bachelors thesis.  One requiredment of
> such a survey is that, for the purposes of statistical analyses, ALL
> fields must have a value: meaning that if a user did not fill in /
> answer a certain question, the program still requires there to be a
> value (picture a spreadsheet-like program).
>  
> anyways, i'm here because certain questions were conditional, meaning
> " 2) If yes, blahblah, if no skip to question 5."
>  
> The problem was that questions 3 & 4 needed a value of '0' just to
> show that the user provided no response.  This cannot be done
> clientside because of security issues relating to "filling out the
> form for the user".
>  
> i was to that serverside I would need something like (for a radio
> button):
>  
> my $toolsYesNo = $query->param('name taken from radio button');
> if $toolsYesNo = ""; { 
> $toolsYesNo = 0;
> }
>  
> I thought you might want to include such options in the script, but
> broaden in to "What would you like submitted if a button / text area
> is not filled in?
>  
> i see it as something like:
>  
> user config area:
> -----------------------
> button / text area name: value / message
>  
> script:
> --------
>  
> my $toolsYesNo = $query->param('name taken from radio button');
> if $toolsYesNo = ""; { 
> $toolsYesNo = 0;
> }
>  
> any thoughts?

I think what you meant to suggest was 'the ability to provide a default
value for input fields', your actual suggestion is to closely tied to
your own requirements and is not generally useful.

I would see having something like:

default_<fieldname>: <value>

in the configuration and using the values from there if none is supplied
in the form values.

We can add something like this to the TODO list, but it needs some keen
develo0per to pick it up.

/J\
-- 

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

[Nms-cgi-devel] [ nms-cgi-Support Requests-1449991 ] admin post delete issue

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

Support Requests item #1449991, was opened at 2006-03-14 23:24
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=1449991&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: Derek (drock22)
Assigned to: Nobody/Anonymous (nobody)
Summary: admin post delete issue

Initial Comment:
I am testing nms message board script on a Windows 
based server hosted at Crystal Tech and getting the 
following error when I attempt to delete a test post.

------------------->>

Application Error
replace 
D:\inetpub\canoecruisers\wwwboard/wwwboard.html: 
Permission denied at D:\Inetpub\canoecruisers\cgi-
bin\wwwadmin.pl line 340, <MESG_IN> line 96. An error 
has occurred in the program. 

replace 
D:\inetpub\canoecruisers\wwwboard/wwwboard.html: 
Permission denied at D:\Inetpub\canoecruisers\cgi-
bin\wwwadmin.pl line 340, <MESG_IN> line 96. 

------------------->>

I have checked all of the permissions and they are 
set correctly. I can also post messages, change admin 
passwords, etc. without any issues.

Any help or insight would be appreciated.

Thanks in advance,

Derek Jubach

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

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

[Nms-cgi-devel] Re: [Nms-cgi-support] FormMail help request

[Steven M. <nm...@ap...>]

Hi,

Have you spotted the file EXAMPLES packaged in with FormMail.pl? That
has examples of what you need to configure in FormMail.pl and what you
need to add to your HTML.

The slightly longer README file is also good if you want to find out
what certain inputs or configuration options are for.

My advice (I am someone who's just set up FormMail for the first time!):
In FormMail.pl:
1/ Put your email address in to FormMail.pl by changing this line in the
User Configuration section:
    %recipient_alias   = ();
make it look like this
    %recipient_alias   = ( me => 'my_...@ex...', );

In your HTML form:
1/ Make sure that the <form> tag has an action attribute that has the
full URL of FormMail.pl.

That is how you attach the form to the script.

2/ Make a hidden input tag like this:
<input type="hidden" name="recipient" value="me" />

That says "use the email address for 'me' that was configured in the
script".

Hope that's helpful,

Steven

quir os wrote:

> hi, i just recently downloaded your script to the cgi bin of my host
> and now i am trying to figure out how to use it.
>  
> i figure that i have to chance some values in the script so it have
> the e-mail address where to send the messages, but then what else?  i
> have the form for the site already set but how do i "attach" it to the
> script.
>  
> i will keep on playing with the script plus your prompt reply will be
> really appreciated.
>  
> -sheska
>
> ------------------------------------------------------------------------
> Brings words and photos together (easily) with
> PhotoMail
> <http://us.rd.yahoo.com/mail_us/taglines/PMall/*http://photomail.mail.yahoo.com>
> - it's free and works with Yahoo! Mail. 

Re: [Nms-cgi-devel] Suggestions for FormMail.pl

[Steven M. <nm...@ap...>]

Regarding adding a Content-Type header to submitted data email messages:

Jonathan Stowe wrote:

>Well, yes but the content is actually still assumed to be encoded as 7,
>the rfc you cited earlier doesn't make any provision for this. I think
>  
>
The content of an email body MUST to be 7-bit for the old fashioned
RFC-821/822 SMTP servers, and for them, yes the content must be encoded
"quoted printable" or something, and the Content-Transfer-Encoding and
Content-Type headers should be set appropriately. FormMail is currently
broken for these servers because it doesn't do that.

Servers can indicate that they can accept messages that contain 8-bit
bytes in the body. An RFC defining this capability, 8BITMIME, for was
published in 1994:
http://en.wikipedia.org/wiki/8BITMIME

Some mail servers already implement this. For these mail servers, it is
sufficient to simply add the correct content-type header describing the
body of the email message. If the mail server needs to relay the mail to
a server that does not support 8BITMIME, then the RFCs say that it is
the servers job to transfer encode the message body:
http://www.faqs.org/rfcs/rfc2821.html

My opinion is
1/ Adding the header doesn't make things more broken than they are already.
2/ The most common case is that the sending ESMTP server will support
8BITMIME extension.
3/ Adding the header is a valuable clue for receiving mail clients for
the common case.
4/ Doing a proper transfer encoding would be a significant change to a
dead-end script, so not worth persuing?

Regarding older versions of Perl -- I'm not sure how older versions of
Perl will change the decoding of the 8-bit characters.

The behaviour that they need to handle is this: If my HTML form is in
charset 8859-15, then the Euro symbol is encoded as %A4 (by the
browser); if the charset is UTF-8 the Euro is %E2%82%AC. CGI.pm decodes
these back to bytes when the form is received. As long as Perl 5
supports 8-bit characters, I don't see how it can know to convert them
to any other representation, it just needs to package the bytes
unchanged in to the email, and with the Content-Type header, I'm happy :-)

I hope that's interesting and helpful to you!

Steven

Re: [Nms-cgi-devel] Suggestions for FormMail.pl

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

On Fri, 2006-03-03 at 17:06, Steven Mackenzie wrote:
> Jonathan Stowe wrote:
> 
> >On Thu, 2006-03-02 at 21:22, Steven Mackenzie wrote:
> >  
> >
> >>A proposal to add a Content-type header to the mails sent by
> >>FormMail.pm, so that the emails include the charset that the user
> >>configured in FormMail.pl:
> >>
> >>After FormMail.pl: Line 1122
> >>Content-Type: text/plain; charset=${\( $self->{CFG}{charset} )}
> >>This was helpful for me. is it contentious?
> >>
> >>    
> >>
> >
> >This is a little tricky, the problem being that putting that header is
> >making a guarantee that the program possibly can't keep. 
> >
> Isn't the program doing that already?
> 
> The current situation is that the FormMail does not add any header to
> the email, so that the content MUST be assumed to be in 7-bit us-ascii.
> That is also a guarantee that the program doesn't try to keep.
> 
> The form defaults to ISO-8859-1 (HTML default character set). My
> understanding is that the browser will use this character set for the
> submitted data, which FormMail then blindly packages in to the body of
> the email (and maybe the headers too). So if any 8-bit characters are
> entered, they will violate the standard assumption of us-ascii.
> 
> Sure, it is better to reencode the data to keep it 7-bit clean, but that
> sounds like hard work. So just adding a header to declare the content
> type (of the body) seems like a valid thing to do, and does not make the
> program more broken than it is already when 8-bit bytes are sent in the
> email. As I said, it allows my mail client to render the email correctly!
> 

Well, yes but the content is actually still assumed to be encoded as 7,
the rfc you cited earlier doesn't make any provision for this. I think
that if one was to pursue this then we would need to implement rfc2045
and provide a Content-Transfer-Encoding as well: for the general case
this wouldn't be a problem as long as we only allow 8 bit character
sets, obviously we would be in the same position with regards to the
encoding if we were to allow arbitrary encodings.


> The confirmation email is a slightly different situation because it is
> not derived from the input content, but read from the script itself. 
> The person editing the script might know what character set they are
> using, and then could  simply add the header to the $confirmation_text
> definition, if the confirmation email was not in us-ascii. So I've
> changed my mind about the suggestion for adding the Content-type/charset
> to the confirmation email at FormMail.pm line 1292.
> 

The chances are that the person editing the file is completely oblivious
to the fact that they may have changed the encoding of the file simply
by editing it, let alone what they might have changed it to.

> I still think that adding the single line of code
> Content-Type: text/plain; charset=${\( $self->{CFG}{charset} )}
> in send_main_email_header is correct though, because it states the
> character set that the browser used to submit the data.
> 

As I suggested before this isn't actually enough, you need the
Content-Transfer-Encoding (and Mime-Version) header in order to properly
support 8 bit character sets. 

> Regarding using other versions of Perl, I don't know -- I've only ever
> used 5.8.7, but as I understand it, as Perl is not trying to render the
> characters, they should just flow through as data? Probably easier to
> test that behaviour than to understand what actually happens :-)

No there is a difference between Byte and Character semantics, there are
people who understand Perl's internals better than I do reading this and
I'm sure they could explain it.

> Maybe I would have just used TFMail if it had been at the top of the
> download web page, though actually I quite like the NMS FormMail, now I
> have it working!

Yeah, that's largely because the old FormMail was the most widely used
and thus with the most visible flaws, at some point we are going to
consign all of the MSA derived programs to a 'legacy' section, and
emphasise our new stuff.

/J\
-- 

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

Re: [Nms-cgi-devel] Suggestions for FormMail.pl

[Steven M. <nm...@ap...>]

Jonathan Stowe wrote:

>On Thu, 2006-03-02 at 21:22, Steven Mackenzie wrote:
>  
>
>>A proposal to add a Content-type header to the mails sent by
>>FormMail.pm, so that the emails include the charset that the user
>>configured in FormMail.pl:
>>
>>After FormMail.pl: Line 1122
>>Content-Type: text/plain; charset=${\( $self->{CFG}{charset} )}
>>This was helpful for me. is it contentious?
>>
>>    
>>
>
>This is a little tricky, the problem being that putting that header is
>making a guarantee that the program possibly can't keep. 
>
Isn't the program doing that already?

The current situation is that the FormMail does not add any header to
the email, so that the content MUST be assumed to be in 7-bit us-ascii.
That is also a guarantee that the program doesn't try to keep.

The form defaults to ISO-8859-1 (HTML default character set). My
understanding is that the browser will use this character set for the
submitted data, which FormMail then blindly packages in to the body of
the email (and maybe the headers too). So if any 8-bit characters are
entered, they will violate the standard assumption of us-ascii.

Sure, it is better to reencode the data to keep it 7-bit clean, but that
sounds like hard work. So just adding a header to declare the content
type (of the body) seems like a valid thing to do, and does not make the
program more broken than it is already when 8-bit bytes are sent in the
email. As I said, it allows my mail client to render the email correctly!

The confirmation email is a slightly different situation because it is
not derived from the input content, but read from the script itself. 
The person editing the script might know what character set they are
using, and then could  simply add the header to the $confirmation_text
definition, if the confirmation email was not in us-ascii. So I've
changed my mind about the suggestion for adding the Content-type/charset
to the confirmation email at FormMail.pm line 1292.

I still think that adding the single line of code
Content-Type: text/plain; charset=${\( $self->{CFG}{charset} )}
in send_main_email_header is correct though, because it states the
character set that the browser used to submit the data.

Regarding using other versions of Perl, I don't know -- I've only ever
used 5.8.7, but as I understand it, as Perl is not trying to render the
characters, they should just flow through as data? Probably easier to
test that behaviour than to understand what actually happens :-)

Maybe I would have just used TFMail if it had been at the top of the
download web page, though actually I quite like the NMS FormMail, now I
have it working!

Steven

>Firstly we
>can't know what has happened to the program after it has been
>downloaded, the encoding of the program file could be changed by some
>editor or it might be changed during the upload process - this will
>affect the actual encoding of the output, and as we are only using the
>charset to do encoding sensitive sanitizing of the input data for the
>output and not actually coercing the encoding of the output it is
>possible that the actual output is not going to get the encoding
>supplied in 'charset'.  The other problem and one which militates
>against our being able to fix the first by coercing the output is that
>with the legacy programs such as FormMail we are committed to being able
>to support versions of Perl as old as 5.004.04 and before the 5.6.0
>release there was virtually no support for unicode and it couldn't
>really be said to be perfect until 5.8.1 so we could have a problem with
>properly handling the encodings properly as I see it, unless of course
>someone wants to persuade me differently.
>
>On the flip side if people were concerned about setting an appropriate
>Content-Type we would probably recommend them to use TFmail as this uses
>a slightly modified version of the MIME::Lite module to do the MIME bits
>for us.
>
>/J\
>  
>

Re: [Nms-cgi-devel] Suggestions for FormMail.pl

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

On Thu, 2006-03-02 at 21:22, Steven Mackenzie wrote:
> A proposal to add a Content-type header to the mails sent by
> FormMail.pm, so that the emails include the charset that the user
> configured in FormMail.pl:
> 
> One of the user configurable parameters in FormMail.pl is charset.
> 
> My HTML form is written in UTF-8, I have set charset to UTF-8, and
> posted data is emailed to me as UTF-8. Unfortunately, the emails do not
> use the Content-type header, so my mail client displays them in a
> default characterset, which is not UTF-8.
> 
> Adding these two lines of code to FormMail.pm resolve the issue:
> 
> After FormMail.pl: Line 1285
>     $self->mailer->print("Content-Type: text/plain;
> charset=".$self->{CFG}{charset}."\n");
> 
> After FormMail.pl: Line 1122
> Content-Type: text/plain; charset=${\( $self->{CFG}{charset} )}
> 
> http://www.ietf.org/rfc/rfc1049.txt  - content type header for email
> http://www.sendmail.org/rfc/0822.html#4 - headers may be in any order
> 
> This was helpful for me. is it contentious?
> 

This is a little tricky, the problem being that putting that header is
making a guarantee that the program possibly can't keep. Firstly we
can't know what has happened to the program after it has been
downloaded, the encoding of the program file could be changed by some
editor or it might be changed during the upload process - this will
affect the actual encoding of the output, and as we are only using the
charset to do encoding sensitive sanitizing of the input data for the
output and not actually coercing the encoding of the output it is
possible that the actual output is not going to get the encoding
supplied in 'charset'.  The other problem and one which militates
against our being able to fix the first by coercing the output is that
with the legacy programs such as FormMail we are committed to being able
to support versions of Perl as old as 5.004.04 and before the 5.6.0
release there was virtually no support for unicode and it couldn't
really be said to be perfect until 5.8.1 so we could have a problem with
properly handling the encodings properly as I see it, unless of course
someone wants to persuade me differently.

On the flip side if people were concerned about setting an appropriate
Content-Type we would probably recommend them to use TFmail as this uses
a slightly modified version of the MIME::Lite module to do the MIME bits
for us.

/J\
-- 

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

Re: [Nms-cgi-devel] Suggestions for FormMail.pl

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

On Thu, 2006-03-02 at 21:22, Steven Mackenzie wrote:
> A proposal to add a Content-type header to the mails sent by
> FormMail.pm, so that the emails include the charset that the user
> configured in FormMail.pl:
> 
> One of the user configurable parameters in FormMail.pl is charset.
> 
> My HTML form is written in UTF-8, I have set charset to UTF-8, and
> posted data is emailed to me as UTF-8. Unfortunately, the emails do not
> use the Content-type header, so my mail client displays them in a
> default characterset, which is not UTF-8.
> 
> Adding these two lines of code to FormMail.pm resolve the issue:
> 
> After FormMail.pl: Line 1285
>     $self->mailer->print("Content-Type: text/plain;
> charset=".$self->{CFG}{charset}."\n");
> 
> After FormMail.pl: Line 1122
> Content-Type: text/plain; charset=${\( $self->{CFG}{charset} )}
> 
> http://www.ietf.org/rfc/rfc1049.txt  - content type header for email
> http://www.sendmail.org/rfc/0822.html#4 - headers may be in any order
> 
> This was helpful for me. is it contentious?
> 
> Steven
> 
> 
> Jonathan Stowe wrote:
> 
> >On Thu, 2006-03-02 at 16:44, Steven Mackenzie wrote:
> >  
> >
> >>Hello,
> >>
> >>I have made some small changes to my FormMail.pm installation to use the
> >>configured Mailer name consistantly, avoid mails being flagged as spam
> >>by SpamAssassin, and to add a content type header that respects the
> >>users configured character set.
> >>
> >>I see the FormMail script hasn't been updated in a while though. Is
> >>anyone interested in adding these changes (in while case I'll describe
> >>and justify them)?
> >>    
> >>
> >
> >FormMail hasn't been changed in a while because it hasn't had any bugs
> >to be fixed and we are not encouraging adding new features - we are
> >concentrating any new development in TFmail as we aren't constrained by
> >the legacy of compatibility with the MSA FormMail.
> >
> >However if you send us a patch against the modules version of FormMail
> >we can take a look and discuss it.
> >
> >/J\
> >
> >  
> >
> 
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> 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/

Re: [Nms-cgi-devel] Suggestions for FormMail.pl

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

On Thu, 2006-03-02 at 20:48, Steven Mackenzie wrote:
> Hi Jonathan,
> 
> One of my proposed changes: one liners for FormMail.pl and FormMail.pm,
> at the bottom of this message. If you really need patches, then can you
> let me know how you like them made?

The output of diff -Bub oldversion newversion is best so we can see
exactly what is changed.

> 
> There is a widely reported problem where SpamAssassin flags the results
> of NMS FormMail submissions as "BUGGY_CGI", after an inspection of the
> X-Mailer header. This does not apply to the confirmation emails, only to
> the submitted data. See for example,
> http://news.spamcop.net/pipermail/spamcop-mail/2003-July/009795.html
> which describes the SpamAssassin checks.
> 

Yes we keep sending them patches to fix this and they either change
something or forget to apply the patches.  Of course this isn't really a
'problem' unless you have locally configured your the score for
BUGGY_CGI to be higher than it is, alternatively you can whitelist the
mails in a number of ways within SpamAssassin.


> Looking at the code in FormMail.pm, confirmation emails are sent with a
> string made from a hard-coded part and the module version number, see
> FormMail.pm, Line 1282
>     $self->mailer->newmail("NMS FormMail.pm v$VERSION",
> $self->{CFG}{postmaster}, $email);
> 
> This string is matched by the SpamAssassin regex, and will not be
> flagged as BUGGY_CGI.
> 
> However, the submitted data is sent using the name_and_version string
> defined in FormMail.pl, which is different.
> 
> FormMail.pl: Line 94
>      name_and_version       => 'NMS FormMail 3.14m1',
> 
> Although this string is in the "non modifyable" section of FormMail.pl,
> it can be overridden in user config, by for example
> $more_config{name_and_version} = "My Mail Form";
> 
> I want to modify this because I am trying to get some extra obscurity by
> changing the value of my X-Mailer header, so I don't want NMS formmail
> advertised in my confirmation emails.
> 

I'm not sure what this buys you really, I hope you aren't thinking that
this is buying you any extra security or something.

> This string (usually with its default value) is used in FormMail.pm,
> Line 1057
>   $mailer->newmail($self->name_and_version, $self->{CFG}{postmaster}, @{
> $self->{Recipients} });
> 
> Mails to the scripts coded recipient are sent using this X-Mailer name,
> and will be flagged as BUGGY_CGI if SpamAssassin gets a sniff of them.
> 
> My first proposed change is that the default string at FormMail.pl line
> 94 should match the SpamAssassin regex, so should be
> FormMail.pl: Line 94:
>      name_and_version       => 'NMS FormMail.pl v3.14m1',
> 

I think the confirmation email should be fixed to use
$self->name_and_email() and the input to the constructor should set the
'name_and_version' to "NMS FormMail.pl v$VERSION"

> My second proposed change is that the configured X-Mailer name should be
> used in the confirmation and the submission emails. version number, see
> FormMail.pm, Line 1282
>     $self->mailer->newmail($self->name_and_version,
> $self->{CFG}{postmaster}, $email);
> 

Yes, I'm not quite sure why there is the different usage to be honest.

> Obviously I've changed my install so I'm happy, but it would be helpful
> for all the people confused that their NMS emails are being flagged as
> buggy! Any thoughts?
> 

I can't see any problem with this - I'll stick them in the code and
they'll be in the next release.

> Regards,
> Steven
> 
> 
> Jonathan Stowe wrote:
> 
> >On Thu, 2006-03-02 at 16:44, Steven Mackenzie wrote:
> >  
> >
> >>Hello,
> >>
> >>I have made some small changes to my FormMail.pm installation to use the
> >>configured Mailer name consistantly, avoid mails being flagged as spam
> >>by SpamAssassin, and to add a content type header that respects the
> >>users configured character set.
> >>
> >>I see the FormMail script hasn't been updated in a while though. Is
> >>anyone interested in adding these changes (in while case I'll describe
> >>and justify them)?
> >>    
> >>
> >
> >FormMail hasn't been changed in a while because it hasn't had any bugs
> >to be fixed and we are not encouraging adding new features - we are
> >concentrating any new development in TFmail as we aren't constrained by
> >the legacy of compatibility with the MSA FormMail.
> >
> >However if you send us a patch against the modules version of FormMail
> >we can take a look and discuss it.
> >
> >/J\
> >
> >  
> >
> 
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> 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/

Re: [Nms-cgi-devel] Suggestions for FormMail.pl

[Steven M. <nm...@ap...>]

A proposal to add a Content-type header to the mails sent by
FormMail.pm, so that the emails include the charset that the user
configured in FormMail.pl:

One of the user configurable parameters in FormMail.pl is charset.

My HTML form is written in UTF-8, I have set charset to UTF-8, and
posted data is emailed to me as UTF-8. Unfortunately, the emails do not
use the Content-type header, so my mail client displays them in a
default characterset, which is not UTF-8.

Adding these two lines of code to FormMail.pm resolve the issue:

After FormMail.pl: Line 1285
    $self->mailer->print("Content-Type: text/plain;
charset=".$self->{CFG}{charset}."\n");

After FormMail.pl: Line 1122
Content-Type: text/plain; charset=${\( $self->{CFG}{charset} )}

http://www.ietf.org/rfc/rfc1049.txt  - content type header for email
http://www.sendmail.org/rfc/0822.html#4 - headers may be in any order

This was helpful for me. is it contentious?

Steven


Jonathan Stowe wrote:

>On Thu, 2006-03-02 at 16:44, Steven Mackenzie wrote:
>  
>
>>Hello,
>>
>>I have made some small changes to my FormMail.pm installation to use the
>>configured Mailer name consistantly, avoid mails being flagged as spam
>>by SpamAssassin, and to add a content type header that respects the
>>users configured character set.
>>
>>I see the FormMail script hasn't been updated in a while though. Is
>>anyone interested in adding these changes (in while case I'll describe
>>and justify them)?
>>    
>>
>
>FormMail hasn't been changed in a while because it hasn't had any bugs
>to be fixed and we are not encouraging adding new features - we are
>concentrating any new development in TFmail as we aren't constrained by
>the legacy of compatibility with the MSA FormMail.
>
>However if you send us a patch against the modules version of FormMail
>we can take a look and discuss it.
>
>/J\
>
>  
>

Re: [Nms-cgi-devel] Suggestions for FormMail.pl

[Steven M. <nm...@ap...>]

Hi Jonathan,

One of my proposed changes: one liners for FormMail.pl and FormMail.pm,
at the bottom of this message. If you really need patches, then can you
let me know how you like them made?

There is a widely reported problem where SpamAssassin flags the results
of NMS FormMail submissions as "BUGGY_CGI", after an inspection of the
X-Mailer header. This does not apply to the confirmation emails, only to
the submitted data. See for example,
http://news.spamcop.net/pipermail/spamcop-mail/2003-July/009795.html
which describes the SpamAssassin checks.

Looking at the code in FormMail.pm, confirmation emails are sent with a
string made from a hard-coded part and the module version number, see
FormMail.pm, Line 1282
    $self->mailer->newmail("NMS FormMail.pm v$VERSION",
$self->{CFG}{postmaster}, $email);

This string is matched by the SpamAssassin regex, and will not be
flagged as BUGGY_CGI.

However, the submitted data is sent using the name_and_version string
defined in FormMail.pl, which is different.

FormMail.pl: Line 94
     name_and_version       => 'NMS FormMail 3.14m1',

Although this string is in the "non modifyable" section of FormMail.pl,
it can be overridden in user config, by for example
$more_config{name_and_version} = "My Mail Form";

I want to modify this because I am trying to get some extra obscurity by
changing the value of my X-Mailer header, so I don't want NMS formmail
advertised in my confirmation emails.

This string (usually with its default value) is used in FormMail.pm,
Line 1057
  $mailer->newmail($self->name_and_version, $self->{CFG}{postmaster}, @{
$self->{Recipients} });

Mails to the scripts coded recipient are sent using this X-Mailer name,
and will be flagged as BUGGY_CGI if SpamAssassin gets a sniff of them.

My first proposed change is that the default string at FormMail.pl line
94 should match the SpamAssassin regex, so should be
FormMail.pl: Line 94:
     name_and_version       => 'NMS FormMail.pl v3.14m1',

My second proposed change is that the configured X-Mailer name should be
used in the confirmation and the submission emails. version number, see
FormMail.pm, Line 1282
    $self->mailer->newmail($self->name_and_version,
$self->{CFG}{postmaster}, $email);

Obviously I've changed my install so I'm happy, but it would be helpful
for all the people confused that their NMS emails are being flagged as
buggy! Any thoughts?

Regards,
Steven


Jonathan Stowe wrote:

>On Thu, 2006-03-02 at 16:44, Steven Mackenzie wrote:
>  
>
>>Hello,
>>
>>I have made some small changes to my FormMail.pm installation to use the
>>configured Mailer name consistantly, avoid mails being flagged as spam
>>by SpamAssassin, and to add a content type header that respects the
>>users configured character set.
>>
>>I see the FormMail script hasn't been updated in a while though. Is
>>anyone interested in adding these changes (in while case I'll describe
>>and justify them)?
>>    
>>
>
>FormMail hasn't been changed in a while because it hasn't had any bugs
>to be fixed and we are not encouraging adding new features - we are
>concentrating any new development in TFmail as we aren't constrained by
>the legacy of compatibility with the MSA FormMail.
>
>However if you send us a patch against the modules version of FormMail
>we can take a look and discuss it.
>
>/J\
>
>  
>

Re: [Nms-cgi-devel] Suggestions for FormMail.pl

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

On Thu, 2006-03-02 at 16:44, Steven Mackenzie wrote:
> Hello,
> 
> I have made some small changes to my FormMail.pm installation to use the
> configured Mailer name consistantly, avoid mails being flagged as spam
> by SpamAssassin, and to add a content type header that respects the
> users configured character set.
> 
> I see the FormMail script hasn't been updated in a while though. Is
> anyone interested in adding these changes (in while case I'll describe
> and justify them)?

FormMail hasn't been changed in a while because it hasn't had any bugs
to be fixed and we are not encouraging adding new features - we are
concentrating any new development in TFmail as we aren't constrained by
the legacy of compatibility with the MSA FormMail.

However if you send us a patch against the modules version of FormMail
we can take a look and discuss it.

/J\

-- 

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

[Nms-cgi-devel] Suggestions for FormMail.pl

[Steven M. <ste...@ap...>]

Hello,

I have made some small changes to my FormMail.pm installation to use the
configured Mailer name consistantly, avoid mails being flagged as spam
by SpamAssassin, and to add a content type header that respects the
users configured character set.

I see the FormMail script hasn't been updated in a while though. Is
anyone interested in adding these changes (in while case I'll describe
and justify them)?

Steven

[Nms-cgi-devel] Re: [Nms-cgi-support] problem with formmail

[<ul...@gu...>]

Am 25.02.2006 um 18:58 schrieb Dave Cross:

> Ulrike G=FCnnel wrote:
>> Hi Dave,
>> thx for the quick answer.
>> I just found the answer of my problem. Now it works.
>> I had to change the script header. It should be #! /usr/bin/perl  =20
>> without any parameters. Now it works. Where are the parameters -wT =20=

>> for?
>> Can I remove it without problems?
>
> Removing those options doesn't solve problems. It simply hides them.

;-) good answer

>
> I suspect that you are coming up against the problem that is =20
> described in the answer to "I am getting the Error 'Too late for -T =20=

> option', what can I do?" at
>
>   http://nms-cgi.sourceforge.net/faq_prob.html

I will try my luck and find some answers there.

>
> Dave...
>

Thx so long.

Ciao Uli

[Nms-cgi-devel] Re: [Nms-cgi-support] Simple Search

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

On Wed, 2006-02-22 at 15:41, Ken Browder wrote:
> Hello and thank you for reading.
>  
> I just downloaded Simple Search and I am trying to implement it into
> our web pages.
>  
> I do have it working quite well on my desktop computer but not yet on
> our web site. I NEED to embed it into my page template some way. I
> have cudgled my brain but can't seem to work it out.
>  
> Of course, I have the search form on my front page, but the search
> results come out full page without CSS control.

You can apply a CSS stylesheet to the results by setting the $style
configuration.  As it currently stands the only further customization
you can do to the search results is by editing the search.pl and
carefully changing the the HTML in the subroutines 

    start_html
    print_result
    end_html

Starting at around line 380.

You need to be careful editing this as it is very easy to introduce a
syntax error into the program.

We do have on our TODO list a new search program which will use
templates for the output and an external configuration file in the same
way and using the same underlying components as our TFmail program -
I've copied the devel list incase someone feels inclined to start
knocking this together.

/J\
-- 

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

[Nms-cgi-devel] Re: [Nms-cgi-support] TFMail File Upload afterConfirmation Page

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

On Mon, 2006-02-20 at 18:01, Harry Smith wrote:
> I think I have followed the readme instructions but cannot get file uploads 
> to work after a confirmation page.
> 
> I have a page where you browse for a file to upload.  You then click a 
> submit button which takes you to a confirm page where you check upload 
> details are correct.  You then hit a submit button to send the file plus 
> other text info.
> 
> I have tried a confirm.trc with
> 
> no_email: 1
> success_page_template: upload_sucesspage
> 
> and a confirm page including this trc
> 
> recipient:me@site
> email_template:my_email
> upload_afile:doc pdf rtf txt
> print_blank_fields:true
> 
> Both the initial html page and the confirm page use:
> <form method="post" enctype="multipart/form-data" 
> action="/cgi-bin/TFmail.pl">
> 
> although I have tried other variations on this.
> 
> The problem is I assume that the <input type="file" name="afile"> becomes 
> <input type="hidden" name="afile">  in the html confirm page.
> 
> If I put <input type="file" > in the first entry form entry page and then 
> add
> 
> recipient:me@site
> email_template:my_email
> upload_afile:doc pdf rtf txt
> 
> to the confirm.trc then the file is sent as an e-mail attachment.  But this 
> makes the confirm button meaningless.
> 
> Equally, if I put <input type="file" > in the confirm form I then get a 
> browse button to go to a file and upload it.  But then this is not a confirm 
> form anymore.
> 
> How can I pass a file to upload to a confirm form.  It would need to be an 
> input with features of both <input type="file" > and <input type="hidden" 
> > I suppose.

Unfortunately there is a fundamental problem with this (or two depending
on how you look at it.)  The 'file' input type causes the content of the
file to be uploaded with the submission of the form and for fairly
obvious security reasons the only way to specify the file to upload is
by selecting it through the 'browse button' (or whatever mechanism the
browser supplies to select the file to upload.) So no you can't have a
'hidden' file input field.

The only way in the general sense that one could achieve this is to save
the file on the first submission when it is uploaded and then when the
confirmation page is submitted retrieve the saved file and attach it to
the email.  Unfortunately TFmail can't currently do this, it is entirely
doable but it will require some thought to be able to do it efficiently
and securely (there is a need to retain some state information and
ensure that no files get overwritten) and I'm not able to give a time
frame when we can implement it.

I've copied the developers list in case anyone has the time to implement
this.

I don't think we can offer you a solution in the short term I'm afraid,
a lot of the pieces needed are there but there is no way to tie them
together.

/J\
-- 

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

Re: [Nms-cgi-devel] Re: [Nms-cgi-support] Admin remove does not remove followup links

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

On Fri, 2006-02-10 at 09:55, Dave Cross wrote:
> Jonathan Stowe wrote:
> 
> > I have copied in the devel list in case there is anyone still reading
> > that who might feel like a bit of exercise, otherwise it'll have to wait
> > until I get around to doing it.
> 
> [ time passes... nothing happens... ]
> 
> There are 78 people subscribed to this list. Is there anyone out there 
> who has any interest in actually doing any nms development?

They probably don't even remember they're subscribed - it's low enough
traffic that most people wouldn't notice.

/J\
-- 

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

[Nms-cgi-devel] Re: [Nms-cgi-support] Admin remove does not remove followup links

[Dave C. <da...@da...>]

Jonathan Stowe wrote:

> I have copied in the devel list in case there is anyone still reading
> that who might feel like a bit of exercise, otherwise it'll have to wait
> until I get around to doing it.

[ time passes... nothing happens... ]

There are 78 people subscribed to this list. Is there anyone out there 
who has any interest in actually doing any nms development?

Just idly wondering :)

Dave...

-- 
Site: http://dave.org.uk/
Blog: http://blog.dave.org.uk/
Code: http://dave.org.uk/code/

[Nms-cgi-devel] Re: [Nms-cgi-support] Admin remove does not remove followup links

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

On Wed, 2006-02-08 at 05:11, Joey wrote:
> I'm using the nms wwwboard program.  When using the admin mode and
> followups are deleted, none of the follow up links are deleted from
> the other messages.  This effectively allows the trolls or spammers to
> keep their links and names on my site despite the fact that I've
> removed the actual message.   
>  
> When a message is deleted, all links associated with that message
> should be automatically removed as well. 

Yes you are probably right, to be honest wwwadmin could do with a
complete rewrite anyway it has had the least attention of the NMS
programs - this is largely because wwwboard is basically a really
horrible program that should have been abandoned years ago but it
refuses to die and all the developers seem to largely ignore in the hope
that it will go away.

There are a number of problems with retrofitting this to the existing
wwwadmin/wwwboard, firstly any given message does not contain the
information that it is a followup to another message and what that
message might be (except in the "In Reply to" link but not is not
completely useful for our purposes) so it is likely that we would have
to build up the tree structure from the main page in order to find the
predecessor and descendant of the page being removed (bearing in mind
that if we do this we really should remove the "In Reply To" from any
subsequent follow up), we also are going to need to potentially traverse
a whole tree of replies to rewrite all of the files above the removed
one to recreate the tree of responses on all of them.  So this is not
just a quick hack - it will require some thought.

To some extent we are constrained by the requirement to remain backwards
compatible with the files created by the MSA wwwboard however horrible
the design might have been, I think that we would probably end up with a
compromise whereby if we were to fix this behaviour we would have the
existing messages treated the same as they currently are and only fix up
the references for messages and threads created with the changed
wwwboard.

>  If provided a little direction, I would be glad to help with this
> problem.   

A patch in "diff -Bub" format would be fabulous :-)

Looking at wwwadmin.pl it really does need a very very big makeover, it
currently handles files in some very unsafe ways and really should at
the very least use File::Transaction like wwwboard itself does  - it
does use the .lock file like wwwboard so it should prevent file
corruption but I need to check that more carefully.

I have copied in the devel list in case there is anyone still reading
that who might feel like a bit of exercise, otherwise it'll have to wait
until I get around to doing it.

>  
> I think that my configuration currently runs in emulate Matt's mode. 

It appears this has no effect in the wwwadmin
>  

/J\
-- 

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

[Nms-cgi-devel] [ nms-cgi-Support Requests-1424835 ] Guestbook

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

Support Requests item #1424835, was opened at 2006-02-05 18:00
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=1424835&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: Ed_R (rnrcomp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Guestbook

Initial Comment:
Was wondering how I could change around to order the 
field are displayed in the Guestbook and COnfirmation 
page?

Thanks!

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

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

[Nms-cgi-devel] Re: [Nms-cgi-support] tfmail help

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

On Wed, 2006-01-25 at 00:21, Marc Austin wrote:
> Thanks - I tried this using checkboxes - can't I do it THAT way?
> 
> <INPUT TYPE="checkbox" NAME="_config" VALUE="clevengers">Clevenger's  
> Detectors<BR>		
> <INPUT TYPE="checkbox" NAME="_config" VALUE="coiltek">Coiltek Coils<BR>
> <INPUT TYPE="checkbox" NAME="_config" VALUE="depthmaster">Depth  
> Master<BR>
> <INPUT TYPE="checkbox" NAME="_config" VALUE="detectorpro">Detector  
> Pro<BR>
> <INPUT TYPE="checkbox" NAME="_config" VALUE="fisherresearch">Fisher  
> Research

NO you can't do it like this because you can't specify more than one
configuration file.  

Let me get this straight, you want to be able to select for any number
of a list of potential recipients based on the form input?  TFmail
doesn't currently have any facility to do this unfortunately.  You could
lash something up in Javascript by looping through the checkbox values
and submitting once for each with _config set in turn to a single value
and no_content set in the configuration (finally ending up with a
default one that prints the confirmation but doesn't send mail).  Right
at this moment I can't even think how we might change TFmail to support
this kind of functionality without implementing some kind of
"programming language" into the configuration: I have copied this to the
devel list to see if anyone has any ideas.

/J\


-- 

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