Shure ist not so hard to configure, If you know Dspam. Its normal for us who knows how and what to do with dspam (more or less :-) to say its not hard to configure. We forgot how hard the first time was :-)
But I see there no way out. Dspam is a Product for Hosters not enduser. Its their normal job getting into complex Applications, adapt them and use them. If you want to make it easier thers a simple solution: First Restrukture the Documentation or make two of it. Means One is a Step by Step first install, second the inside all about Dpsam Documentation. This will help at first steps. They have to learn it more inside anyway and this I not nessesary a bad thing. I think its absolutely the wrong investing now time into make it easier instead of bringing dspam into his next generation. How many daemons you know where the setup is easy? Did you ever setup and apache host (ther are compileoptions a user take days to understand what they man and even years to know when they need them and not even to think about the configuration)... No dpsam is design to be an enterpriselevel system not an enduser desktop filter. The question is not to make a setup easier. The question is how to make it easier to understand dspam and its strukture - here the apache website documentation is a good way to go ..... BTW I want to say again that it would be really nessesary getting rid of saved files into the Filesystem and replace it with a database driven system (even when it means that hash no longer works). It will make things simplier - many permission issue will be solved that way. Even Problems to scale the system and many other things -----Ursprüngliche Nachricht----- Von: Steve [mailto:steeeeev...@gmx.net] Gesendet: Dienstag, 10. November 2009 16:24 An: dspam-user@lists.sourceforge.net Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4 -------- Original-Nachricht -------- > Datum: Tue, 10 Nov 2009 13:44:03 +0100 > Von: Tom Hendrikx <t...@whyscream.net> > An: Steve <steeeeev...@gmx.net> > CC: dspam-user@lists.sourceforge.net > Betreff: Re: [Dspam-user] DSPAM 3.9.0 BETA 4 > 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. > You write as if I was the one making up that decision to implement stuff that way. It's not me. I am just the poor DSPAM user working the last months almost exclusively on developing and fixing issues in DSPAM. The good think to have this as compile option is that you can overstep the reading of dspam.conf in some situations and using what the user has set on compile time. This saves time. Having everything configurable inside dspam.conf would definitely be a great option but does not necessarily makes things less complex. In some areas it makes things more complex. One of such things is the Web-UI where you would need to ensue read access to dspam.conf for the tools and if some one is running the Web UI in a chroot then things get more complicated. Using variables would be cool. But I am sure that most users would not fiddle around with default setups. When looking at what Dovecot allows then I am sure that most users would just use: %u - username %n - user part in u...@domain, same as %u if there's no domain %d - domain part in u...@domain, empty if there's no domain %h - home directory I personally would like to have more then just that. I would like to have the offset functionality as well. That would allow me to implement large scale by just using %h/%1u/%2.1u/%u and domain scale by just using %h/%d/%u. However... one would need to tweak that since DSPAM does not follow strict <1st char>/<2nd char>/<full username> for large scale. If the user name has a "." on the 2nd character then the directory might look like this for user d.u...@domain.tld: /var/spool/dspam/data/d/d.u...@domain.tld/. This basically breaks the assumption that every user can be reached 3 levels down the data root if one is using large scale. >From my viewpoint this is a bug in DSPAM. But probably John has never thought about that a dot has a special meaning on some file systems and that /var/spool/dspam/data/d/./d.u...@domain.tld is equal to /var/spool/data/d/d.u...@domain.tld > > 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. > He does not! If one just installs DSPAM and does not fiddle around then he can have DSPAM up and running in no time. 1) Install DSPAM - apt-get install dspam dspam-webfrontend - emerge dspam dspam-web - rpm -Uvh dspam - etc 2) Configure storage backend inside dspam.conf (for this example I use MySQL) - edit/change: MySQLServer, MySQLUser, MySQLPass, MySQLDb, StorageDriver 3) Configure the delivery and server/client stuff inside dspam.conf: - edit/change: DeliveryHost 127.0.0.1 - edit/change: DeliveryPort 10026 - edit/change: DeliveryIdent localhost - edit/change: DeliveryProto SMTP - edit/change: ServerDomainSocketPath "/var/run/dspam/dspam.sock" - edit/change: ClientHost "/var/run/dspam/dspam.sock" - edit/change: ClientIdent "<password>@dspam_localhost" 4) Import the database schema into MySQL - mysqladmin --user=root -p create dspam - mysql --user=root -p > GRANT SELECT, INSERT, UPDATE, DELETE ON dspam.* TO 'dspam_admin'@'localhost' IDENTIFIED BY 'dspam_admin_password'; > GRANT SELECT, INSERT, UPDATE, DELETE ON dspam.* TO 'dspam_admin'@'localhost.localdomain' IDENTIFIED BY 'dspam_admin_password'; > FLUSH PRIVILEGES; > quit; - mysql --user=root -p dspam < src/tools.mysql_drv/mysql_objects-speed.sql - mysql --user=root -p dspam < src/tools.mysql_drv/virtual_users.sql 5) Integrate DSPAM with his MTA (for example Postfix) - edit master.cf smtp inet n - n - - smtpd -o content_filter=lmtp:unix:/var/run/dspam/dspam.sock 127.0.0.1:10026 inet n - n - - smtpd -o content_filter= -o local_header_rewrite_clients= -o local_recipient_maps= -o mynetworks=127.0.0.0/8 -o mynetworks_style=host -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,n o_milters -o relay_recipient_maps= -o smtp_send_xforward_command=yes -o smtpd_authorized_xforward_hosts=127.0.0.0/8 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_delay_reject=no -o smtpd_end_of_data_restrictions= -o smtpd_error_sleep_time=0 -o smtpd_hard_error_limit=1000 -o smtpd_helo_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_restriction_classes= -o smtpd_sender_restrictions= -o smtpd_soft_error_limit=1001 -o strict_rfc821_envelopes=yes 6) Install and configure the Web-UI 7) Start the DSPAM daemon (if needed) 8) Finish How hard is that? > > 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? > NO ONE IS STUPID! Real stupid people are rare. > 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. > It's mentioned in the README. > 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. > They don't care. You are right. But they all cry out loud when they realize that the choosen tokenizer is not good for them and that they need to restart from the scratch and months of training. > >> 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. > Sorry. But Postfix has way, way, way more configure options then DSPAM. And the same goes for Dovecot, Apache, etc... they all have more options then DSPAM. > 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. > I could create a bunch of pre-configs for such scenarios. Pretty much like MySQL does and include them in DSPAM and allow users to just execute a shell script asking them a bunch of questions and then modify dspam.conf, Apache configuration, MTA (Postfix, Exim, Sendmail, etc) and the storage backend (MySQL, SQLite, PostgreSQL, etc). > The domain-/large-scale stuff vs. path macro processing would be a nice > starter. > I would sure welcome such a macro processing capability but I don't think that this would significantly change the complexity. For a bunch of reasons: 1) Distro packagers choose the compile options and deliver a binary package 2) domain-/large-scale is not something preventing people running DSPAM. I even don't remember when someone asked help for that here in the ML. > -- > Tom > Steve -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ---------------------------------------------------------------------------- -- 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 !DSPAM:1005,4af9872c321701804284693! ------------------------------------------------------------------------------ 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
