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

RE: [Nms-cgi-devel] Questions regarding email filter...

[Wizard <wi...@ne...>]

> I think it would be perfectly acceptable to require users to specify
> both domains.

It would be. I just hope to make it better than that.

> I still think it is a requirement to block whole sub-domains, for
> instance *@*.kr or *@*.spammers-r-us.com

I'm not sure that we differ on that, but there could be some problems with
it either way: how does the second example treat the example given yesterday
of info@dk? or fr...@sp...? Depending on how it parses, we could
block neither or both. Is it better to fail conservatively, aggressively, or
not at all? These are all things I'm trying to consider (my brain hurts).

> It would be a very cool thing but I'm not convinced it is doable or
> necessary. Big kudos to you if it works though :)

I'm not convinced either, just an optimistic pessimist. That means that my
glass is half-full of crap :-).
Grant M.

RE: [Nms-cgi-devel] Questions regarding email filter...

[Simon W. <es...@ou...>]

On Wed, 2003-02-12 at 12:02, Wizard wrote:

> That is actually one of three possible uses, another is to moderate posts
> for certain emails/domains, and lastly to possibly block sending email
> (later version, subscription email) to those addresses. This is in
> combination with IP filtering. It is easy to get around if you're willing to
> change you're email every time you're blocked from posting, and can post
> from different IP ranges. Unless you are willing to retrieve numerous email
> accounts from different domains, you won't get any email from your posts,
> i.e., advertising posts. This was an issue for a friend of mine at Coonhound
> Central, where people would post classifieds in the message board when they
> should have been buying classifieds.

Ah yes, I see. I hadn't thought of that particular use.

> > Everyone at a domain containing a word somewhere in the hierarchy
> 
> Not really, but everyone in a WHOLE Domain, meaning everyone at
> "JoeSchmoes", where "JoeSchmoes" may consist of:
> cuba.joeschmoes.com       # not cuba.co.uk
> joeschmoes.fi            # not joeschmoes.yahoo.co.uk
> google.joeschmoes.com     # not google.com

I just don't see under which set of circumstances you would want to
block joeschmoes.com and joeschmoes.co.uk with one filter.

I think it would be perfectly acceptable to require users to specify
both domains.

> > I just don't see that this would be a requirement for most people. If
> > they want to ban aol.de and aol.co.uk then let them put both in the
> > configuration. I actually think it would cause *less* confusion than odd
> > edge cases falling through the filter.
> 
> Then it would probably be better to just do full ^-$ string matches on the
> post-@ string, which isn't really what I hoped to accomplish. That may be
> the only option, though. I'm not arguing that this may not be possible, but
> if it is (reliably so) then I would love to include it.

I still think it is a requirement to block whole sub-domains, for
instance *@*.kr or *@*.spammers-r-us.com

> > I believe that it is over-complicating things to try and develop a
> > filter for something that is semantically richer than you can see just
> > by looking at the domain name.
> 
> You may be correct, but it's just that I seem to be so close to what I am
> trying to do with the code that I have. If at all possible it would be nice
> to have it.

It would be a very cool thing but I'm not convinced it is doable or
necessary. Big kudos to you if it works though :)

Simon.

RE: [Nms-cgi-devel] Questions regarding email filter...

[Wizard <wi...@ne...>]

> If I knew more about the existing wwwboard I could probably answer this
> one but where do these addresses come from ?

It isn't in the existing wwwboard (it was requested by users). This is new
for NMSBoard. They come from the post form, as you state below.

> I'm presuming they come from a user entering it via an html form in
> which case it would be laughably easy to get around.

That is actually one of three possible uses, another is to moderate posts
for certain emails/domains, and lastly to possibly block sending email
(later version, subscription email) to those addresses. This is in
combination with IP filtering. It is easy to get around if you're willing to
change you're email every time you're blocked from posting, and can post
from different IP ranges. Unless you are willing to retrieve numerous email
accounts from different domains, you won't get any email from your posts,
i.e., advertising posts. This was an issue for a friend of mine at Coonhound
Central, where people would post classifieds in the message board when they
should have been buying classifieds.

> That being so, perhaps we are over-engineering the filtering ?

That is entirely possible, but I'm just working off of how I think it should
work. If folks think that this need only be single email matching (string
match) then I'll be happy to do it that way. Did you get a chance to look at
the example code I sent out? That may help explain my motivation ;-).

> As far as I can see, the cases we need to deal with are:
>
> A specific email address
> Everyone at a specific domain
> Everyone at a domain and its subdomains
>
> The case you seem to be struggling with is
>
> Everyone at a domain containing a word somewhere in the hierarchy

Not really, but everyone in a WHOLE Domain, meaning everyone at
"JoeSchmoes", where "JoeSchmoes" may consist of:
cuba.joeschmoes.com       # not cuba.co.uk
joeschmoes.fi            # not joeschmoes.yahoo.co.uk
google.joeschmoes.com     # not google.com

> I just don't see that this would be a requirement for most people. If
> they want to ban aol.de and aol.co.uk then let them put both in the
> configuration. I actually think it would cause *less* confusion than odd
> edge cases falling through the filter.

Then it would probably be better to just do full ^-$ string matches on the
post-@ string, which isn't really what I hoped to accomplish. That may be
the only option, though. I'm not arguing that this may not be possible, but
if it is (reliably so) then I would love to include it.

> I believe that it is over-complicating things to try and develop a
> filter for something that is semantically richer than you can see just
> by looking at the domain name.

You may be correct, but it's just that I seem to be so close to what I am
trying to do with the code that I have. If at all possible it would be nice
to have it.

Thanks again,
Grant M.

RE: [Nms-cgi-devel] Questions regarding email filter...

[Simon W. <es...@ou...>]

On Tue, 2003-02-11 at 20:46, Wizard wrote:
> Just so that I'm explaining myself fully, this is for DENY/ALLOW filtering
> for users to post to NMSBoard, i.e., to block users with specific emails
> from posting messages.

If I knew more about the existing wwwboard I could probably answer this
one but where do these addresses come from ?

I'm presuming they come from a user entering it via an html form in
which case it would be laughably easy to get around.

That being so, perhaps we are over-engineering the filtering ?

As far as I can see, the cases we need to deal with are:

A specific email address
Everyone at a specific domain
Everyone at a domain and its subdomains

The case you seem to be struggling with is

Everyone at a domain containing a word somewhere in the hierarchy

I just don't see that this would be a requirement for most people. If
they want to ban aol.de and aol.co.uk then let them put both in the
configuration. I actually think it would cause *less* confusion than odd
edge cases falling through the filter.

I believe that it is over-complicating things to try and develop a
filter for something that is semantically richer than you can see just
by looking at the domain name.

Simon.

[Nms-cgi-devel] RE: Email filtering example code...

[Wizard <wi...@ne...>]

Here's some sample code to give people a better idea of what I am trying to
do (it's not pretty). It will parse the email address given as I had
planned, but doesn't actually do any comparisons yet. My primary reason for
wanting to do this is DWIM for the user, where fr...@to... will
not be disallowed by "*@tobago.*" whose intent is to filter tobago.com,
tobago.net, etc, not prodigy.net.
==================================================CUT FROM HERE
#/usr/bin/perl

# This would actually come from a .cfg file
my $users = "fred\@fsck.com, john\@ted.com, dev\@null.*, weiner\@fred.*";

my $user = shift; # get email from shell - "prog.pl us...@em..."

my $valid_tlds =
"[com][gov][org][edu][net][biz][arpa][int][nato][info][name][museum][coop][a
ero][pro][co][mil]";

my $bool = &check_user( $user, $users ); # call sub

sub check_user {
    my $user = shift @_;
    my $blocked_users = shift @_;
    my( @bad_users, $name, $tmp, @cnames, $dn, $tld, $country, $port );
    $blocked_users =~ s/\,\s*/+/g;
    foreach( split /\+/, $blocked_users ) {
        push @bad_users, $_;
    }
    ($name, my $tmp) = split /\@/, $user;
    @cnames = split /\./, $tmp;
    $tld = pop @cnames;
    if( length( $tld ) < 3 ) {
        $country = $tld;
        $tld = pop @cnames;
        if( $valid_tlds !~ /\[$tld\]/ ) {
            $dn = $tld;
            $tld = $country;
        }
    }
    $dn = pop @cnames if !$dn;
    $dn = $tld if !$dn;
    print "NAME: $name\n" if $name;
    print "CNAMES: ", join( '.', @cnames ), "\n";
    print "DOMAIN: $dn\n";
    print "TLD: $tld\n" if defined $tld;
    print "COUNTRY: $country\n" if defined $country;
} # end check_user()
=========================================CUT TO HERE
Each of the @bad_users entries is parsed exactly the same with '*'s replaced
with '.*'s, and then each component would be matched against the
corresponding user component, like so:
$user_tld =~ /^$blocked_tld$/ if $user_tld;
$user_dn =~ /^$blocked_dn$/ if $user_dn;
...
Hope that helps,
Grant M.

RE: [Nms-cgi-devel] Questions regarding email filter...

[Wizard <wi...@ne...>]

> http://dk/
>
> although your web browser or proxy is probably broken, and will
> need you to
> write that as http://dk./

No, the browser worked.
Well they just don't get to use NMSBoard at all. problem solved. ;-)
README file =====
"Note: you are not allowed to use NMS scripts at all if we feel that your
domain or email address is annoying or silly."
;-)

> If you wish to parse e-mail addresses for validity, you could use the 8000
> character regexp in Mastering Regular Expressions, although it won't cope
> with nested comments, and won't actually tell you about
> non-existent domains.

No, it's actually for DENY/ALLOW. Se my last few messages.
Thanks,
Grant M.

Re: [Nms-cgi-devel] Questions regarding email filter...

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

On Tue, Feb 11, 2003 at 03:29:48PM +0000, Simon Wilcox wrote:
> On Tue, 2003-02-11 at 15:12, Wizard wrote:
> > > in...@bl... is valid too. And what is a standard anyway ?

> > > Do you mean .us domains of G-TLD's like .com and .org ?
> > 
> > The latter, as anything else should be handled by the international code.
> 
> whithouse.gov ? nasa.gov ?

m@im

Although I don't think he's using it anymore (and I've not met him)

http://dk/

although your web browser or proxy is probably broken, and will need you to
write that as http://dk./

If you wish to parse e-mail addresses for validity, you could use the 8000
character regexp in Mastering Regular Expressions, although it won't cope
with nested comments, and won't actually tell you about non-existent domains.

Nicholas Clark

RE: [Nms-cgi-devel] Questions regarding email filter...

[Wizard <wi...@ne...>]

Just so that I'm explaining myself fully, this is for DENY/ALLOW filtering
for users to post to NMSBoard, i.e., to block users with specific emails
from posting messages.
Grant M.

RE: [Nms-cgi-devel] Questions regarding email filter...

[Wizard <wi...@ne...>]

> I would think that the only way to do it is to maintain a lookup of the
> "generic" second level domains under the ccTLDs. For instance:
>
> .co.uk is generic
> .bl.uk is not
>
> Wee, how about this one I just found...
>
> www.co.uk
>
> The only way you can tell them apart is to precode that metadata
> somewhere.
>
> I smell maintenance nightmare. Tell me again why you want to do this ? I
> still don't grok how this code is going to be used.

More or less it's just DWIM, where the user enters a glob-format string in
the config file to disallow emails that match that criteria. I didn't want
the user to have to understand how the system works in order to filter on
the entire domain, ie, "*@netgear.*" SHOULD filter out only netgear
accounts, but what about poor "fr...@ne..."?

I'm still going to spend a little time reading and see if I can come up with
at least a partial solution to this.

Grant M.

RE: [Nms-cgi-devel] Questions regarding email filter...

[Simon W. <es...@ou...>]

On Tue, 2003-02-11 at 16:23, Wizard wrote:
> > I don't think you can do this programatically. Strictly speaking, aol.*
> > should NOT match aol.co.uk. It;s only your semantic interpretation of
> > the data that "knows" that aol.co.uk and aol.com are the same
> > organisation.
> 
> Well I have some code now that will do just that, but not the last one
> because it doesn't fit the DOMAIN.TLD[.CC] format.
> 
> 
> > How do we know *programatically* that aol.parliament.uk is not part of
> > AOL ?
> 
> Presently we don't. I'll see what I can come up with for code later this
> evening. I have an interview right now.

I would think that the only way to do it is to maintain a lookup of the
"generic" second level domains under the ccTLDs. For instance:

.co.uk is generic
.bl.uk is not

Wee, how about this one I just found...

www.co.uk

The only way you can tell them apart is to precode that metadata
somewhere.

I smell maintenance nightmare. Tell me again why you want to do this ? I
still don't grok how this code is going to be used.

Simon.

RE: [Nms-cgi-devel] Questions regarding email filter...

[Wizard <wi...@ne...>]

> I don't think you can do this programatically. Strictly speaking, aol.*
> should NOT match aol.co.uk. It;s only your semantic interpretation of
> the data that "knows" that aol.co.uk and aol.com are the same
> organisation.

Well I have some code now that will do just that, but not the last one
because it doesn't fit the DOMAIN.TLD[.CC] format.


> How do we know *programatically* that aol.parliament.uk is not part of
> AOL ?

Presently we don't. I'll see what I can come up with for code later this
evening. I have an interview right now.
Thanks,
Grant M.

RE: [Nms-cgi-devel] Questions regarding email filter...

[Simon W. <es...@ou...>]

On Tue, 2003-02-11 at 16:09, Wizard wrote:
> > A little more context ? What are you trying to DO ?
> >
> > I probably don't understand the requirement but from what you're saying:
> >
> > An email address arrives from somewhere
> > It's checked for well-formedness
> > It's compared to a list of regexes of known banned addresses
> > It is accepted/rejected based on this
> 
> I want it to be universal. For instance, how would you parse this:
> *@*.aol.*
> 
> into:
> fr...@ao...
> fr...@ma...
> and
> fr...@mi...
> 
> It should match the first two, but not the last, because the DOMAIN in the
> last is 'parliment', not 'aol'.

I don't think you can do this programatically. Strictly speaking, aol.*
should NOT match aol.co.uk. It;s only your semantic interpretation of
the data that "knows" that aol.co.uk and aol.com are the same
organisation.

How do we know *programatically* that aol.parliament.uk is not part of
AOL ?

Simon.

RE: [Nms-cgi-devel] Questions regarding email filter...

[Wizard <wi...@ne...>]

> A little more context ? What are you trying to DO ?
>
> I probably don't understand the requirement but from what you're saying:
>
> An email address arrives from somewhere
> It's checked for well-formedness
> It's compared to a list of regexes of known banned addresses
> It is accepted/rejected based on this

I want it to be universal. For instance, how would you parse this:
*@*.aol.*

into:
fr...@ao...
fr...@ma...
and
fr...@mi...

It should match the first two, but not the last, because the DOMAIN in the
last is 'parliment', not 'aol'.

If you want code, let me know,
Grant M.

RE: [Nms-cgi-devel] Questions regarding email filter...

[Simon W. <es...@ou...>]

On Tue, 2003-02-11 at 15:45, Wizard wrote:
> > Can we turn it up the other way and ask what it is you are trying to
> > accomplish ?
> 
> Email/User filtering for NMSBoard posts, using filter sets like this:
> *@*.sf.net, *@*.aol.*, *@fred.bitchin.co.uk, etc.

A little more context ? What are you trying to DO ?

I probably don't understand the requirement but from what you're saying:

An email address arrives from somewhere
It's checked for well-formedness
It's compared to a list of regexes of known banned addresses
It is accepted/rejected based on this

Why do you want to be any more specific about the composition of the
address ?

Simon.

RE: [Nms-cgi-devel] Questions regarding email filter...

[Wizard <wi...@ne...>]

> That's the great thing about standards, there are so many to choose
> from.

I drive a Honda!

> > > Finland has no second level domain structure. e.g. www.genelec.fi is a
> > > valid domain.
> >
> > I never liked the Saab, either. Can't they do anything right ;-).
>
> That's OK. Saab isn't Finnish.

They never did look "Finnished". HAHAHAHAHAHA! What?

> Can we turn it up the other way and ask what it is you are trying to
> accomplish ?

Email/User filtering for NMSBoard posts, using filter sets like this:
*@*.sf.net, *@*.aol.*, *@fred.bitchin.co.uk, etc.

> whithouse.gov ? nasa.gov ?

Those are typical and fall into DOMAIN.TLD format. Same as .edu, .biz, .org.

Thanks,
Grant M.

RE: [Nms-cgi-devel] Questions regarding email filter...

[Simon W. <es...@ou...>]

On Tue, 2003-02-11 at 15:12, Wizard wrote:
> > in...@bl... is valid too. And what is a standard anyway ?
> 
> Standard (U.S.): A car with a manual-shift transmission.

That's the great thing about standards, there are so many to choose
from.

> > Finland has no second level domain structure. e.g. www.genelec.fi is a
> > valid domain.
> 
> I never liked the Saab, either. Can't they do anything right ;-).

That's OK. Saab isn't Finnish.

> > > 2.> Do email addresses ever have port numbers appended, like this:
> > > fr...@fs...:24
> > > ? Let me know.
> >
> > Not that I know of but there are a *lot* of ways of expressing comments
> > and so on in email addresses that you may need to take account of.
> 
> The question is 'Do I?', or can I just assume the most typical formats and
> ignore the rest (for blocking, anyway)? I can probably account for 99% of
> formats, and then do a final string_match for emails in the 'allow_user'
> configuration variable. Will this work?

Can we turn it up the other way and ask what it is you are trying to
accomplish ?

> > Do you mean .us domains of G-TLD's like .com and .org ?
> 
> The latter, as anything else should be handled by the international code.

whithouse.gov ? nasa.gov ?

Simon

RE: [Nms-cgi-devel] Questions regarding email filter...

[Wizard <wi...@ne...>]

> in...@bl... is valid too. And what is a standard anyway ?

Standard (U.S.): A car with a manual-shift transmission.

> Finland has no second level domain structure. e.g. www.genelec.fi is a
> valid domain.

I never liked the Saab, either. Can't they do anything right ;-).

> > 2.> Do email addresses ever have port numbers appended, like this:
> > fr...@fs...:24
> > ? Let me know.
>
> Not that I know of but there are a *lot* of ways of expressing comments
> and so on in email addresses that you may need to take account of.

The question is 'Do I?', or can I just assume the most typical formats and
ignore the rest (for blocking, anyway)? I can probably account for 99% of
formats, and then do a final string_match for emails in the 'allow_user'
configuration variable. Will this work?

> Do you mean .us domains of G-TLD's like .com and .org ?

The latter, as anything else should be handled by the international code.

Thanks,
Grant M.

Re: [Nms-cgi-devel] Questions regarding email filter...

[Simon W. <es...@ou...>]

On Tue, 2003-02-11 at 14:34, Wizard wrote:
> Ok, I have some minor issues with email filtering:
> 1.> These are all valid email address:
> Jer...@th...
> J.G...@us...
> Pau...@us...
> Ton...@pm... <- this is valid, but not standard

in...@bl... is valid too. And what is a standard anyway ?

> The problem is that last one with DOMAIN.CC format. Not having a TLD is NOT
> TYPICAL for UK domains (there are only 7), but are there other domains
> similar to this format? This is what I am expecting for international
> emails, and others will presently fail:
> USER_NAME[_W_DOTS*]@CNAMES*.DOMAIN.TLD.CC[:PORT?], an extreme being like
> this:
> ton...@do...:8021 where 'TLD' is required if
> 'CC' is present.
> Is this a problem?

Finland has no second level domain structure. e.g. www.genelec.fi is a
valid domain.
 
> 2.> Do email addresses ever have port numbers appended, like this:
> fr...@fs...:24
> ? Let me know.

Not that I know of but there are a *lot* of ways of expressing comments
and so on in email addresses that you may need to take account of.

> 3.> Are there any US domains that don't look like this:
>     CNAMES*.DOMAIN.TLD[:PORT?]

Do you mean .us domains of G-TLD's like .com and .org ?

Simon.

[Nms-cgi-devel] Questions regarding email filter...

[Wizard <wi...@ne...>]

Ok, I have some minor issues with email filtering:
1.> These are all valid email address:
Jer...@th...
J.G...@us...
Pau...@us...
Ton...@pm... <- this is valid, but not standard

The problem is that last one with DOMAIN.CC format. Not having a TLD is NOT
TYPICAL for UK domains (there are only 7), but are there other domains
similar to this format? This is what I am expecting for international
emails, and others will presently fail:
USER_NAME[_W_DOTS*]@CNAMES*.DOMAIN.TLD.CC[:PORT?], an extreme being like
this:
ton...@do...:8021 where 'TLD' is required if
'CC' is present.
Is this a problem?

2.> Do email addresses ever have port numbers appended, like this:
fr...@fs...:24
? Let me know.

3.> Are there any US domains that don't look like this:
    CNAMES*.DOMAIN.TLD[:PORT?]
Let me know,
Grant M.

RE: [Nms-cgi-devel] NMSBoard ideas

[Wizard <wi...@ne...>]

Just a note: the script you have is PRE-ALPHA, and is still being developed.
Also, some of my answers may seem discouraging, but most of the things that
you have suggested are good, and will likely make it in at some point.

> I downloaded the pre-alpha and got it running. I
> tried to post a message, but it didn't show up (no error
> message, everything seemed normal).

There is no posting ability yet. I hope to get something up this week. This
is still not a complete package, but is just there to try out. keep watching
and you should see something shortly.

> I see that in data.nml you store the <date>, but not time. I
> definitely want
> to show the time and date in my message index, and I believe that it may
> also be useful for other purposes to have the exact time of posting.

Actually, I'm planning on storing date AND time using the standard time
value of seconds since epoch (both in the <date> field). This will be
transformed into date and time strings when displayed. Post converted from
older wwwboard.html posts may only have the date string, but I may try to
work in the time as well, we'll see.

> 1. Allow users to easily change the "look" of the board (like
> fancy list in
> the pre-alpha, choose another CSS etc.)

You can do this already, but you'll have to have the templates/css/configs
already there. The fancy list is an example of that, using the same dataset
with different templates and settings. If you mean 'fully customizable' as
in the ability to create one's own templates and configurations, I don't
know that there is a truly safe way to do that. Templates are parsed, and
user configurations are VERY unsafe. If I can come up with a way, I can
pretty much guarantee that it won't be in the first version. When we have
user accounts/sessions, there will be more ability to customize views.

> 2. User profiles (See more about this in 19 below) : Name,
> e-mail, password,
> descriptive text, optional link (and description), optional image URL,
> optional graphic upload. This might require a config for the profile and
> graphic directories. Also allow the users to exclude old messages
> from their
> message listing (Only show the last three days, one week etc.).
> This setting
> should also be stored in the profile.

There may be some of this functionality, specifically the ability to filter
messages by date, but presently not stateful. Something like the user
profiles is planned for future revisions, but not the first one.

> 3. Only allow one profile per e-mail address. This has really cut down
> problems with posters on my current board.

With this version, you'll be able to block posting by IP block and email,
and you'll be able to moderate posts by email or 'all'. Moderated posts will
be recorded but not displayed until the admin says so.

> 4. User Preferences, allowing users to change the preferred order of
> messages in the message list etc.

This will be a sort feature in the 2nd release that will allow one to sort
based on date, user, and message size. This will likely be retained in a
cookie to reduce server space.

> 5. Easy changing of message list order (threaded, chronological or
> guestbook-style lists). The more flexibility and choices in this area the
> better.

There will be a 'guestbook-like' (sorry, Nick Clark ;-) feature where all
posts will be top-level in this first version, but it is configuration
based. When we get user accounts and sessions, we'll be able to do more of
this.

> 6. Mark new messages in message list since last visit (different color,
> icon... configurable)

You can simulate this now by setting the "a.visited {" value in the .css
file to a different color than the "a {" value. This won't quite accomplish
what you are asking, and I will consider it for a future version when we
implement some sort of stateful/session interface.

> 7. Allow users to mark all messages as read.

Again, this will have to wait until after we have some sort of session
cookie.

> 8. Easy use of smilies when writing messages (icons)

I saw this in another request, and it could be done with this version
without actually adding anything to the script. It would involve adding some
JavaScript buttons to the form template and creating the images, but it
shouldn't be too complicated. I'll see if I can add something to the
examples.

> 9. Allow easy formatting of message text (bold, italic, highlighted...)

More JavaScript stuff. I'll try to get to it, but we'll have to see.

> 10. Easy recovery of lost user passwords (e-mail to the address in the
> profile?). The most frequent problem my users have is losing/forgetting
> their password.

User Accounts aren't slated until the next release, but this won't be part
of it. Without incorporating multiple servers with GPG/PGP or something
similar, I don't believe that there is a safe way to store retrievable
passwords.

> 11. Search function

Should be in this version.

> 12. Paged message index with user selected timeframe for each page.
> (Requires page links similar to those in the advanced guestbook of the
> Tfmail script).

I'm not sure what this means, but I'll take a look at TFmail when I have a
chance.

> 13. Reply with or without quoting (different links/buttons). Both choices
> should be available when responding to a message.

I can add a 'clear form' button that will clear everything except the
Subject field. That should accomplish what you're asking.

> 14. Allow preview of messages before posting

It'll be in this version.

> 15. Automatically hotlink URLs and e-mail addresses (maybe configurable)

That's not a bad idea. I'll try to fit this into this version.

> 16. Allow users to delete their own messages. Maybe it would be
> easiest (and
> least confusing for the users) if a placeholder for the deleted message is
> shown in the message list if it had follow-up messages.

Perhaps next version. As stated earlier, we need a session/user accounts
first.

> 17 List of most active posters (top n list)

Again, we'll need User accounts first.

> 18. Admin module (Manage profiles, delete/modify messages, admin posts,
> archiving, rebuild database...)

There will be an admin module that does everything it needs to.

> 19. Allow the admin to limit posting to those who have a user
> profile. Also
> allow the admin to prevent certain users (e-mail addresses) from posting.

Emails and IPs can be blocked with this release.

> 20. Multiple message boards using only separate config files.

That's in this version. The two example boards supplied are just that, but
simply share the same data file.

> 21. Allow the admin to choose to have the post message form on the index
> page or on a separate page.

Good thought. That'll likely only be for the list views. The message views
will have a form, but I could put a 'no_form_on_thread' config variable.

> 22. Same as above for a post message form on individual message
> pages (like
> when reading a message).

I'm not sure there is a real need to have a separate form for individual
messages, but you could do this now by making the form template all hiddens
with a post button pointing to an (X)HTML form page with JavaScript to
fill-in the fields with the post values. I'll see what I can do as far as an
example.

> 23. Configure the message index to show if a message contains a
> picture or a
> link (separate icons, so a message with both a link and a picture would
> display both).

This may be in a future version. Advanced displays of lists/threads will
probably not occur until we have sessions, so that users can turn them on
and off.

> 24. Configure the message index to show how often each message
> has been read
> (This has proved to be very popular on my board).

I may be able to do this by incorporating the counter script into NMSBoard.
If I have the chance, I'll see.

> 25. View statistics (Number of posts per week...)

That's do-able, but we'll see if I have time.

> 26. As much flexibility as possible through CSS

That is pretty do-able with this version. I'm trying to avoid specifically
formatting any dynamically generated display items (no tables). Everything
should be within DIVs, SPANs, etc, with class= as needed. The rest is done
through templates.

> 27. Hooks for custom code (Before message is saved, before it is
> displayed... probably many other places). This would be _really_ nice.

I'll think about it for a later version.

Right now I'm just trying to finish a working, more flexible version of NMS
WWWBoard so that we have something to get some feedback on. Don't be
discouraged by my responses though, as this is, and will be a work in
progress. Once we have this version completed and released, we'll have a
base to add features to. We have tried to make it as generic as possible so
that any additions we make after the first release should be plug-in
replacements. In the event that I mess something up and we need to change
something that will not be backward-compatible, we will include scripts to
automate the upgrade.

Thanks for the feedback, and please continue to offer suggestions.
If I missed anything, let me know,
Grant M.

[Nms-cgi-devel] NMSBoard ideas

[Dadi J. <da...@si...>]

I really look forward to see the first official version of NMSBoard. I have
seen what you guys have done with Tfmail, so I have high hopes about this
new script. I downloaded the pre-alpha and got it running. I tried to post a
message, but it didn't show up (no error message, everything seemed normal).

I see that in data.nml you store the <date>, but not time. I definitely want
to show the time and date in my message index, and I believe that it may
also be useful for other purposes to have the exact time of posting.

I have been running a "threaded" message board for some years, and below I
have made a list of useful things to have in such a message board. Hopefully
you will put some of these on the "to-do" list for NMSBoard. I realize that
some of the items are already planned for NMSBoard.

I see that recently you have mostly been discussing the more technical
aspects of the script, but I hope that its not too early (and not too late!)
to suggest new ideas.

*Users*

1. Allow users to easily change the "look" of the board (like fancy list in
the pre-alpha, choose another CSS etc.)

2. User profiles (See more about this in 19 below) : Name, e-mail, password,
descriptive text, optional link (and description), optional image URL,
optional graphic upload. This might require a config for the profile and
graphic directories. Also allow the users to exclude old messages from their
message listing (Only show the last three days, one week etc.). This setting
should also be stored in the profile.

3. Only allow one profile per e-mail address. This has really cut down
problems with posters on my current board.

4. User Preferences, allowing users to change the preferred order of
messages in the message list etc.

5. Easy changing of message list order (threaded, chronological or
guestbook-style lists). The more flexibility and choices in this area the
better.

6. Mark new messages in message list since last visit (different color,
icon... configurable)

7. Allow users to mark all messages as read.

8. Easy use of smilies when writing messages (icons)

9. Allow easy formatting of message text (bold, italic, highlighted...)

10. Easy recovery of lost user passwords (e-mail to the address in the
profile?). The most frequent problem my users have is losing/forgetting
their password.

11. Search function

12. Paged message index with user selected timeframe for each page.
(Requires page links similar to those in the advanced guestbook of the
Tfmail script).

13. Reply with or without quoting (different links/buttons). Both choices
should be available when responding to a message.

14. Allow preview of messages before posting

15. Automatically hotlink URLs and e-mail addresses (maybe configurable)

16. Allow users to delete their own messages. Maybe it would be easiest (and
least confusing for the users) if a placeholder for the deleted message is
shown in the message list if it had followup messages.

17 List of most active posters (top n list)

*Administration*

18. Admin module (Manage profiles, delete/modify messages, admin posts,
archiving, rebuild database...)

19. Allow the admin to limit posting to those who have a user profile. Also
allow the admin to prevent certain users (e-mail addresses) from posting.

20. Multiple message boards using only separate config files.

21. Allow the admin to choose to have the post message form on the index
page or on a separate page.

22. Same as above for a post message form on individual message pages (like
when reading a message).

23. Configure the message index to show if a message contains a picture or a
link (separate icons, so a message with both a link and a picture would
display both).

24. Configure the message index to show how often each message has been read
(This has proved to be very popular on my board).

25. View statistics (Number of posts per week...)

26. As much flexibility as possible through CSS

*Script modifications*

27. Hooks for custom code (Before message is saved, before it is
displayed... probably many other places). This would be _really_ nice.

[Nms-cgi-devel] Fwd: [Nms-cgi-support] Formmail and GnuPG?

[webmaster <web...@b4...>]

Hello All,

Here is a suggestion from the support list
which I thought sounded like a good idea.

Is this a possibility?
Thank you
Bill W


>X-NMS-Sendmail: v1.5
>X-HTTP-Referer: [http://nms-cgi.sourceforge.net/support.html]
>X-HTTP-Client: [195.92.168.166]
>X-Mailer: NMS FormMail.pl (FormMail.pl) v2.12[http://nms-cgi.sourceforge.net/]
>To: nms...@li...
>From: ben...@ho... (Ben Pollinger)
>Subject: [Nms-cgi-support] Formmail and GnuPG?
>Sender: nms...@li...
>Below is the result of your feedback form.  It was submitted by
>Ben Pollinger (ben...@ho...) on Thursday, February 06, 2003 
>at 23:01:03
>---------------------------------------------------------------------------
>description: Not a problem - a suggestion.
>
>I like the formmail script, as it is solid and secure.
>I like GnuPG because it secures communications between machines.
>I would love to join them up, encrypting the output of formmail with
>GnuPG, before it is sent to me via my form.
>I know nearly nothing about Perl, PHP, or anything really.
>I found this - http://gnupg-interface.sourceforge.net/
>It looks useful, but see the above statement.
>
>Can this be done? I'm sure many people would use it, cos the other
>options don't really appeal.
>
>cheers,
>Ben
>--
>www.psyclick.org.uk
>
>---------------------------------------------------------------------------
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com

[Nms-cgi-devel] Fwd: [Nms-cgi-support] Formmail and GnuPG?

[BillW <bi...@b4...>]

Hello All,

Here is a suggestion from the support list
which I thought sounded like a good idea.

Is this a possibility?
Thank you
Bill W


>X-NMS-Sendmail: v1.5
>X-HTTP-Referer: [http://nms-cgi.sourceforge.net/support.html]
>X-HTTP-Client: [195.92.168.166]
>X-Mailer: NMS FormMail.pl (FormMail.pl) v2.12[http://nms-cgi.sourceforge.net/]
>To: nms...@li...
>From: ben...@ho... (Ben Pollinger)
>Subject: [Nms-cgi-support] Formmail and GnuPG?
>Sender: nms...@li...
>Below is the result of your feedback form.  It was submitted by
>Ben Pollinger (ben...@ho...) on Thursday, February 06, 2003 
>at 23:01:03
>---------------------------------------------------------------------------
>description: Not a problem - a suggestion.
>
>I like the formmail script, as it is solid and secure.
>I like GnuPG because it secures communications between machines.
>I would love to join them up, encrypting the output of formmail with
>GnuPG, before it is sent to me via my form.
>I know nearly nothing about Perl, PHP, or anything really.
>I found this - http://gnupg-interface.sourceforge.net/
>It looks useful, but see the above statement.
>
>Can this be done? I'm sure many people would use it, cos the other
>options don't really appeal.
>
>cheers,
>Ben
>--
>www.psyclick.org.uk
>
>---------------------------------------------------------------------------
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com

RE: [Nms-cgi-devel] Re: NMSTreq and other modules...

[Wizard <wi...@ne...>]

> I would just copy and paste for now, see what you end up with.
Yeah, after looking at it, I realized it really isn't what I'll need, but
I'll likely use some of it.
Thanks,
Grant M.

RE: [Nms-cgi-devel] NMSBoard data format question...

[Wizard <wi...@ne...>]

> If it's not really XML, it shouldn't have a dtd IMO.

Technically speaking, the only reason that we aren't calling it XML is
because we're not parsing it as XML. The file itself is valid XML.

> If we want to avoid confusion with XML, how about just avoiding
> anglebrackets, e.g. use "[foo]bah[/foo]" instead of the XML like
> "<foo>bar</foo>".

The primary reason I proposed this was in response to Simon's issue of
someone munging the file with an XML editor. If someone wants to edit the
data file directly, I don't believe the tag format that we use will be
either a deterrent or an incentive. It was just a suggestion. I just felt
that by providing a DTD, we can control how their XML editor will edit it.
Thanks,
Grant M.