qmailadmin-devel — List to discuss future development of QmailAdmin

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

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

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.

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

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

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

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=96

--
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.

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

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

[qmailadmin-devel] ACL thoughts

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

The past week, I've been thinking about the htpasswd method of 
authenticating users, and whether it could be applied to this mish-mash 
of applications.  Consider this scenario:

We write an apache module to authenticate users against the vpopmail 
user databases.  You could then place .htaccess files in directories 
for qmailadmin, SquirrelMail, SpamAssassinPrefsPackageWhatever, etc. 
and they would all make use of this vpopmail authentication module.

Now, here's where it gets good.  If you place all of these packages as 
subdirectories off of a single directory, you only need to authenticate 
once via the browser, and you have access to everything.

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.

Perhaps the better solution is to allow "deep linking" into qmailadmin 
and other apps, with authentication information passed in hidden 
fields.  This way, QmailAdmin could "hand-off" to an existing SAPrefs 
program, which wouldn't have to ask the user to re-login.  Then, the 
SAPrefs could direct the user back to QmailAdmin, or even to 
SquirrelMail.  You could have a SquirrelMail plugin that links directly 
to the "Modify User Settings" screen of QmailAdmin, which contains a 
link back to SquirrelMail.  Perhaps instead of integrating vqadmin into 
QmailAdmin, we just figure out the interlinks -- fire up vqadmin to 
create/modify/delete a domain and then it hands off to QmailAdmin for 
managing the addresses in that domain.

See where I'm going with this?  If we can work out some sort of 
standard with the maintainers of these various packages, we won't end 
up re-inventing the wheel.  If someone's off to a good start with a 
PHP-based SAPrefs app, then let's spend time tying into it instead of 
trying to build it into QmailAdmin.  Modularity and flexibility is 
good.  If someone wants to bundle it all into a single package for easy 
installation, that's great.  Having building blocks that click together 
is a good goal.

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.

--
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.

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

Scott: I'm getting duplicates of ALL your messages... sometimes only 
seconds apart, sometimes minutes.

Bill


On Monday, July 21, 2003, at 07:36  AM, Scott Davis wrote:

>> Hi Scott,
>>
>>> I guess what I'm proposing is that we significantly extend the
>>> QmailAdmin interface - to control a bunch of SpamAssassin options
>>> initially...
>>
>> ok, but...
>>
>>> ...and even MORE stuff (logs, virii, etc...) later-on.  As it
>>> evolves, the software controlled might be "less flexible".
>>
>> ...I think this kind of stuff is a job to vqadmin[1], right?
>
> Oboy.  You've hit one of the nails right on the head.
>
> I wasn't aware of vqadmin until "just now".  If both projects
> (QmailAdmin and vqadmin) continue with their current "this is for 
> users"
> and "this is for administrators" 'roles'..  I don't know where my
> proposal stands.
>
> What I'm suggesting is that we throw all of it into one interface.  I
> know that's a pile of work, but I think it's the best thing to do in 
> the
> long run.  Login and <insert app name here> knows what you can modify -
> and gives you appropriate clickety, simplish buttons, etc... to get
> whatever you need done.
>
>
> 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!
>
>
> Mt Thanks, Dorneles!
>
> -- Scott.
>
>
>
>
>
> -------------------------------------------------------
> 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

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

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] FW: SpamAssassin web-control interface - proposed project.

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

> -----Original Message-----
> It sounds like you've created the 'best with both' solution.
>
This was for a completely different project, btw, not for anything directly
related to vpopmail, qmailadmin or vqadmin.  We're just using iframes today
to integrate these apps, though I'm still hopeful 1.1 will include a
conversion to something vastly more flexible than compiled CGI, such as PHP.

> I honestly have doubts that this 'many tools integrated to get the
> single job done' approach is "best".  No offense intended.
>
No offense taken.  However, consider this: qmailadmin and vqadmin have
considerable overlap.  And while it's laudable to start separate qmailadmin
more into the end-user self-admin role, I think that ends up shorting
qmailadmin where it has considerable strengths, such as with mailing list
setup.  vqadmin, on the other hand, has an archaic interface and really only
provides a couple major features over qmailadmin: the ability to manage
domains (create, delete, modify, etc., including quota limits, account
limits, etc.) and the ability to mark other user accounts within a domain as
a postmaster account.  It seems to me that if we had an admin mode for
qmailadmin that essentially went one level higher and provided these 2
features that vqadmin provides, then that would be realistic and beneficial.

However, the one main area of difference between qmailadmin and vqadmin that
would be a sticking point comes with access control.  vqadmin relies on
htpasswd authentication and then has an ACL setup underlying specifying what
realms of features an htpasswd-authenticated user can use.  We would need to
address this within qmailadmin.  This is where I came up with the notion of
an attributes field.  Those attributes could include:

P - Postmaster (single-domain administrator)
G - All-domain Administrator
M - Mailing-list Administrator (single-domain)
U - User self-administration
etc.

The better the granularity, the easier it would be to delegate various
responsibilities to people.  As a hosting provider, this is something I
believe my customers would like to see.  For example, I would want my
level-1 techs to be able to reset all user passwords, but not postmaster
passwords, while my L2 and L3 techs should be able to reset postmaster
passwords, etc.

In terms of where to keep this information, I really believe that
integration with vpopmail would be ideal (using existing CDB file or
vpopmail table).  However, from a generic standpoint, it might be better to
create a separate CDB or table.  Alternately, one could use the integration
approach for vpopmail and then have other integration or standalone options
for other installs.

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

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

> Hi Scott,
> 
> > I guess what I'm proposing is that we significantly extend the
> > QmailAdmin interface - to control a bunch of SpamAssassin options
> > initially...
> 
> ok, but...
> 
> > ...and even MORE stuff (logs, virii, etc...) later-on.  As it
> > evolves, the software controlled might be "less flexible".
> 
> ...I think this kind of stuff is a job to vqadmin[1], right?

Oboy.  You've hit one of the nails right on the head.  

I wasn't aware of vqadmin until "just now".  If both projects
(QmailAdmin and vqadmin) continue with their current "this is for users"
and "this is for administrators" 'roles'..  I don't know where my
proposal stands.

What I'm suggesting is that we throw all of it into one interface.  I
know that's a pile of work, but I think it's the best thing to do in the
long run.  Login and <insert app name here> knows what you can modify -
and gives you appropriate clickety, simplish buttons, etc... to get
whatever you need done.


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!


Mt Thanks, Dorneles!

-- Scott.

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

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

> Hi Scott,
> 
> > I guess what I'm proposing is that we significantly extend the
> > QmailAdmin interface - to control a bunch of SpamAssassin options
> > initially...
> 
> ok, but...
> 
> > ...and even MORE stuff (logs, virii, etc...) later-on.  As it
> > evolves, the software controlled might be "less flexible".
> 
> ...I think this kind of stuff is a job to vqadmin[1], right?

Oboy.  You've hit one of the nails right on the head.  

I wasn't aware of vqadmin until "just now".  If both projects
(QmailAdmin and vqadmin) continue with their current "this is for users"
and "this is for administrators" 'roles'..  I don't know where my
proposal stands.

What I'm suggesting is that we throw all of it into one interface.  I
know that's a pile of work, but I think it's the best thing to do in the
long run.  Login and <insert app name here> knows what you can modify -
and gives you appropriate clickety, simplish buttons, etc... to get
whatever you need done.


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!


Mt Thanks, Dorneles!

-- Scott.

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

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

> > > i.e. - some things will have to be addressed with qmail-scanner,
> > > maildrop or procmail - which of them should be included? All?
Why?
> > Why
> > > not just PICK one and "encourage" people to use it?
> >
> > You can PICK one but if it can be made to work with both then go for
> > both.
> >
> Good UI design should allow for both interfaces to exist simultaneous.
In
> our product development, we've adopted the format of <address> being
the
> default user interface while <address>/admin become the administrator
> interface.  As those using it know, vqadmin is already using .htpasswd
> accounts for access, etc.  For our development, we use multi-faceted
> accounts setup in a mysql table.  We could be looking at adding an
> attributes column to vpopmail, or creating a new table altogether, and
> then
> adding the attributes field to CDB version of vpopmail (or creating a
> secondary CDB file for admin attributes).  By handling it this way,
users
> should see one view and admins should see another.

It sounds like you've created the 'best with both' solution. 

I honestly have doubts that this 'many tools integrated to get the
single job done' approach is "best".  No offense intended.  


> > > Have you not found that your users want/need to implement
> > > "whitelists"..?
> >
> > Not realy but I welcome a [config] screen with mucho options.  Right
now
> > what I need is a way to provide the users with the option to tag or
sort
> > the spam.
> >
> Our users widely use whitelist_from, blacklist_from and whitelist_to.
> These are essential options for an initial deployment, along with the 
> ability to   modify their required_hits value.  We've gone so far as
to 
> mask these values into "Severe", "High", "Medium", "Low", and "None"
using > "reasonable" settings for our enviornment.  All of this is
wrapped in a 
> simple SquirrelMail plugin.  Nice and neat.  The only thing missing
from 
> my webmail is a method for users to change their passwords and setup 
> forward, vacation, etc., though that would be easy to do, too.

Thanks.  I'm glad someone else agrees that end-user modification of
white/black lists will be crucial.


Thanks, Folks!

-- Scott.

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

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

> > > i.e. - some things will have to be addressed with qmail-scanner,
> > > maildrop or procmail - which of them should be included? All?
Why?
> > Why
> > > not just PICK one and "encourage" people to use it?
> >
> > You can PICK one but if it can be made to work with both then go for
> > both.
> >
> Good UI design should allow for both interfaces to exist simultaneous.
In
> our product development, we've adopted the format of <address> being
the
> default user interface while <address>/admin become the administrator
> interface.  As those using it know, vqadmin is already using .htpasswd
> accounts for access, etc.  For our development, we use multi-faceted
> accounts setup in a mysql table.  We could be looking at adding an
> attributes column to vpopmail, or creating a new table altogether, and
> then
> adding the attributes field to CDB version of vpopmail (or creating a
> secondary CDB file for admin attributes).  By handling it this way,
users
> should see one view and admins should see another.

It sounds like you've created the 'best with both' solution. 

I honestly have doubts that this 'many tools integrated to get the
single job done' approach is "best".  No offense intended.  


> > > Have you not found that your users want/need to implement
> > > "whitelists"..?
> >
> > Not realy but I welcome a [config] screen with mucho options.  Right
now
> > what I need is a way to provide the users with the option to tag or
sort
> > the spam.
> >
> Our users widely use whitelist_from, blacklist_from and whitelist_to.
> These are essential options for an initial deployment, along with the 
> ability to   modify their required_hits value.  We've gone so far as
to 
> mask these values into "Severe", "High", "Medium", "Low", and "None"
using > "reasonable" settings for our enviornment.  All of this is
wrapped in a 
> simple SquirrelMail plugin.  Nice and neat.  The only thing missing
from 
> my webmail is a method for users to change their passwords and setup 
> forward, vacation, etc., though that would be easy to do, too.

Thanks.  I'm glad someone else agrees that end-user modification of
white/black lists will be crucial.


Thanks, Folks!

-- Scott.

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

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

> Hi Scott,
> 
> > I guess what I'm proposing is that we significantly extend the
> > QmailAdmin interface - to control a bunch of SpamAssassin options
> > initially...
> 
> ok, but...
> 
> > ...and even MORE stuff (logs, virii, etc...) later-on.  As it
> > evolves, the software controlled might be "less flexible".
> 
> ...I think this kind of stuff is a job to vqadmin[1], right?

Oboy.  You've hit one of the nails right on the head.  

I wasn't aware of vqadmin until "just now".  If both projects
(QmailAdmin and vqadmin) continue with their current "this is for users"
and "this is for administrators" 'roles'..  I don't know where my
proposal stands.

What I'm suggesting is that we throw all of it into one interface.  I
know that's a pile of work, but I think it's the best thing to do in the
long run.  Login and <insert app name here> knows what you can modify -
and gives you appropriate clickety, simplish buttons, etc... to get
whatever you need done.


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!


Mt Thanks, Dorneles!

-- Scott.

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

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

> Hi Scott,
> 
> > I guess what I'm proposing is that we significantly extend the
> > QmailAdmin interface - to control a bunch of SpamAssassin options
> > initially...
> 
> ok, but...
> 
> > ...and even MORE stuff (logs, virii, etc...) later-on.  As it
> > evolves, the software controlled might be "less flexible".
> 
> ...I think this kind of stuff is a job to vqadmin[1], right?

Oboy.  You've hit one of the nails right on the head.  

I wasn't aware of vqadmin until "just now".  If both projects
(QmailAdmin and vqadmin) continue with their current "this is for users"
and "this is for administrators" 'roles'..  I don't know where my
proposal stands.

What I'm suggesting is that we throw all of it into one interface.  I
know that's a pile of work, but I think it's the best thing to do in the
long run.  Login and <insert app name here> knows what you can modify -
and gives you appropriate clickety, simplish buttons, etc... to get
whatever you need done.


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!


Mt Thanks, Dorneles!

-- Scott.

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

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

> > i.e. - some things will have to be addressed with qmail-scanner,
> > maildrop or procmail - which of them should be included? All?  Why?
> Why
> > not just PICK one and "encourage" people to use it?
>
> You can PICK one but if it can be made to work with both then go for
> both.
>
Good UI design should allow for both interfaces to exist simultaneous.  In
our product development, we've adopted the format of <address> being the
default user interface while <address>/admin become the administrator
interface.  As those using it know, vqadmin is already using .htpasswd
accounts for access, etc.  For our development, we use multi-faceted
accounts setup in a mysql table.  We could be looking at adding an
attributes column to vpopmail, or creating a new table altogether, and then
adding the attributes field to CDB version of vpopmail (or creating a
secondary CDB file for admin attributes).  By handling it this way, users
should see one view and admins should see another.

> The strength of OSS is that you can pick the best of bread for whatever
> task your trying to accomplish.  For example vpopmail can be made to
> work with postfix which means that qmailadmin could be used even when
> your MTA is postfix!
>
Rumors, rumors...this is OT, but has anybody actually since vpopmail
installs with postfix, or even directions for it?  A year ago no such advice
existed.

> > Have you not found that your users want/need to implement
> > "whitelists"..?
>
> Not realy but I welcome a [config] screen with mucho options.  Right now
> what I need is a way to provide the users with the option to tag or sort
> the spam.
>
Our users widely use whitelist_from, blacklist_from and whitelist_to.  These
are essential options for an initial deployment, along with the ability to
modify their required_hits value.  We've gone so far as to mask these values
into "Severe", "High", "Medium", "Low", and "None" using "reasonable"
settings for our enviornment.  All of this is wrapped in a simple
SquirrelMail plugin.  Nice and neat.  The only thing missing from my webmail
is a method for users to change their passwords and setup forward, vacation,
etc., though that would be easy to do, too.

> Whatever is implemented has to be for the long term.  Future versions of
> qmailadmin will need to be backwards compatible, so whatever the
> solution is, it has to take this into considuration.
>
"backwards compatible" to what?  this is never sound logic and often leads
to closed thinking/engineering.  One ought never feel bound to previous
decisions and mistakes.  There are always ways to work-around
(upgrade/update tools, etc., such as the alias2forward.pl script).

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

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

> ...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.

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

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

> > IMHO qmailadmin is targetted for the end user and is not meant to be
> > used as an administration tool for sysadmin's.  In other words,  users
> > need the ability to set whether they want their spam sorted or simply
> > taged but they do not need to set/config virii policy.  Any email
> config
> > that does not require user input should not be in qmailadmin.
>
> I entirely agree.  I also assume that end-users shouldn't touch
> anti-virus software/settings whatsoever.  I was just writing about which
> features might be included in the "whole bunch of stuff" QmailAdmin
> interface..  that I'm proposing, I guess.
>
Ummmm....I completely disagree, and this is further supported by talk a
couple weeks ago about integrating vqadmin features into qmailadmin (it
wasn't me who brought it up, but I think it's an excellent idea).
Furthermore, qmailadmin most certainly is an admin tool -- how else do you
manage your mailing lists, robots, etc., on a per-domain basis?

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.

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

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

Hi Scott,

> I guess what I'm proposing is that we significantly extend the
> QmailAdmin interface - to control a bunch of SpamAssassin options
> initially...

ok, but...

> ...and even MORE stuff (logs, virii, etc...) later-on.  As it
> evolves, the software controlled might be "less flexible".

=2E..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? ;-)

Best 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.

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

> From: "Scott Davis" <SD...@Es...>
> 
> > I guess what I'm proposing is that we significantly extend the
> > QmailAdmin interface - to control a bunch of SpamAssassin options
> > initially, and even MORE stuff (logs, virii, etc...) later-on.  As
it
> > evolves, the software controlled might be "less flexible".
> 
> IMHO qmailadmin is targetted for the end user and is not meant to be
> used as an administration tool for sysadmin's.  In other words,  users
> need the ability to set whether they want their spam sorted or simply
> taged but they do not need to set/config virii policy.  Any email
config
> that does not require user input should not be in qmailadmin.

I entirely agree.  I also assume that end-users shouldn't touch
anti-virus software/settings whatsoever.  I was just writing about which
features might be included in the "whole bunch of stuff" QmailAdmin
interface..  that I'm proposing, I guess.

The "KISS" (Keep It Simple, Stupid) principle is *very* important when
you're designing an interface for the "average" end-user.

I do disagree on one point though - I can see some "clients" designating
a postmaster that can control most/all of the SpamAssassin UserPref's
for her domain(s).  I think that training one person - and letting them
be the "champ" or "expert" at the client site will help accomplish one
of my stated goals; reducing the support load at the ISP tech-help phone
queue.. which is my primary goal..  (with the assumption that
whitelists, blacklists and various end-user tinkering are "required").
My last (cruddy) corporate job was at a real estate brokerage firm.
Phrases like "mortgage", &c are entirely valid for them.  I just can't
see SpamAssassin being "really" effective for some of our clients,
unless we let them customize their settings all to high heaven.


> 
> > i.e. - some things will have to be addressed with qmail-scanner,
> > maildrop or procmail - which of them should be included? All?  Why?
> Why
> > not just PICK one and "encourage" people to use it?
> 
> You can PICK one but if it can be made to work with both then go for
> both.

Thanks, Gerald.  I've started in with the 'ole O'Reilly PHP/MySQL book.
I don't really write "apps" - though I do have a good amount of 'theory'
in my little brain.  

I'm starting to read/learn the PHP syntax.  I could use some more
"direct" suggestions about which components to include or exclude - to
avoid having this "extension" to QMA turn into a 'platform' specific
tool.  Anything you can offer is greatly appreciated.  (ie, focus on
qmail/Vpopmail with which of the post-receipt processors?)



> > I'm much more used to the commercial software "world".  I like
> "bundles"
> > of pre-integrated software, I admit.  My usual wants might not be
> > appropriate for the OSS world, I'm afraid.  Two of three of us (at
the
> > ISP where I'm volunteering) that are interested in initiating this
> > project think that a "bundled" solution would be great.  The other
> > individual is advocating a more "modular, flexible" approach if
> > possible.
> >
> > I'm confused about which is more appropriate.  A total, bundled
> > QMail-Vpop-MySQL-VpopMail-etc.. solution with a more feature rich
> > interface or a more flexible and less feature rich "out of the
> compile"
> > solution.  I'd love it if any of you could give me some feedback..
as
> > to where you'd like to see the QmailAdmin project go - and perhaps
> note
> > which components (SpamAss,Logs,Reports,Anti-Virii, etc..) you think
> are
> > appropriate?
> 
> The strength of OSS is that you can pick the best of bread for
whatever
> task your trying to accomplish.  For example vpopmail can be made to
> work with postfix which means that qmailadmin could be used even when
> your MTA is postfix!

*eesh* .. I have the feeling I'm about to teach this to myself the "hard
way"..  *grin*


[snip]
> > Have you not found that your users want/need to implement
> > "whitelists"..?
> 
> Not realy but I welcome a [config] screen with mucho options.  Right
now
> what I need is a way to provide the users with the option to tag or
sort
> the spam.

Okay.  We both like lots of options.  Yay!  Well, give me a week or so
and we'll see what I come up with.  

Thanks again for your comments!

-- Scott.





> Whatever is implemented has to be for the long term.  Future versions
of
> qmailadmin will need to be backwards compatible, so whatever the
> solution is, it has to take this into considuration.

*grin* -- Aye.  Assuming I create something that "works" with qma
v1.0.24 -- someone will have to maintain it.  Other than that, I think
I'm missing your point here.  

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

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

> From: "Scott Davis" <SD...@Es...>
> 
> > I guess what I'm proposing is that we significantly extend the
> > QmailAdmin interface - to control a bunch of SpamAssassin options
> > initially, and even MORE stuff (logs, virii, etc...) later-on.  As
it
> > evolves, the software controlled might be "less flexible".
> 
> IMHO qmailadmin is targetted for the end user and is not meant to be
> used as an administration tool for sysadmin's.  In other words,  users
> need the ability to set whether they want their spam sorted or simply
> taged but they do not need to set/config virii policy.  Any email
config
> that does not require user input should not be in qmailadmin.

I entirely agree.  I also assume that end-users shouldn't touch
anti-virus software/settings whatsoever.  I was just writing about which
features might be included in the "whole bunch of stuff" QmailAdmin
interface..  that I'm proposing, I guess.

The "KISS" (Keep It Simple, Stupid) principle is *very* important when
you're designing an interface for the "average" end-user.

I do disagree on one point though - I can see some "clients" designating
a postmaster that can control most/all of the SpamAssassin UserPref's
for her domain(s).  I think that training one person - and letting them
be the "champ" or "expert" at the client site will help accomplish one
of my stated goals; reducing the support load at the ISP tech-help phone
queue.. which is my primary goal..  (with the assumption that
whitelists, blacklists and various end-user tinkering are "required").
My last (cruddy) corporate job was at a real estate brokerage firm.
Phrases like "mortgage", &c are entirely valid for them.  I just can't
see SpamAssassin being "really" effective for some of our clients,
unless we let them customize their settings all to high heaven.


> 
> > i.e. - some things will have to be addressed with qmail-scanner,
> > maildrop or procmail - which of them should be included? All?  Why?
> Why
> > not just PICK one and "encourage" people to use it?
> 
> You can PICK one but if it can be made to work with both then go for
> both.

Thanks, Gerald.  I've started in with the 'ole O'Reilly PHP/MySQL book.
I don't really write "apps" - though I do have a good amount of 'theory'
in my little brain.  

I'm starting to read/learn the PHP syntax.  I could use some more
"direct" suggestions about which components to include or exclude - to
avoid having this "extension" to QMA turn into a 'platform' specific
tool.  Anything you can offer is greatly appreciated.  (ie, focus on
qmail/Vpopmail with which of the post-receipt processors?)



> > I'm much more used to the commercial software "world".  I like
> "bundles"
> > of pre-integrated software, I admit.  My usual wants might not be
> > appropriate for the OSS world, I'm afraid.  Two of three of us (at
the
> > ISP where I'm volunteering) that are interested in initiating this
> > project think that a "bundled" solution would be great.  The other
> > individual is advocating a more "modular, flexible" approach if
> > possible.
> >
> > I'm confused about which is more appropriate.  A total, bundled
> > QMail-Vpop-MySQL-VpopMail-etc.. solution with a more feature rich
> > interface or a more flexible and less feature rich "out of the
> compile"
> > solution.  I'd love it if any of you could give me some feedback..
as
> > to where you'd like to see the QmailAdmin project go - and perhaps
> note
> > which components (SpamAss,Logs,Reports,Anti-Virii, etc..) you think
> are
> > appropriate?
> 
> The strength of OSS is that you can pick the best of bread for
whatever
> task your trying to accomplish.  For example vpopmail can be made to
> work with postfix which means that qmailadmin could be used even when
> your MTA is postfix!

*eesh* .. I have the feeling I'm about to teach this to myself the "hard
way"..  *grin*


[snip]
> > Have you not found that your users want/need to implement
> > "whitelists"..?
> 
> Not realy but I welcome a [config] screen with mucho options.  Right
now
> what I need is a way to provide the users with the option to tag or
sort
> the spam.

Okay.  We both like lots of options.  Yay!  Well, give me a week or so
and we'll see what I come up with.  

Thanks again for your comments!

-- Scott.





> Whatever is implemented has to be for the long term.  Future versions
of
> qmailadmin will need to be backwards compatible, so whatever the
> solution is, it has to take this into considuration.

*grin* -- Aye.  Assuming I create something that "works" with qma
v1.0.24 -- someone will have to maintain it.  Other than that, I think
I'm missing your point here.  

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

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

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

> I guess what I'm proposing is that we significantly extend the
> QmailAdmin interface - to control a bunch of SpamAssassin options
> initially, and even MORE stuff (logs, virii, etc...) later-on.  As it
> evolves, the software controlled might be "less flexible".

IMHO qmailadmin is targetted for the end user and is not meant to be
used as an administration tool for sysadmin's.  In other words,  users
need the ability to set whether they want their spam sorted or simply
taged but they do not need to set/config virii policy.  Any email config
that does not require user input should not be in qmailadmin.

> i.e. - some things will have to be addressed with qmail-scanner,
> maildrop or procmail - which of them should be included? All?  Why?
Why
> not just PICK one and "encourage" people to use it?

You can PICK one but if it can be made to work with both then go for
both.

> I'm much more used to the commercial software "world".  I like
"bundles"
> of pre-integrated software, I admit.  My usual wants might not be
> appropriate for the OSS world, I'm afraid.  Two of three of us (at the
> ISP where I'm volunteering) that are interested in initiating this
> project think that a "bundled" solution would be great.  The other
> individual is advocating a more "modular, flexible" approach if
> possible.
>
> I'm confused about which is more appropriate.  A total, bundled
> QMail-Vpop-MySQL-VpopMail-etc.. solution with a more feature rich
> interface or a more flexible and less feature rich "out of the
compile"
> solution.  I'd love it if any of you could give me some feedback..  as
> to where you'd like to see the QmailAdmin project go - and perhaps
note
> which components (SpamAss,Logs,Reports,Anti-Virii, etc..) you think
are
> appropriate?

The strength of OSS is that you can pick the best of bread for whatever
task your trying to accomplish.  For example vpopmail can be made to
work with postfix which means that qmailadmin could be used even when
your MTA is postfix!

> Your comments reflect a subset of the SpamAssassin functionality that
> I've proposed.  Thanks for letting me know that someone (*grin*) has
> gone that far, at least.  Greatly appreciated!

Yes and No.  Most users will know the difference between taging only and
sorting the spam into a new Maildir folder.  But for the rest... its too
much for the initial screen.  That is what the [config] button is for...
For all the fancy options.

> Have you not found that your users want/need to implement
> "whitelists"..?

Not realy but I welcome a [config] screen with mucho options.  Right now
what I need is a way to provide the users with the option to tag or sort
the spam.

Whatever is implemented has to be for the long term.  Future versions of
qmailadmin will need to be backwards compatible, so whatever the
solution is, it has to take this into considuration.

Gérald

RE: [vchkpw] Re: [qmailadmin-devel] Updated vpopmail -- please review before public announcement

[Remo M. <rem...@it...>]

Did you try to put #!/bin/sh at the beginning of the line?



Remo Mattei
Network Security Engineer
cell 801-209-8554
email re...@it...

-----Original Message-----
From: sp...@gr...
[mailto:sp...@gr...] On Behalf Of spork
Sent: Sunday, July 20, 2003 5:12 PM
To: qma...@li...
Cc: vc...@in...
Subject: [vchkpw] Re: [qmailadmin-devel] Updated vpopmail -- please =
review
before public announcement

On Sat, 19 Jul 2003, Jeff Hedlund wrote:

> This definitely needs to be looked into as a bug, but in the =
meantime--
> why don't you check out my mailfilter script here:
> http://marc.theaimsgroup.com/?l=3Dqmailadmin&m=3D105689448125793&w=3D2
>
> You are calling maildrop from the directory where the Maildir is, why
> not use the PWD environment var instead of running vuserinfo?
>
> That script also picks apart the PWD to get EXT and HOST.

What shell are you using within maildrop?  I modified my filter and it
seems something is not quite working:

Modifying my filter like so:

----
SHELL=3D"/bin/sh"
VHOME=3D"$PWD/Maildir/"
USERNAME=3D`echo ${PWD##*/}`
USERHOST=3D`PWDTMP=3D${PWD%/*}; echo ${PWDTMP##*/}`
#VHOME=3D`/home/vpopmail/bin/vuserinfo -d $EXT@$HOST`
logfile
"$VHOME/maildrop.log"
log "=3D=3D=3D=3D=3D"
if ( $SIZE < 262144 )
{
        exception {
                #xfilter "/usr/local/bin/spamc -f -u $EXT@$HOST"
                xfilter "/usr/local/bin/spamc -f -u $USERNAME@$USERHOST"
}
[etc]
----

I get the following in my qmail log when a message arrives:

2003-07-20 19:04:02.689482500 delivery 13903: deferral:
Message_start_at_59_bytes,_envelope_sender=3Du...@is...=
/mail
drop:_Attempting_/usr/local/etc/mailfilter.user/maildrop:_Filtering_throu=
gh_
`echo_${PWD##*/}`/maildrop:_Filtering_through_`PWDTMP=3D${PWD_/*};_echo_$=
{PWDT
MP##*/}`//usr/local/bin/maildrop:_Unable_to_create_log_file./

Thanks,

Charles



> Jeff
>
>
>
> -------------------------------------------------------
> 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.

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

> > Proposed Project Summary:
> >
> > Create a web interface to SpamAssassin userprefs (and more) that
> > end-users or postmasters can utilize.
> 
> In my view there are 2 kinds of users.  People who use POP3 and people
> who use IMAP and the spam solution needs to change accordingly.  For
> POP3 users you needs to tag the spam and for IMAP users you can sort
the
> spam into its own Maildir.


Thanks for responding, Gerald.

I guess what I'm proposing is that we significantly extend the
QmailAdmin interface - to control a bunch of SpamAssassin options
initially, and even MORE stuff (logs, virii, etc...) later-on.  As it
evolves, the software controlled might be "less flexible".

i.e. - some things will have to be addressed with qmail-scanner,
maildrop or procmail - which of them should be included? All?  Why?  Why
not just PICK one and "encourage" people to use it?

I'm much more used to the commercial software "world".  I like "bundles"
of pre-integrated software, I admit.  My usual wants might not be
appropriate for the OSS world, I'm afraid.  Two of three of us (at the
ISP where I'm volunteering) that are interested in initiating this
project think that a "bundled" solution would be great.  The other
individual is advocating a more "modular, flexible" approach if
possible.

I'm confused about which is more appropriate.  A total, bundled
QMail-Vpop-MySQL-VpopMail-etc.. solution with a more feature rich
interface or a more flexible and less feature rich "out of the compile"
solution.  I'd love it if any of you could give me some feedback..  as
to where you'd like to see the QmailAdmin project go - and perhaps note
which components (SpamAss,Logs,Reports,Anti-Virii, etc..) you think are
appropriate?  

Your comments reflect a subset of the SpamAssassin functionality that
I've proposed.  Thanks for letting me know that someone (*grin*) has
gone that far, at least.  Greatly appreciated! 

> An example of how this could be made real is here:
> http://marc.theaimsgroup.com/?l=qmailadmin&m=105833792607618&w=2
> 
> Note that the initial interface is VERY simple it offerse only:
> 
> 1. No spam filtering at all.
> 2. Only Tag the spam do nothing else for POP3 users.
> 3. Sort the spam into a Maildir folder for IMAP users.
> 4. Delete all mail tagged as spam.
> 
> The domain wide default for new account creation could be set to one
of
> these 4 options in the .qmailadmin-limits file.
> 
> Only when you select the [config] button would you get more advance
> options like "Control over the score" etc.
> 
> Let me know what you think,
> Gerald
[Scott Davis] 

Generally, that's a simplified version of my proposed "first phase".
The three of us (at the ISP where I'm volunteering) have very different
ideas about what's the best approach to take once an email is classified
as "spam".  I'd like to make that stuff as flexible as possible right
now.  

Have you not found that your users want/need to implement
"whitelists"..?  

Thanks again, Gerald.  

-- Scott!

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

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

> > Proposed Project Summary:
> >
> > Create a web interface to SpamAssassin userprefs (and more) that
> > end-users or postmasters can utilize.
> 
> In my view there are 2 kinds of users.  People who use POP3 and people
> who use IMAP and the spam solution needs to change accordingly.  For
> POP3 users you needs to tag the spam and for IMAP users you can sort
the
> spam into its own Maildir.


Thanks for responding, Gerald.

I guess what I'm proposing is that we significantly extend the
QmailAdmin interface - to control a bunch of SpamAssassin options
initially, and even MORE stuff (logs, virii, etc...) later-on.  As it
evolves, the software controlled might be "less flexible".

i.e. - some things will have to be addressed with qmail-scanner,
maildrop or procmail - which of them should be included? All?  Why?  Why
not just PICK one and "encourage" people to use it?

I'm much more used to the commercial software "world".  I like "bundles"
of pre-integrated software, I admit.  My usual wants might not be
appropriate for the OSS world, I'm afraid.  Two of three of us (at the
ISP where I'm volunteering) that are interested in initiating this
project think that a "bundled" solution would be great.  The other
individual is advocating a more "modular, flexible" approach if
possible.

I'm confused about which is more appropriate.  A total, bundled
QMail-Vpop-MySQL-VpopMail-etc.. solution with a more feature rich
interface or a more flexible and less feature rich "out of the compile"
solution.  I'd love it if any of you could give me some feedback..  as
to where you'd like to see the QmailAdmin project go - and perhaps note
which components (SpamAss,Logs,Reports,Anti-Virii, etc..) you think are
appropriate?  

Your comments reflect a subset of the SpamAssassin functionality that
I've proposed.  Thanks for letting me know that someone (*grin*) has
gone that far, at least.  Greatly appreciated! 

> An example of how this could be made real is here:
> http://marc.theaimsgroup.com/?l=qmailadmin&m=105833792607618&w=2
> 
> Note that the initial interface is VERY simple it offerse only:
> 
> 1. No spam filtering at all.
> 2. Only Tag the spam do nothing else for POP3 users.
> 3. Sort the spam into a Maildir folder for IMAP users.
> 4. Delete all mail tagged as spam.
> 
> The domain wide default for new account creation could be set to one
of
> these 4 options in the .qmailadmin-limits file.
> 
> Only when you select the [config] button would you get more advance
> options like "Control over the score" etc.
> 
> Let me know what you think,
> Gerald
[Scott Davis] 

Generally, that's a simplified version of my proposed "first phase".
The three of us (at the ISP where I'm volunteering) have very different
ideas about what's the best approach to take once an email is classified
as "spam".  I'd like to make that stuff as flexible as possible right
now.  

Have you not found that your users want/need to implement
"whitelists"..?  

Thanks again, Gerald.  

-- Scott!

Re: [qmailadmin-devel] Updated vpopmail -- please review before public announcement

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

On Sat, 19 Jul 2003, Jeff Hedlund wrote:

> This definitely needs to be looked into as a bug, but in the meantime--
> why don't you check out my mailfilter script here:
> http://marc.theaimsgroup.com/?l=qmailadmin&m=105689448125793&w=2
>
> You are calling maildrop from the directory where the Maildir is, why
> not use the PWD environment var instead of running vuserinfo?
>
> That script also picks apart the PWD to get EXT and HOST.

What shell are you using within maildrop?  I modified my filter and it
seems something is not quite working:

Modifying my filter like so:

----
SHELL="/bin/sh"
VHOME="$PWD/Maildir/"
USERNAME=`echo ${PWD##*/}`
USERHOST=`PWDTMP=${PWD%/*}; echo ${PWDTMP##*/}`
#VHOME=`/home/vpopmail/bin/vuserinfo -d $EXT@$HOST`
logfile
"$VHOME/maildrop.log"
log "====="
if ( $SIZE < 262144 )
{
        exception {
                #xfilter "/usr/local/bin/spamc -f -u $EXT@$HOST"
                xfilter "/usr/local/bin/spamc -f -u $USERNAME@$USERHOST"
}
[etc]
----

I get the following in my qmail log when a message arrives:

2003-07-20 19:04:02.689482500 delivery 13903: deferral:
Message_start_at_59_bytes,_envelope_sender=use...@is.../maildrop:_Attempting_/usr/local/etc/mailfilter.user/maildrop:_Filtering_through_`echo_${PWD##*/}`/maildrop:_Filtering_through_`PWDTMP=${PWD_/*};_echo_${PWDTMP##*/}`//usr/local/bin/maildrop:_Unable_to_create_log_file./

Thanks,

Charles



> Jeff
>
>
>
> -------------------------------------------------------
> 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...>
To: <qma...@li...>
Sent: Saturday, July 19, 2003 3:36 AM
Subject: [qmailadmin-devel] FW: SpamAssassin web-control interface -
proposed project.


> Proposed Project Summary:
>
> Create a web interface to SpamAssassin userprefs (and more) that
> end-users or postmasters can utilize.

In my view there are 2 kinds of users.  People who use POP3 and people
who use IMAP and the spam solution needs to change accordingly.  For
POP3 users you needs to tag the spam and for IMAP users you can sort the
spam into its own Maildir.

An example of how this could be made real is here:
http://marc.theaimsgroup.com/?l=qmailadmin&m=105833792607618&w=2

Note that the initial interface is VERY simple it offerse only:

1. No spam filtering at all.
2. Only Tag the spam do nothing else for POP3 users.
3. Sort the spam into a Maildir folder for IMAP users.
4. Delete all mail tagged as spam.

The domain wide default for new account creation could be set to one of
these 4 options in the .qmailadmin-limits file.

Only when you select the [config] button would you get more advance
options like "Control over the score" etc.

Let me know what you think,
Gerald