qmailadmin-devel — List to discuss future development of QmailAdmin

Re: [qmailadmin-devel] Updated vpopmail (5.3.21)

[Tom C. <to...@to...>]

On Saturday, July 19, 2003, at 01:09  AM, spork wrote:
> If anyone is interested, here's some of the errors appearing, this is 
> on
> FreeBSD 4.8:
>
> ----
> gcc -I. -I/usr/local/include/mysql     -g -O2 -Wall -c maildirquota.c
> maildirquota.c: In function `readuserquota':
> maildirquota.c:188: warning: passing arg 3 of `countcurnew' from
> incompatible pointer type
> maildirquota.c:196: warning: passing arg 4 of `countsubdir' from
> incompatible pointer type

Brian Kolaci's code in maildirquota.c uses an unsigned long in 
instances when it should be off_t.  I doubt off_t is the same as 
unsigned long on most platforms, since off_t would typically be signed. 
  I think that readdomainquota and readuserquota should be altered to 
use off_t * instead of long * for the sizep parameter.  I don't know if 
that would impact other code though.

I'm cc'ing Brian on this email -- perhaps he can look into it further, 
or let me know if anything outside of maildirquota makes use of 
readdomainquota() or readuserquota().

> ----
> gcc -I. -I/usr/local/include/mysql     -g -O2 -Wall -c vpasswd.c
> vpasswd.c: In function `get_options':
> vpasswd.c:80: warning: unused variable `optarg'

Removed unused variable optarg.

> ----
> gcc -I. -I/usr/local/include/mysql     -g -O2 -Wall -c vdeloldusers.c
> vdeloldusers.c: In function `main':
> vdeloldusers.c:87: warning: control reaches end of non-void function

Main ends with vexit which ultimately calls exit.  It looks like other 
programs do "return(vexit(0));" to avoid this warning, so I've matched 
that practice in vdeloldusers.

> ----
> gcc -I. -I/usr/local/include/mysql     -g -O2 -Wall -c vdominfo.c
> vdominfo.c: In function `get_options':
> vdominfo.c:85: warning: unused variable `optarg'

Removed unused variable optarg.

> ----
> gcc -I. -I/usr/local/include/mysql     -g -O2 -Wall -c vkill.c
> vkill.c: In function `get_options':
> vkill.c:52: warning: unused variable `optarg'
> ----

Removed unused variable optarg.

--
Tom Collins
to...@to...
http://sniffter.com/ - info on the Sniffter hand-held Network Tester

Re: [qmailadmin-devel] FW: SpamAssassin web-control interface - proposed project.

[spork <sp...@fa...>]

On Tue, 22 Jul 2003, Gerald Villemure wrote:

> To add a third level:
>
> 3. System wide level security where the "admin" can create new domains
> etc.
>
> May require qmailadmin to run SETUID as **ROOT**

No, just some creative chmod'ing of some qmail files, and a cron job to
look for changes and "svc -t /service/qmail-send" if something has
changed.  No need for the big hammer...

Charles

> I am not sure about this but the inter7 web site seems to imply this.
>
> I for one have the creation and removal of domains completely automated
> with shell scripts so I don't use vqadmin.
>
> G=E9rald
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> qmailadmin-devel mailing list
> qma...@li...
> https://lists.sourceforge.net/lists/listinfo/qmailadmin-devel
>

Re: [qmailadmin-devel] FW: SpamAssassin web-control interface - proposed project.

[Gerald V. <GVi...@ik...>]

----- Original Message ----- 
From: "Scott Davis" <SD...@Es...>

> Once again, to everyone:  I think I'm suggesting that we "bundle" a
> bunch of administrivia into QmailAdmin.  If you can please give me
> feedback - regarding if you think that's appropriate or not, I'd
> appreciate it!

Qmailadmin has 2 levels of security.  At least it seems to me.

1. Domain level security where the user can edit all accounts for a
domain.
2. User level security where the user can only edit his own setting.

Both require qmailadmin to run SETUID as vpopmail.

To add a third level:

3. System wide level security where the "admin" can create new domains
etc.

May require qmailadmin to run SETUID as **ROOT**

I am not sure about this but the inter7 web site seems to imply this.

I for one have the creation and removal of domains completely automated
with shell scripts so I don't use vqadmin.

Gérald

Re: [qmailadmin-devel] Template mailfilter

[Jeff H. <jef...@ma...>]

Gerald Villemure wrote:
> That's a very interesting way to go about it.  I see what you mean, tag
> the spam yes/no and if you want it sorted into a bulk folder then its up
> to you to create your own sorting rules.

Just to clear this up:  If you want it sorted into a Bulk folder, all 
the user has to do is create that Bulk folder.

Only if they want to sort with their own method (into a different folder 
or something), only then would they have to be able to create their own 
sorting rules (for spam).

> Well you got me convinced, the only problem is that I don't use
> SquirrelMail.  I use IMP so the users are not able to create maildrop
> filters.
> 
> Should I just have a parallel install of SquirrelMail or will future
> versions of qmailadmin allow users the ablility to create/edit maildrop
> filters?

I don't know if SquirrelMail allows the editing of Maildrop filters 
either.  I am still exploring that solution.

Oh, I just realized you are probably talking about sqwebmail (something 
different than SquirrelMail).

I am hoping that we can include a module to edit maildrop filters within 
qmailadmin at some point.

Jeff

Re: [qmailadmin-devel] Template mailfilter

[Jeff H. <jef...@ma...>]

spork wrote:
> On Tue, 22 Jul 2003, Gerald Villemure wrote:
> 
> 
>>Should I just have a parallel install of SquirrelMail or will future
>>versions of qmailadmin allow users the ablility to create/edit maildrop
>>filters?
> 
> 
> This harkens back to an earlier post about "packaging", but assuming
> qmailadmin was built with the assumption you would use maildrop, an easy
> fix until such time someone builds a mailfilter editing tool (blech) would
> be to have several maildrop config files packaged with qmailadmin.  ie:
> one filter simply calls SA and tags the message in the subject line,
> another dumps the tagged spam into a spambox, another throws away the
> filtered mail.
> 
> The "enable spam filtering" checkbox could become three checkboxes, and
> depending on which is checked, the user's .qmail file would contain a
> pointer to the appropriate maildrop config, like "|preline
> /usr/local/bin/maildrop
> /home/vpopmail/etc/maildroprc.tag||maildroprc.spambox||maildroprc.discard".

We're beginning to talk in circles.

Gerald proposed this method you describe, I responded showing the way I do it that doesn't require having three buttons.

Jeff

RE: [qmailadmin-devel] FW: SpamAssassin web-control interface - proposed project.

[spork <sp...@fa...>]

On Mon, 21 Jul 2003, Benjamin Tomhave wrote:

> Ummmm....not to point out the obvious, but I know there's already a
> comprehensive PHP-based SA configuration interface out there on the 'net.  I
> believe it's called "phpsa" though I've not found the link (yet).  I will
> pass along the link when I find it.

The link is down at the bottom of this page:

http://www.spamassassin.org/dist/sql/README

It's basic, but it works well.  Allows a user to make white/blacklists and
set their threshold.  Something like this would also probably be fairly
easy to hack into a squirrelmail module.  Once the user is auth'd, it's
just a matter of updating fields in an sql table where
"username='$logged_in_user'".

Charles

>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> qmailadmin-devel mailing list
> qma...@li...
> https://lists.sourceforge.net/lists/listinfo/qmailadmin-devel
>

Re: [qmailadmin-devel] Template mailfilter

[spork <sp...@fa...>]

On Tue, 22 Jul 2003, Gerald Villemure wrote:

> Should I just have a parallel install of SquirrelMail or will future
> versions of qmailadmin allow users the ablility to create/edit maildrop
> filters?

This harkens back to an earlier post about "packaging", but assuming
qmailadmin was built with the assumption you would use maildrop, an easy
fix until such time someone builds a mailfilter editing tool (blech) would
be to have several maildrop config files packaged with qmailadmin.  ie:
one filter simply calls SA and tags the message in the subject line,
another dumps the tagged spam into a spambox, another throws away the
filtered mail.

The "enable spam filtering" checkbox could become three checkboxes, and
depending on which is checked, the user's .qmail file would contain a
pointer to the appropriate maildrop config, like "|preline
/usr/local/bin/maildrop
/home/vpopmail/etc/maildroprc.tag||maildroprc.spambox||maildroprc.discard".

Charles

> G=E9rald
>
>
> ----- Original Message -----
> From: "Jeff Hedlund" <jef...@ma...>
> To: <qma...@li...>
> Sent: Monday, July 21, 2003 5:57 PM
> Subject: Re: [qmailadmin-devel] Template mailfilter
>
>
> >
> >
> > Gerald Villemure wrote:
> > > In order the use the filter you need to have one of these in your
> .qmail:
> > >
> > > |preline -f maildrop -w 90 /etc/mailfilter
> > > |preline -f maildrop -w 90 /etc/mailfilter TAG
> > > |preline -f maildrop -w 90 /etc/mailfilter SORT
> > > |preline -f maildrop -w 90 /etc/mailfilter DROP
> > >
> > > I am hoping that future version of qmailadmin will have
> > > an admin screen that looks like this:
> > >
> > > Spam filter setup:
> > > Email_Account   Nothing   Tag_only  Filter  Delete    Configuer
> > > bob                      O            O            X       O
> [config]
> > > dave                     O            X            O       O
> [config]
> > > dale                      O            O            O       X
> [config]
> >
> > Just wanted to make a few comments on this design.  There's been
> > discussion in the past about letting users just delete spam (mainly
> due
> > to the fact that non-spam messages can be lost).  I would feel nervous
> > having a Delete configuration option-- so as long as it was
> configurable
> > to turn off that option (system-wide), I'd be happy.
> >
> > As far as the Nothing, Tag_only, and Filter options -- those are sort
> of
> > built into my mailfilter already.  Obviosly, the Nothing and Tag_only
> > are already present by checking or unchecking the Detect Spam box.
> >
> > For filtering, I let my users know that they can create a "Bulk" mail
> > folder that automatically filters Spam into that folder (I explain how
> > to create this folder for IMAP users and for POP users, POP users use
> > the web-based e-mail to create the folder and check the folder
> > occasionally).
> >
> > If they don't want spam to be filtered into that folder, they can
> create
> > their own rules to filter spam (as long as they have not created that
> > Bulk folder).
> >
> > As for the "Delete" option, I warn users that by creating a Bulk mail
> > folder that mail in that folder will automatically be removed if older
> > than two weeks.  I decided to do that to help control the size of the
> > Bulk mail folder.
> >
> > If a user really doesn't care to go through the spam, they can just
> > ignore the spam folder and it automatically takes care of itself.
> >
> > In summary, I feel that the Nothing, Tag only, and Filter are one in
> the
> > same and that the delete option shouldn't exist.
> >
> > Jeff
> >
> > PS - I use courier-imap to control the expiration of the mail in the
> > spam folder.
> > --
> >
> >    /\  /\              ..    ..    ..    jef...@ma...
> >   /  \/  \ a t r i x  .  .  .  .  .  .  .           (770) 794-7233
> >   s o f t w a r e  i n c  ..    ..    ..   http://www.matrixsi.com
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> qmailadmin-devel mailing list
> qma...@li...
> https://lists.sourceforge.net/lists/listinfo/qmailadmin-devel
>

Re: [qmailadmin-devel] Template mailfilter

[Gerald V. <GVi...@ik...>]

That's a very interesting way to go about it.  I see what you mean, tag
the spam yes/no and if you want it sorted into a bulk folder then its up
to you to create your own sorting rules.

Well you got me convinced, the only problem is that I don't use
SquirrelMail.  I use IMP so the users are not able to create maildrop
filters.

Should I just have a parallel install of SquirrelMail or will future
versions of qmailadmin allow users the ablility to create/edit maildrop
filters?

Gérald


----- Original Message ----- 
From: "Jeff Hedlund" <jef...@ma...>
To: <qma...@li...>
Sent: Monday, July 21, 2003 5:57 PM
Subject: Re: [qmailadmin-devel] Template mailfilter


>
>
> Gerald Villemure wrote:
> > In order the use the filter you need to have one of these in your
.qmail:
> >
> > |preline -f maildrop -w 90 /etc/mailfilter
> > |preline -f maildrop -w 90 /etc/mailfilter TAG
> > |preline -f maildrop -w 90 /etc/mailfilter SORT
> > |preline -f maildrop -w 90 /etc/mailfilter DROP
> >
> > I am hoping that future version of qmailadmin will have
> > an admin screen that looks like this:
> >
> > Spam filter setup:
> > Email_Account   Nothing   Tag_only  Filter  Delete    Configuer
> > bob                      O            O            X       O
[config]
> > dave                     O            X            O       O
[config]
> > dale                      O            O            O       X
[config]
>
> Just wanted to make a few comments on this design.  There's been
> discussion in the past about letting users just delete spam (mainly
due
> to the fact that non-spam messages can be lost).  I would feel nervous
> having a Delete configuration option-- so as long as it was
configurable
> to turn off that option (system-wide), I'd be happy.
>
> As far as the Nothing, Tag_only, and Filter options -- those are sort
of
> built into my mailfilter already.  Obviosly, the Nothing and Tag_only
> are already present by checking or unchecking the Detect Spam box.
>
> For filtering, I let my users know that they can create a "Bulk" mail
> folder that automatically filters Spam into that folder (I explain how
> to create this folder for IMAP users and for POP users, POP users use
> the web-based e-mail to create the folder and check the folder
> occasionally).
>
> If they don't want spam to be filtered into that folder, they can
create
> their own rules to filter spam (as long as they have not created that
> Bulk folder).
>
> As for the "Delete" option, I warn users that by creating a Bulk mail
> folder that mail in that folder will automatically be removed if older
> than two weeks.  I decided to do that to help control the size of the
> Bulk mail folder.
>
> If a user really doesn't care to go through the spam, they can just
> ignore the spam folder and it automatically takes care of itself.
>
> In summary, I feel that the Nothing, Tag only, and Filter are one in
the
> same and that the delete option shouldn't exist.
>
> Jeff
>
> PS - I use courier-imap to control the expiration of the mail in the
> spam folder.
> -- 
>
>    /\  /\              ..    ..    ..    jef...@ma...
>   /  \/  \ a t r i x  .  .  .  .  .  .  .           (770) 794-7233
>   s o f t w a r e  i n c  ..    ..    ..   http://www.matrixsi.com

Re: [qmailadmin-devel] Should QmailAdmin be rewritten in PHP?

[Gerald V. <GVi...@ik...>]

----- Original Message ----- 
From: "Benjamin Tomhave" <in...@so...>


> What about a hybrid?  Core functions in C-based CGIs and then the
actual UI
> written in PHP.  Essentially this would be akin to writing a C-based
CGI API
> that is then accessible via whatever interface people want.

A hybrid could work.  Or at least some for of SETUID wraper to get
around the permission problems.

Gerald

Re: [qmailadmin-devel] Should QmailAdmin be rewritten in PHP?

[spork <sp...@fa...>]

On Mon, 21 Jul 2003, Jeff Hedlund wrote:

> If we did want to go with PHP at some point, there may be other options..

One would be simple wrappers to the vpopmail command-line tools.  Make the
vpopmail bins setuid vpopmail, executable by the group your vpopmail
server runs as, and not executable by any other uid.  Ditto on the files
that php would have to directly manipulate.

Charles

> Jeff
> --
>
>    /\  /\              ..    ..    ..    jef...@ma...
>   /  \/  \ a t r i x  .  .  .  .  .  .  .           (770) 794-7233
>   s o f t w a r e  i n c  ..    ..    ..   http://www.matrixsi.com
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> qmailadmin-devel mailing list
> qma...@li...
> https://lists.sourceforge.net/lists/listinfo/qmailadmin-devel
>

RE: [qmailadmin-devel] ACL thoughts

[spork <sp...@fa...>]

On Mon, 21 Jul 2003, Benjamin Tomhave wrote:

> This sounds reasonable.  Should be easy enough to wrap SSL around it if
> necessary.  Allowing URL parms to directly access all pages and actions from
> a single URL would somewhat negate my request for PHP conversion, though I
> still think the flexibility from a PHP-based install would be hugely useful
> and important.

Not to mention that if we went with PHP, there would be a much larger
base of developers to work on it.  C requires that a good deal of your
work is just dirty grunt work; a higher level language would make many of
the things people want rolled into qmailadmin much easier to do.  As I see
it, all of these inter7 tools are a good start, but there's still much
work to do to make them "right".  I'm no pro with php, but building
something like vqadmin in php would be very easy; most of the work would
be the logic behind it, not the implementation...

Just my $0.02.

Charles

>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> qmailadmin-devel mailing list
> qma...@li...
> https://lists.sourceforge.net/lists/listinfo/qmailadmin-devel
>

RE: [qmailadmin-devel] FW: SpamAssassin web-control interface - proposed project.

[Benjamin T. <in...@so...>]

> 1)  Tackle 'bundling' a SA-userPref "page" into my existing QmailAdmin
> setup.
>
Could be done very similar to how the help files are referenced now.

> 2)  Ignore all of my 'bundling' dreams.  Heck, I don't have the skill to
> build it "all" yet.  It seems that most people don't want a totally
> integrated package also.  I can respect that, though I don't really
> understand it.
>
If you approach things from a modular perspective, then it should be easy to
add it as a "plugin" to qmailadmin in the future.

> 3)  When I'm done with my PHP SA-config "pages", I'll make them
> available for everyone to review.  As I'm not much of a programmer, I
> suspect this will take me several days - if not longer.
>
Ummmm....not to point out the obvious, but I know there's already a
comprehensive PHP-based SA configuration interface out there on the 'net.  I
believe it's called "phpsa" though I've not found the link (yet).  I will
pass along the link when I find it.

Re: [qmailadmin-devel] Should QmailAdmin be rewritten in PHP?

[<dor...@x3...>]

Hi Jeff,

> This has been removed from PHP as of 4.3.0 (as the site mentions).  And=

> the PEAR add-on doesn't appear to exist.
>=20
> So it would appear there is no good support for the library at this poi=
nt.

oh, sorry I haven't saw that... :-(

> Or maybe it's being developed elsewhere?

Anyway I sent a mail to James Cox (current vpopmail pear package leader)
asking project status informations...

> If we did want to go with PHP at some point, there may be other options=
=2E.

Hey, I don't say I prefer PHP, just started enumerate pros/cons.

I like both, but really love python... hehehe ;-)

Kindly regards,

--=20

Dorneles Trem=E9a
Caxias do Sul - RS - Brasil
+55 54 9114 9312 - UIN: 2413568
X3ng Web Technology <http://www.x3ng.com.br>

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/IT d- s:->: a24 C+++ UBL++++$ P--- L++ E-- W+++
N++ o? K? w+ O M+ V-- PS+ PE- Y-- PGP++ t+ 5 X++ R+
tv+ b(++) DI+ D++ G+>+++ e++>++++ h---- r+++ y+++**
------END GEEK CODE BLOCK------

RE: [qmailadmin-devel] Should QmailAdmin be rewritten in PHP?

[Benjamin T. <in...@so...>]

> PHP may arguably easier to develop with.  However, when dealing with an
> embedded scripting language rather than CGI, you have to deal with
> apache permissions, whereas the qmailadmin cgi is setuid.  Many of us
> use qmailadmin along with standard web serving for our customers.
>
What about a hybrid?  Core functions in C-based CGIs and then the actual UI
written in PHP.  Essentially this would be akin to writing a C-based CGI API
that is then accessible via whatever interface people want.

RE: [qmailadmin-devel] Should QmailAdmin be rewritten in PHP?

[Benjamin T. <in...@so...>]

> The difference is almost insignificant, I guess. The PHP core
> is also native C...
>
The difference in performance, negligible.  The difference in ease of
integrating with other/existing web sites, major.

> > I suspect that it would be easier to configure and install though.
>
> Here it can be A LOT easier... ;-)
>
Easier to configure, install, extend, modify, etc.  An integrators dream! :)

> Pros:
>  - Easier instalation
>  - (add your toughts here)
>
-easier integration with existing web sites
-more extensible and configurable (for example, these various looks would be
very straight-forward)

> Cons:
>  - Rewrite everything from scratch
>  - Learn a new programming language (or no...)
>  - (add your toughts here too)
>
The above.  The big one would be completely re-doing the architecture of
qmailadmin.  While this may not be a bad thing, it would probably be a lot
of work.  On the flip side, the benefits may far outweight the costs, but
it's hard to say.

Integration issues aside, if the HTML becomes much easier to customize and
users can feel like they're SSO for webmail, qmailadmin and their ISP
accounts (for payments, etc.) and that's accomplished through URL parms vs
PHP, that's cool.  My big thing here is trying to present a single interface
to all my customers that allows them to self-service their accounts as much
as possible.

Re: [qmailadmin-devel] Should QmailAdmin be rewritten in PHP?

[Chris H. <cha...@ch...>]

I wouldn't mind seeing a split off of the branch. Like using the C =
program and PHP program. But you don't have much time and it would be =
time consuming to devlope 2 things for the same functionality.

Chris
  ----- Original Message -----=20
  From: Tom Collins=20
  To: qma...@li...=20
  Sent: Monday, July 21, 2003 12:45
  Subject: [qmailadmin-devel] Should QmailAdmin be rewritten in PHP?


  This is a big question, that's for sure.

  I'm not a PHP programmer. I don't know what it's capable of, or what =
its benefits are over using a compiled CGI. I don't know if it can =
interface with the vpopmail library. I don't know if it will run slower, =
or use more resources than a compiled C program. I suspect that it would =
be easier to configure and install though.

  What are the benefits to switching to PHP? Are there things we can do =
in the existing code to gain some of those benefits?

  Jeff Hedlund emailed me off-list about a very cool tool called =
Flate[1], for managing HTML templates used by C programs. If we stay =
with C, then I'd definitely want to convert over to Flate (or adapt some =
of its methods) as one of our first goals, and then work on supporting =
multiple templates -- classic QmailAdmin, the new interface making the =
rounds, and maybe even a new one that uses CSS, minimal graphics, and =
has a menu on-screen at all times.

  [1] http://freshmeat.net/projects/flate/?topic_id=3D96

  --
  Tom Collins
  to...@to...
  http://sniffter.com/ - info on the Sniffter hand-held Network Tester

Re: [qmailadmin-devel] Should QmailAdmin be rewritten in PHP?

[Bill S. <hos...@sh...>]

On Monday, July 21, 2003, at 01:40  PM, Bill Shupp wrote:

> I personally prefer to stick with CGI.

Uh, to be clearer, C.

Bill

Re: [qmailadmin-devel] Should QmailAdmin be rewritten in PHP?

[Bill S. <hos...@sh...>]

On Monday, July 21, 2003, at 10:45  AM, Tom Collins wrote:

> This is a big question, that's for sure.
>
> I'm not a PHP programmer.  I don't know what it's capable of, or what 
> its benefits are over using a compiled CGI.  I don't know if it can 
> interface with the vpopmail library.  I don't know if it will run 
> slower, or use more resources than a compiled C program.  I suspect 
> that it would be easier to configure and install though.
>
> What are the benefits to switching to PHP?  Are there things we can do 
> in the existing code to gain some of those benefits?

PHP may arguably easier to develop with.  However, when dealing with an 
embedded scripting language rather than CGI, you have to deal with 
apache permissions, whereas the qmailadmin cgi is setuid.  Many of us 
use qmailadmin along with standard web serving for our customers.

I personally prefer to stick with CGI.

> Jeff Hedlund emailed me off-list about a very cool tool called 
> Flate[1], for managing HTML templates used by C programs.  If we stay 
> with C, then I'd definitely want to convert over to Flate (or adapt 
> some of its methods) as one of our first goals, and then work on 
> supporting multiple templates -- classic QmailAdmin, the new interface 
> making the rounds, and maybe even a new one that uses CSS, minimal 
> graphics, and has a menu on-screen at all times.

This sounds good to me.  I've found the existing template structure not 
terribly intuitive.

Regards,

Bill

Re: [qmailadmin-devel] Should QmailAdmin be rewritten in PHP?

[Jeff H. <jef...@ma...>]

Dorneles Treméa wrote:
> [PHP vpopmail library interface] 
> [1] http://www.php.net/manual/en/ref.vpopmail.php

This has been removed from PHP as of 4.3.0 (as the site mentions).  And 
the PEAR add-on doesn't appear to exist.

So it would appear there is no good support for the library at this point.

Or maybe it's being developed elsewhere?

If we did want to go with PHP at some point, there may be other options..

Jeff
-- 

   /\  /\              ..    ..    ..    jef...@ma...
  /  \/  \ a t r i x  .  .  .  .  .  .  .           (770) 794-7233
  s o f t w a r e  i n c  ..    ..    ..   http://www.matrixsi.com

RE: [qmailadmin-devel] FW: SpamAssassin web-control interface - proposed project.

[Scott D. <SD...@Es...>]

Tom, Thanks for stating your opinion.

Bill - and the rest of you.  Sorry for the double-postings.  Apparently
my Microsoft "lookout" was incorrectly reporting that "sent items" were
not sent, when they really were.  You shouldn't see any more dupes.
Sorry for the inconvenience.


Okay, folks.  

Here's what I'm thinking I'm going to do..  

1)  Tackle 'bundling' a SA-userPref "page" into my existing QmailAdmin
setup.  

2)  Ignore all of my 'bundling' dreams.  Heck, I don't have the skill to
build it "all" yet.  It seems that most people don't want a totally
integrated package also.  I can respect that, though I don't really
understand it.

3)  When I'm done with my PHP SA-config "pages", I'll make them
available for everyone to review.  As I'm not much of a programmer, I
suspect this will take me several days - if not longer.


Thank you all VERY much for your feedback.  

Take Care.

-- Scott.





> -----Original Message-----
> From: qma...@li... [mailto:qmailadmin-
> dev...@li...] On Behalf Of Tom Collins
> Sent: Monday, July 21, 2003 1:31 PM
> To: qma...@li...
> Subject: Re: [qmailadmin-devel] FW: SpamAssassin web-control interface
-
> proposed project.
> 
> On Monday, July 21, 2003, at 07:00  AM, Benjamin Tomhave wrote:
> > As for the assumption that user's must be able to administer their
spam
> > settings through qmailadmin, this is not universally true, either.
I'm
> > providing spam-filtering on a per-domain basis and then have
provided a
> > simple PHP-based plugin in my webmail (SquirrelMail) for users to
> > whitelist,
> > blacklist, and modify their required_hits setting.
> 
> I'm more than happy to work out a way to interface to existing
> solutions for editing SpamAssassin prefs, even to the point of
> including the latest version of a selected Open Source solution with
> every QmailAdmin release.
> 
> As mentioned in my other email, we do not need to reinvent the wheel.
> We do not need to bundle everything into QmailAdmin.  Modularity is
> king.
> 
> --
> Tom Collins
> to...@to...
> http://sniffter.com/ - info on the Sniffter hand-held Network Tester
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single
machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at
the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> qmailadmin-devel mailing list
> qma...@li...
> https://lists.sourceforge.net/lists/listinfo/qmailadmin-devel

Re: [qmailadmin-devel] Should QmailAdmin be rewritten in PHP?

[<dor...@x3...>]

Hi Tom,

> I'm not a PHP programmer. I don't know what it's capable of,
> or what its benefits are over using a compiled CGI. I don't know
> if it can interface with the vpopmail library.

yes, it can and it's well documented[1]... :-)

> I don't know if it will run slower, or use more resources than
> a compiled C program.

The difference is almost insignificant, I guess. The PHP core
is also native C...

> I suspect that it would be easier to configure and install though.

Here it can be A LOT easier... ;-)

> What are the benefits to switching to PHP? Are there things we=20
> can do in the existing code to gain some of those benefits?

Pros:
 - Easier instalation
 - (add your toughts here)

Cons:
 - Rewrite everything from scratch
 - Learn a new programming language (or no...)
 - (add your toughts here too)

> Jeff Hedlund emailed me off-list about a very cool tool called Flate[1]=
,
> for managing HTML templates used by C programs. If we stay with C, then=

> I'd definitely want to convert over to Flate (or adapt some of its
> methods) as one of our first goals, and then work on supporting multipl=
e
> templates -- classic QmailAdmin, the new interface making the rounds,
> and maybe even a new one that uses CSS, minimal graphics, and has a men=
u
> on-screen at all times.

Hum, I need to take a look at this later...

[1] http://www.php.net/manual/en/ref.vpopmail.php

Regards,

--=20

Dorneles Trem=E9a
Caxias do Sul - RS - Brasil
+55 54 9114 9312 - UIN: 2413568
X3ng Web Technology <http://www.x3ng.com.br>

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/IT d- s:->: a24 C+++ UBL++++$ P--- L++ E-- W+++
N++ o? K? w+ O M+ V-- PS+ PE- Y-- PGP++ t+ 5 X++ R+
tv+ b(++) DI+ D++ G+>+++ e++>++++ h---- r+++ y+++**
------END GEEK CODE BLOCK------

RE: [qmailadmin-devel] FW: SpamAssassin web-control interface - proposed project.

[Benjamin T. <in...@so...>]

> On Monday, July 21, 2003, at 07:01  AM, Benjamin Tomhave wrote:
> >> ...I think this kind of stuff is a job to vqadmin[1], right?
> >>
> >> [1] http://www.inter7.com/vqadmin
> >>
> >> Tom, it's time to start an sf.net vqadmin project, isn't it? ;-)
> >>
> > Unless vqadmin gets integrated into qmailadmin, which would be
> > extremely
> > worthwhile, imho.
>
> I'm not looking to take over everything Inter7 has ever done...
>
> I'll fire up vqadmin on one of my development machines to see what it
> does.  We can then start a discussion of how to integrate some of its
> features into QmailAdmin for the 1.1 development cycle.
>
Oh, come on, now, Tom, you've already got qmailadmin and vpopmail, why not
add vqadmin while you're at it? :) ;) :)

vqadmin setup is a bear, and it definitely has a couple nice features, but
there's a huge percentage of overlap and, frankly, it makes more sense as a
global admin mode within qmailadmin than it does on it's own.  You can
create/modify/delete domains, tagged non-postmaster-account users as
postmaster, and so on.  Nice global management features.  Unfortunately,
they, too, are implemented in compiled CGI and then rely on .htpasswd to
boot.  Integrating it with qmailadmin and then bringing it up to conformance
with the look and ACLs would be a huge step forward.

RE: [qmailadmin-devel] ACL thoughts

[Benjamin T. <in...@so...>]

> On Monday, July 21, 2003, at 11:04  AM, Bill Shupp wrote:
> > I like this idea better... allowing other apps to access QmailAdmin
> > pages directly.  The obvious downfalls of using GET though is that the
> > user/pass is logged if it's in the URL.  Maybe POST could be used
> > instead.  While still unenctryped, it might be a better option.
>
> We'll probably support GET, POST and a mixture of both (form data
> POSTed, with some fields passed in the URL).  I agree that GET is bad,
> since the password is part of the URL.  I think POST, with the password
> in a hidden field in the HTML (maybe even base64-encoded for
> obfuscation) would be better.
>
> If QmailAdmin accepted cleartext and base64-encoded, it would be up to
> the other end to be as secure as deemed necessary.
>
This sounds reasonable.  Should be easy enough to wrap SSL around it if
necessary.  Allowing URL parms to directly access all pages and actions from
a single URL would somewhat negate my request for PHP conversion, though I
still think the flexibility from a PHP-based install would be hugely useful
and important.

Re: [qmailadmin-devel] ACL thoughts

[Tom C. <to...@to...>]

On Monday, July 21, 2003, at 11:04  AM, Bill Shupp wrote:
> I like this idea better... allowing other apps to access QmailAdmin 
> pages directly.  The obvious downfalls of using GET though is that the 
> user/pass is logged if it's in the URL.  Maybe POST could be used 
> instead.  While still unenctryped, it might be a better option.

We'll probably support GET, POST and a mixture of both (form data 
POSTed, with some fields passed in the URL).  I agree that GET is bad, 
since the password is part of the URL.  I think POST, with the password 
in a hidden field in the HTML (maybe even base64-encoded for 
obfuscation) would be better.

If QmailAdmin accepted cleartext and base64-encoded, it would be up to 
the other end to be as secure as deemed necessary.

--
Tom Collins
to...@to...
http://sniffter.com/ - info on the Sniffter hand-held Network Tester

Re: [qmailadmin-devel] ACL thoughts

[Bill S. <hos...@sh...>]

On Monday, July 21, 2003, at 10:23  AM, Tom Collins wrote:

> Unfortunately, I just thought of why this won't work.  As far as I 
> know, you won't be able to log out without closing the browser.

exactly..

> I'm planning to rework the URL formats in the 1.1 dev series.  I want 
> to have a system where you can link directly to any "page" within 
> QmailAdmin.  You will be able to pass the login information in hidden 
> fields (if it's known), or QmailAdmin will prompt for it if you aren't 
> logged in.  After logging you in, you'll go to the page requested 
> instead of the main menu.
>
> This will fulfill someone's request of having shell scripts run on 
> another computer that can easily authenticate with QmailAdmin and 
> accomplish a task in a single URL request.  Imagine the power in being 
> able to create a new user account by having any computer (with the 
> correct login info) fetch a URL.

I like this idea better... allowing other apps to access QmailAdmin 
pages directly.  The obvious downfalls of using GET though is that the 
user/pass is logged if it's in the URL.  Maybe POST could be used 
instead.  While still unenctryped, it might be a better option.

Regards,

Bill