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....
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?
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. 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). 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.
>
>> 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.
>
>> 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.
--
Regards,
Tom
------------------------------------------------------------------------------
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
