-------- Original-Nachricht --------
> Datum: Tue, 10 Nov 2009 09:54:50 +0100
> Von: Tom Hendrikx <t...@whyscream.net>
> An: Steve <steeeeev...@gmx.net>
> CC: dspam-user@lists.sourceforge.net, ds...@cytringan.co.uk
> Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4
> Steve wrote:
> > -------- Original-Nachricht --------
> >> Datum: Tue, 10 Nov 2009 00:43:05 +0100 Von: Tom Hendrikx
> >> <t...@whyscream.net> An: Steve <steeeeev...@gmx.net>,
> >> dspam-user@lists.sourceforge.net Betreff: Re: [Dspam-user] DSPAM
> >> 3.9.0 BETA 4
> >
> >> Steve wrote:
> >>
> >>> You miss one point: Everyone and his dog think they can package
> >>> the product better. Let's look for example at Debian: They break
> >>> up the configuration in peaces and have one part in dspam.conf
> >>> while having another part some where external.
> >>>
> >>> And now just think about how many different distros are there and
> >>> other OS that do the same. And now try to bring one universal
> >>> tool helping to configure all those DSPAM installations. Good
> >>> look doing that!
> >> Don't get me wrong, I'm not trying to advocate for a 'universal
> >> tool'. If we can install all the relevant stuff in relevant
> >> locations (based on FHS or any other sane standard),
> >>
> > FHS only applies to certain OS. Linux for example. But what about all
> > the different *BSD brands? And what about all the different
> > incarnations of Solaris/Open Solaris? etc... It's not easy to be
> > multi platform.
>
> 'Sane locations' are available on every OS, just like they are used
> right now. That is why configure has things like --prefix
> or--sysconfdir: so that the OS, the vendor/distro or the admin can setup
> things they like. And the Makefile can (should!) use this information to
> it's own advantage. This is off-topic since most of this is already in
> place and working fine, or easy to fix.
>
> >> For instance: the choice for large-scale, domain-scale or none of
> >> them. It is not clear what the choice means for your setup: does it
> >> affect the default config, or does it also affect the way Dspam
> >> works internally? Why does Dspam have this option, and Postfix for
> >> example doesn't? Or to turn it the other way: why needs Dspam such
> >> a thing and Postfix or Dovecot do not?
> >>
> > Dovecot has something like that. And Postfix as well. They use it in
> > different areas of the product. And all this because of speed and
> > other limitations/influences of the underlaying file system. You have
> > to think global. Can you imagine 1 million email addresses managed by
> > DSPAM? And all of those 1 million emails saved under
> > /var/spool/dspam/data/xxxxx. Flat. No hierarchy at all. Can you
> > imagine how horribly slow lookups in this directory will be? That's
> > the reason for the large-scale and/or domain-scale. They both try to
> > mitigate that issue by splitting the directory either on the first
> > two letters of the email (large scale) or by splitting on domain
> > level (domain scale). And don't think that DSPAM is the only one
> > doing that. Squid is doing the same with their cache directory.
> > Postfix is doing it in the queue. Dovecot is doing it when storing
> > the mails in mbox or maildir (see mail_location and the various
> > options to tweak how to organize your mail store).
> >
>
> If you would introduce something like Dovecots macro processing of
> usernames and domains into Dspam, you can obsolete --enable-homedir,
> --enable-long-usernames, --enable-domain-scale, --enable-large-scale,
> --with-dspam-home and maybe more from configure, *and* gain more
> flexibility for power setups. Aaaaah, simplicity....
>
@simplicity: That would be more complicated then two simple options (either
domain- or large scale).
@flexibility: Definitely. That would be more flexible.
> Another example from yesterdays mail thread: preferences extension. You
> can setup default preferences in dspam.conf and database, user
> preferences in database and homedir config file, change stuff in the
> webUI or via the dspam_admin utility (in which of the mentioned places
> does such a change end up, or is there a 5th or even 6th location?). And
> in which order are values in all these locations applied?
>
It's all written in the doc.
1) If preference extensions are enabled then they are first evaluated.
1.1) First by user UID
1.2) Second by default UID (0)
2) Then dspam.conf is evaluated
For the web-UI the default.prefs are used to set defaults in the UI if
preference extensions are not enabled.
The tool that takes care of aggregating the preferences (regardless of what you
use) is the dspam_admin tool. It takes care to exactly list/set the preferences
for the user:
dspam_admin aggregate preference <username>
> When you ask someone to 'change the preference setting', I can
> understand that he cannot see his change applied when he even doesn't
> know in which location to update them, and where to check for the
> result.
>
Then he has not read the documentation.
> A good brainstorm could result in something that is a lot more
> easier to understand and administer (from sysadmin view), to use (from
> user view) and to debug (from developer or supporter view).
>
> I think things like this should be thought of again, and maybe see an
> overhaul for Dspam 4.0 (yes I'm optimistic:>). You could see this as
> feature bloat (and that needs to die).
>
To be honest: I don't see that as an feature bloat.
I see the whole thing as an logical stacking of evaluation of places the
configuration is read. Pretty much like on every modern system. Let's take for
example something like IBM Lotus Domino/Notes:
- You have access rights to the domain
- You have access rights to a Domino server
- You have access rights to a directory on the server file system
- You have access rights to a database (ACL)
- You have access rights to a view/folder inside the database
- You have access rights to documents inside the database
- You have access rights to sections of the document
- You have access rights to fields on the document
- Fields can be crypted
- Documents can be crypted
- Databases can be crypted
- etc...
Now you can go and give someone right to a certain document inside a database.
You can give him full rights but as long as he does not have access rights to
the database all the rights you have given him/her do not help. That's because
the document resists inside a database and to have access to a document one
first needs access to the database. Etc...
And DSPAM preferences are like that. If you read the documentation then you
will see where you need to change them in order to have proper working
preferences for a user. It's simple once you have read the documentation and
not just read but understood.
> This is not the fault of today's
> developers, but thinking about it could be put on the todo-list. I'd be
> happy to add my thoughts.
>
DSPAM is very powerful and the problem is that DSPAM is not hiding things from
the user. And the second problem is that some users not understanding much of
DSPAM internals are not using the tools that make their life easier but go
ahead and fiddle around with changing dspam.conf and directly
adding/removing/modifying entries in the database instead of using the tools
that abstract the complexity for them (for example dspam_admin).
> >> I just want to show an example (the answer is in the README), there
> >> are so much things that you cannot gripe without reading all the
> >> docs again and again. Postfix is quite easy to setup: default
> >> install and 30 minutes with a howto suffice for a simple test
> >> setup, and it does stuff like domain-/large-scale in the config
> >> file, so you can fiddle with it easily, *after* having your initial
> >> setup up and running. With Dspam you get lost in the knobs and
> >> dials that have all kinds of functions that are far from obvious,
> >> even before can type 'make && make install' ;)
> >>
> > You want to tell me that Postfix is obvious? No way! Some one never
> > having anything done with messaging will have his hard time to
> > configure a properly working Postfix. And the same goes for DSPAM.
> > Without reading and understanding what you read it's hard. No mater
> > at what you look.
> >
> When I compare the time that I needed to first-time setup Postfix for 1
> domain and 2 mailboxes (i.e. a test setup) to Dspam with same setup:
> yes, Postfix is easy.
> I'm not talking about systems with gazillion domains/users here, minimal
> setup should be easier, this makes adoption and testing of Dspam much
> better. ISP-sized setups always need special attention so the admin
> should should give it the time and work it needs. It's their work and
> they know it.
>
DSPAM is not really much harder then Postfix. Installing DSPAM and configuring
it to process mail and tag the mails is easy. Gluing it together with Postfix
is another issue. Can you tell me what was/is so hard in installing and
configuring DSPAM?
> >> Maybe it would make a nice point on the todo-list to look into a
> >> way to make sure that new users can get a new install up and
> >> running without too much hassle, even without a configuration
> >> utility or strong guidance /lots of work from their distro.
> >>
> > I would love if that would be possible. But I am afraid that you
> > can't much abstract things in DSPAM. It's not as easy as adding a
> > gearshift, clutch, brake pedal and an accelerator. You need to
> > understand some fundamental things and if you don't understand them
> > then it's not easy to handle DSPAM. If some one is not understanding
> > how tokenizers are working then how the heck is one supposed to
> > abstract that in DSPAM?
> >
> I read most of what I know about Dspam tokenizers a few months ago (in
> one of your great mails, I think), after almost 2 years of Dspam use,
> just because it was interesting. Sensible defaults add lots of
> abstractions for new users. In Dspam, this holds true for the tokenizer
> stuff (I think, last clean setup was some time ago) but not for some
> other parts, such as the scaling stuff mentioned earlier.
>
>
> @Paul Cockings: I think I'm in the same seat as you: an administrator
> but not a coder. As you can see I don't expect any of this in beta5 or
> 3.9.0 release, I just merely want to point out the places where I think
> Dspam could gain a lot in means of acceptation.
>
I personally welcome that. Bring on the ideas and solutions how to make DSPAM
easier.
> --
> Regards,
> Tom
>
Steve
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Dspam-user mailing list
Dspam-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspam-user
