[Kolab-devel] TO all anti-spam enthusiasts

Gunnar Wrobel wrobel at pardus.de
Mon Jan 7 09:04:23 CET 2008

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

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.



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

More information about the devel mailing list