Re: [dspam-users] I would appreciate some feedback
ציטוט ML: Le 24 janv. 09 à 15:56, Dov Zamir a écrit : Thomas wrote: I would like to see a better webgui through which you configure everything, so don't have to tweak config files and hack apache to define users. The web gui should be designed in such a way that it gives a unified interface for all actions (admin and user functions). It should give you the option to define, import or refer to users through external user databases (ldap, mysql...) First of all, we are planning a completely new webGUI based upon PHP, with i13n possibilities. However, I am unclear as to why you would want to refer to users through an external database. IMHO, dspam should, at best, use the same userbase as your MTA. Please enlighten me as why that should not be the case. ATM you have two options, as far as I understand, to define users. Either you define them manually, or you let dspam add them as they receive (or in some installations, send) mail. We currently use a shared DSPAM user on a per "customer" basis. This is a case where a external database would help, as one DSPAM user match several email addresses, usually one DSPAM user mean in fact one domain name, but sometimes several domain names also. We wrote various scripts to update the DSPAM group text file and restart DSPAM deamon, but it would be very better if we can handle this directly in our main user DB in a simple 2 entries table that match mail recipient to actual DSPAM user. I think moving every DSPAM datas to some abstract DB connector would be the best, this would allow to build DB connector for several Backend (MySQL, PostgreSQL, Hash, and so on). Maybe it is hard work, but currently having DB *and* file storage mean IMHO bad scalability, bad security (webgui need access to flat file on backend storage !?), and complexity for contributors that want to write new features. My 2c. too ;) OK, but this is not a webGUI issue. It is a core issue. -- Ml !DSPAM:1011,497c2637150921360121267!
Re: [dspam-users] I would appreciate some feedback
ציטוט Thomas: First of all, we are planning a completely new webGUI based upon PHP, with i13n possibilities. However, I am unclear as to why you would want to refer to users through an external database. IMHO, dspam should, at best, use the same userbase as your MTA. Please enlighten me as why that should not be the case. Let my try it in an other way ;) - You install dspam - The first time you login as the admin your asked if it should create the databases for you and where the db server is located (login credentials an such). - You're asked if you want to import users from Active Directory/LDAP/other database, create users manually, lookup users in runtime, say a already created database used by postfix/MTA or create users as email passes through the gateway. - You can now group together email addresses so when user abc logs in he/she will see spammail for all in the group. Settings are bound to user abc so same settings apply to all the addresses. The grouping could be by manually selecting rows of addresses or by defining a common attribute (don't know how/or what though) making out the group automatically. - You can choose to use pre-trained data on users until they have collected enough for them self and detach the shared spam-data. - You can choose global settings and define if users should be able to customize them. - You select when/how optimization jobs should run on the database. - You can define replica servers in an environment with multiple MTA's sharing your configuration. - You specify digest mails and what they should look like. - You define if users have a local password or they are looked up through external databases (AD/LDAP/PAM...) - You can define for how long mails are kept in the quarantine and/or if users should be able to change this. - You define if users can use whitelists and how many per user. I see a solution where a simple setup with few users can be configured in matters of minutes and in a huge enterprise/ISP environment dspam will more or less be inserted without cumbersome changes and kind of seamless. I like the idea that the dspam installation more or less is completely handle through this webui. This sounds good. Could you pleased add this a featur request at: https://sourceforge.net/tracker2/?group_id=250683&atid=1126468 I understand that you have actually implemented some of these? Is it implemented entirely within the webui? Can you kindly submit your patches? /Thomas !DSPAM:1011,497c279c150921632311776!
Re: [dspam-users] I would appreciate some feedback
Steve wrote: Hello all I would like to get some feedback from as many people as possible so I am asking here: You as DSPAM user or as DSPAM admin: If you would have the chance to change or add anything to DSPAM, what would that be? Or if you are not a DSPAM user jet and using something else: Why don't you use DSPAM? Why do you use something else? What function / feature would motivate you to switch to DSPAM? And finally something else: Do you all know that DSPAM has a feature request page at SourceForge? -> https://sourceforge.net/tracker2/?group_id=250683&atid=1126468 If you had in the past something you wanted to be included or built into DSPAM then now is the right time to request that. Now that the community is starting to take over DSPAM development it is the best time to bring in your request. I mainly use DSPAM on small firm sites up to several hundred users and up to few thousands mails/day, mostly with hash driver and configured as shared,managed groups. My two cents of wish: - Web UI display non-ISO8859-1 chars in From/Subject as garbage. Resolve this probably lead to decode and save these fields in DSPAM databases as UTF-8 and do not need be trivial.. - Web UI history should be allow optionally display "To:" field - this option would be useful just in case managed groups, as it helps group manager deciding. - I'm not sure how it exactly works, but I have suspicion, that DSPAM learning spam from non-US/non-ISO8859-1 is worse. We use ISO8859-2 and cp1250, spam come in too from Russia and Far East, and I feel its filtering isn't as successful as with ASCII/Latin1 spams. I have some DSPAM RPM packages and .SPEC file on my site http://hanzlici.cz/packages/fedora/dspam/ when You would like use them or inspire from it, and I've some experience with RPM packaging, when I may offer them. Regards, Franta Hanzlik !DSPAM:1011,497c321d150928841216105!
Re: [dspam-users] I would appreciate some feedback
Steve wrote: Hello all I would like to get some feedback from as many people as possible so I am asking here: You as DSPAM user or as DSPAM admin: If you would have the chance to change > or add anything to DSPAM, what would that be? Or if you are not a DSPAM user jet and using something else: Why don't you > use DSPAM? Why do you use something else? What function / feature would > motivate you to switch to DSPAM? And finally something else: Do you all know that DSPAM has a feature request page at > SourceForge? -> https://sourceforge.net/tracker2/?group_id=250683&atid=1126468 If you had in the past something you wanted to be included or built into > DSPAM then now is the right time to request that. Now that the community > is starting to take over DSPAM development it is the best time to bring > in your request. // Steve -- One more feature would be nice - when DSPAM could act as milter. (I use sendmail, but postfix can use it too, I'm right?) Regards, Franta Hanzlík !DSPAM:1011,497c34b4150923378614474!
Re: [dspam-users] I would appreciate some feedback
> -- > One more feature would be nice - when DSPAM could act as milter. > (I use sendmail, but postfix can use it too, I'm right?) > Yes. You are right. Newer Postfix versions can use milter. > Regards, Franta Hanzlík -- NUR NOCH BIS 31.01.! GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 EURO/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a !DSPAM:1011,497c3532150928436258331!
[dspam-users] Re: [Dspam-community-devel] I would appreciate some feedback
Original-Nachricht > Datum: Sun, 25 Jan 2009 02:04:47 + > Von: RW > An: dspam-community-de...@lists.sourceforge.net > CC: dspam-community-u...@lists.sourceforge.net, > dspam-community-de...@lists.sourceforge.net, > dspam-users@lists.nuclearelephant.com, dspam-...@lists.nuclearelephant.com > Betreff: Re: [Dspam-community-devel] I would appreciate some feedback > On Sun, 25 Jan 2009 00:24:52 +0100 > "Steve" wrote: > > > > > Original-Nachricht > > > Datum: Sat, 24 Jan 2009 16:36:16 + > > > Von: RW > > > An: dspam-community-de...@lists.sourceforge.net > > > CC: dspam-community-u...@lists.sourceforge.net, > > > dspam-community-de...@lists.sourceforge.net, > > > dspam-users@lists.nuclearelephant.com, > > > dspam-...@lists.nuclearelephant.com Betreff: Re: > > > [Dspam-community-devel] I would appreciate some feedback > > > > I was put-off using DSPAM for a long time because it wasn't clear > > > to me that it could even be used without mta integration, quarantine > > > etc. And the idea of managing spam through a webpage, or forwarding > > > addresses seems very clumsy compared with dragging to a learn-spam > > > folder or setting a flag. > > > > > Funny you mention this because that would require IMAP integration > > but above you complained about MTA integration. > > Firstly, learning from folders doesn't require any IMAP integration if > DSPAM is on the same machine as the folders. It doesn't even imply the > use of imap if the folders are local to your home directory. Bogofilter > and spamassassin can both learn whole folders in one go just by giving > the correct path. This is trivial to do from crontab without any > significant shell scripting experience. Bogofilter also has a perl > script that that will do training to exhaustion from two corpus folders, > which is even easier. Claws-mail and kmail both have bogofilter and > spamassassin plugins that that make them as easy to use as the Bayesian > filtering in Thunderbird. > Now I understand you. DSPAM can as well learn from folders. The basis functionality is there. The training script included into DSPAM does exactly that. Learning is not a big issue. The re-learning or re-classifying is a issue since it would require to extract the signature from the mails. It would not be a big issue to wrap that functionality into a shell script.. > Secondly, like a lot of people who run mail filtering software on > desktop computers, I'm not using an MTA, I use getmail to fetch mail > from pop/imap accounts and feed it through spam filters to dovecot. Lots > of people use getmail or fetchmail in this way. > DSPAM does not force you to use a MTA. You can run it without any MTA. A good example of that is the training script included in DSPAM. Running it does not require you to use a MTA at all. > > > I think it's a mistake to lump together all > > > the parts of DSPAM under a single project name, it gives the > > > impression that it's a Windows-style monolithic application. > > > > > Is it so important if it is monolithic or not? I personally care more > > about the result of the filtering and the level of maintenance it > > needs then about the question if it is monolithic or not. But that's > > just me. > > I would hope it is just you, I certainly wouldn't run DSPAM if it > dictated how I process my mail, and really did require me to > install an unwanted MTA and webserver, just to do simple > mail-filtering. > But the question about being monolithic or not has nothing to do with MTA/Webserver stuff. Or do I get that wrong? > > > If you read around a bit more, you may > > > find out about the hash driver, and home-directory support. > > > However, the hash driver support is much less mature, and unlike > > > Bogofilter and Spamassassin, DSPAM doesn't honour $HOME, so you > > > can't use virtual home directories. > > > > > What do you mean with "virtual home directories"? Could you explain > > me what this is? > > Pseudo home directories for virtual users. It's a pity this doesn't > work for another reason. According to the documentation only the hash > driver is fast enough to cope with some of DSPAM's more advanced > filtering options, > With "more advanced" you mean the SBPH tokenizer. Right? I would not say that the SBPH tokenizer is more advanced then the other tokenizers. It is sure one of the more complex tokenizers but the OSB tokenizer is not less complex and can store it's results in other storages then the hash driver. The point with SBPH is that it produces a lot of data. A mail with just 5 words would result in +/- 16 tokens with the SBPH tokenizer where the WORD tokenizer would do +/- 5 tokens, the CHAIN tokenizer would do +/- 9 tokens and the OSB tokenizer would create +/- 4 to 5 tokens. You could use SBPH and let it save the tokens in MySQL or PostgreSQL or any other storage DSPAM supports. But be prepared that the speed will be much slower then compared to the h
[dspam-users] Re: [Dspam-community-user] [Dspam-community-devel] I would appreciate some feedback
On Sun, 25 Jan 2009 02:04:47 + RW wrote: > On Sun, 25 Jan 2009 00:24:52 +0100 > "Steve" wrote: > > > > > Original-Nachricht > > > Datum: Sat, 24 Jan 2009 16:36:16 + > > > Von: RW > > > An: dspam-community-de...@lists.sourceforge.net > > > CC: dspam-community-u...@lists.sourceforge.net, > > > dspam-community-de...@lists.sourceforge.net, > > > dspam-users@lists.nuclearelephant.com, > > > dspam-...@lists.nuclearelephant.com Betreff: Re: > > > [Dspam-community-devel] I would appreciate some feedback > > > > I was put-off using DSPAM for a long time because it wasn't clear > > > to me that it could even be used without mta integration, > > > quarantine etc. And the idea of managing spam through a webpage, > > > or forwarding addresses seems very clumsy compared with dragging > > > to a learn-spam folder or setting a flag. Please help us with the documentation then ;-) > > Funny you mention this because that would require IMAP integration > > but above you complained about MTA integration. > > Firstly, learning from folders doesn't require any IMAP integration if > DSPAM is on the same machine as the folders. It doesn't even imply the > use of imap if the folders are local to your home directory. Indeed. > Bogofilter and spamassassin can both learn whole folders in one go > just by giving the correct path. This is trivial to do from crontab > without any significant shell scripting experience. Bogofilter also > has a perl script that that will do training to exhaustion from two > corpus folders, which is even easier. Claws-mail and kmail both have > bogofilter and spamassassin plugins that that make them as easy to > use as the Bayesian filtering in Thunderbird. Writing a dspam plugin for claws is on my to do for a looong time. But since I don't really need it ... > Secondly, like a lot of people who run mail filtering software on > desktop computers, I'm not using an MTA, I use getmail to fetch mail > from pop/imap accounts and feed it through spam filters to dovecot. > Lots of people use getmail or fetchmail in this way. Well, actually the percent is very small compared to the total. But rest assured we're not planning on forcing anyone to install half of gnome and half on kde plus two to database servers just to run dspam :-) > > > I think it's a mistake to lump together all > > > the parts of DSPAM under a single project name, it gives the > > > impression that it's a Windows-style monolithic application. > > > > > Is it so important if it is monolithic or not? I personally care > > more about the result of the filtering and the level of maintenance > > it needs then about the question if it is monolithic or not. But > > that's just me. > > I would hope it is just you, I certainly wouldn't run DSPAM if it > dictated how I process my mail, and really did require me to > install an unwanted MTA and webserver, just to do simple > mail-filtering. It doesn't and it won't. One of the point Steve was trying to make here is that with limited resources we have to prioritize what we work on. Dspam's code is a little monolithic; some things you can patch, other would require quite a rewrite. I don't like it but that's what we have to work with. Please keep in mind that we all do this for free, in our spare time (not that we know what spare time is, really). And as such there's no way we can accommodate everyone wishes not because we wouldn't like to, but because we don't have the time. So what will go in first is what we need and what you and other people send patches for; and some of the requested features; and what is it needed behind the scene to make it all work. There's been a lot of unseen work in the last two months that doesn't show up yet, but will hopefully impact the devel positively in the future. And one of the reasons we're encouraging everyone to use the request tracker is to give us a broader view of what needs to be done in order to plan our devel accordingly. > > > If you read around a bit more, you may > > > find out about the hash driver, and home-directory support. > > > However, the hash driver support is much less mature, and unlike > > > Bogofilter and Spamassassin, DSPAM doesn't honour $HOME, so you > > > can't use virtual home directories. > > > > > What do you mean with "virtual home directories"? Could you explain > > me what this is? > > Pseudo home directories for virtual users. It's a pity this doesn't > work for another reason. According to the documentation only the hash > driver is fast enough to cope with some of DSPAM's more advanced > filtering options, and AFAIK the hash driver doesn't support virtual > users. Making it honoring $HOME wouldn't be that easy if I understand correctly what you want. -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: [dspam-users] I would appreciate some feedback
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > This sounds good. Could you pleased add this a featur request at: > > https://sourceforge.net/tracker2/?group_id=250683&atid=1126468 Will do. > > I understand that you have actually implemented some of these? Is it > implemented entirely within the webui? Can you kindly submit your patches? Oh no, this is just wishes ;) I'm so not a programmer, I just like to implement stuff. Most of my ideas are taken from my everyday work-life where I use proprietary solutions, from non of which can do all the before mentioned wishes. I just collected all the good stuff and filled in where they all lacked features. The core of dspam is very good and outperform all other solutions I've worked with. The problem, or challenge, is to web a framework around it making it usable for "joe average" sysadmin with other things on his mind than complex MTA stuff. /Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl8dvMACgkQoJ3cLHC2TxrCRwCeKpYSPsMPJBxixq9a/YorNT95 lbkAn1l5SK5t+VRSgwVe2ZCyCJXC6RSY =HxXJ -END PGP SIGNATURE- !DSPAM:1011,497c7702150923663373461!
