[Kolab-devel] TO all anti-spam enthusiasts

Mon Jan 7 13:37:50 CET 2008

On Jan 7, 2008 9:04 AM, Gunnar Wrobel <wrobel at pardus.de> wrote:
> "Alain Spineux" <aspineux at gmail.com> writes:
>
> > On Jan 3, 2008 11:41 AM, Bernhard Reiter <bernhard at intevation.de> wrote:
> >> On Monday 17 December 2007 20:02, Richard Bos wrote:
> >> > > Why do you want to hide the underneath features under vague words.
> >>
> >> Administrators ("users" to our Kolab Server) often report that they are
> >> overwhelmed with options, they also do not understand.
> >> This is why the administration capabilities should be very strict about
> >> containing only the most important buttons. We should put up a good argument
> >> for each button as experienced MTA administrators can use the kolab-templates
> >> anyway to fine-tune. And they will need to do it.
> >
> > I thing that set the default to a reliable value and clearly show the
> > recommended
> > value to the user is a better solution than to hide the complexity.
> > If the user can see that all settings are set to the recommended values,
> > it will be reassured.
> >
> >>
> >> > > Why not list them all, maybe ordered from the lighter to the hardest, and
> >> > > maybe with a hint in ( relaxed, medium, aggressive ) and some more help.
> >> >
> >> > Why not combine both ;) ?
> >> >
> >> > Each and every measure should just be listed, which could be activated with
> >> > e.g. a checkbox.
> >>
> >> No, this is probably overkill.
> >
> > We are speaking about 10 or less options, no more !
>
> All these options are currently available for the system administrator
> by directly editing the templates.

Yes! But the complexity of the configuration of a grey listing or an
RBL in Kolab is the
same as installing another "FooBar OpenGroupware" already having these
features :-)

Then here is a compromise, to make both happy.
- All options could be enable by a group option on the GUI or
individually by manually
editing /kolab/etc/kolab.kolab.global. And related template should
look like this, here apostfix template :

@@@if anti-spam-groupA OR anti-spam-optionA1@@@
postfix_optionA1= yes
@@@endif@@@

@@@if anti-spam-groupA OR anti-spam-optionA2@@@
postfix_optionA2= yes
@@@endif@@@
...
@@@if anti-spam-groupB OR anti-spam-optionB1@@@
postfix_optionB1= yes
@@@endif@@@

I don't thing template enable logical OR and AND expressions, but this
should be very easy
to do.

Regards

>
> The web admin should really only be a very basic frontend that first
> time users can easily understand and use. It is not intended to convey
> much of the complexity of underlying server configuration.
>
> It might be something different if the web admin would have a
> different code structure that would make it better extendable and
> would provide something like an "expert" switch that would provide
> additional features. But that is something we don't have right now so
> I think it would be good to start very simple.
>
> I also think that the first step should be decent documentation in the
> wiki about better spam prevention using postfix.
>
> Cheers,
>
> Gunnar
>
>
> >
> >> Using a few sections with a sensible grouping might be better.
> >> Single measure can still be defined in the configuration files themselfs.
> >>
> >> > Additionally there could be three columns after the checkbox that shows
> >> > whether the measure is part of a (convenience group as listed above
> >> > (relaxed, medium or aggressive)).
> >> > The convenience groups are probably just arrays in php (or maybe a new
> >> > template file?). By selecting a convenience group all measure that are
> >> > part of that group will be checked. That way it is also visible clear what
> >> > the result will be of selecting a convenience group.
> >>
> >> I agree that there should be good documentation about what the groups do,
> >> but on the other hand, I know that documentation will rot pretty fast,
> >> so for a frist step a hint towards the relevant templates would be sufficient.
> >> I think that adding another mini-templating system like arrays in php would be
> >> too complex to do any good. The main work will be to discuss what good default
> >> are. Doing for three levels instead of the one that we have know is adding
> >> more load to us.
> >>
> >> So even the idea of adding only one level or keep the current and document
> >> the possibilities of postfix better is still appealing to me. ;)
> >>
> >> Bernhard
> >>
> >> --
> >> Managing Director - Owner: www.intevation.net       (Free Software Company)
> >> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> >> Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> >> Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
> >>
> >> _______________________________________________
> >> Kolab-devel mailing list
> >> Kolab-devel at kolab.org
> >> https://kolab.org/mailman/listinfo/kolab-devel
> >>
> >
> >
> >
> > --
> > Alain Spineux
> > aspineux gmail com
> > May the sources be with you
> >
> > _______________________________________________
> > Kolab-devel mailing list
> > Kolab-devel at kolab.org
> > https://kolab.org/mailman/listinfo/kolab-devel
>
> --
> ______ http://kdab.com _______________ http://kolab-konsortium.com _
>
> p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
>
> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
> E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
> Tel.   : +49 700 6245 0000                          Bundesstrasse 29
> Fax    : +49 721 1513 52322                          D-20146 Hamburg
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
>
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel

-- 
Alain Spineux
aspineux gmail com
May the sources be with you