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