Steve wrote: >> 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).
You would remove 5 configure switches that no first-timer understands for something that can (and probably should) be handled more elegantly in a configuration file, where changes to directory paths are applied to configuration items named like "user_homedir": a name that reflects a directory path. And *that* is simple and understandable to anyone. > It's all written in the doc. > > <snip> > > Then he has not read the documentation. > > <snip> > > 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. > Again, I do not think a new user needs to spend 2 days of documentation reading before he can get a test setup running. > 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). > This is a nice one: they don't understand the internals, yet dive into it and fiddle in all the wrong locations. Are there too many locations, too much documentation explaining too much stuff and not pointing to the right tools, or too stupid users? I never saw dspam_admin before bash autocompletion told me of it's existance. Maybe it was in the docs somewhere, but I think I missed it. The keyword here is: make it more straightforward. Don't write more docs to explain stuff that is simply 'too hard', but make the process simpler and document in 2 parts: the straightforward way and the stuff with all the background info. Most people who don't run a resource-short server don't care which tokenizer is used, as long as it yields them a 99% success rate. >> 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? > This was more than 2 years ago, but I remember at least that I got scared on all the configure switches I didn't understand (or gentoo use flags for that matter), and then getting swamped in the documentation which is accurate, technical and far too much for a newbie. After getting the feeling that I read up on all the things I did not understand, most of the information from the first half of the reading session was already gone. 2 days had passed and I didn't install a thing yet. After that I just installed and started to get a setup running without understanding if I even started in the right direction. I succeeded in the end, but simply said: it is too f***ing hard for a newbie :) > Bring on the ideas and solutions how to make DSPAM easier. If we can agree on thinking up on this concept: getting new users started easily, combining code changes that make configuration/setup more straightforward, and documentation that helps first-timers setting things up in say two hours, then bring on the wiki account. The domain-/large-scale stuff vs. path macro processing would be a nice starter. -- 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
