[Dovecot] new antispam plugin
Sparked from the discussion on the list, I've put my antispam plugin into git and split up the code into a frontend and possibly multiple backends. See http://git.sipsolutions.net/dovecot-antispam.git/ (URL functions as both gitweb and git URL)
Andreas, I took your README file and adjusted it, I hope you don't mind. I didn't fork from your git tree because you'd already implemented the libdspam backend there. Maybe you could take a look at the new backend/frontend separation and implement a libdspam backend.
Aria, it should be possible to write a spamassassin plugin, quite easily if spamassassin supports training based on signatures, not quite so easily otherwise though I intend to plan this.
Timothy, you could write the mysql logger as a backend too.
I take patches :)
Oh and as always thanks to Timo for implementing such a nice server and string, memory and mail handling API.
johannes
On Sun, 2007-09-30 at 16:04 +0200, Johannes Berg wrote:
Sparked from the discussion on the list, I've put my antispam plugin into git and split up the code into a frontend and possibly multiple backends. See http://git.sipsolutions.net/dovecot-antispam.git/ (URL functions as both gitweb and git URL)
Just added a new feature that should help those who need --user given on the dspam command line:
http://git.sipsolutions.net/?p=dovecot-antispam.git;a=commit;h=b61c062501065...
--->%--- dspam-exec backend: allow extra arguments
This allows people who need --user given on the command line to add something like this to the configuration:
antispam_dspam_args = --user;%uwhere the semicolon is the separator between arguments to build the dspam command line as indicated by the dspam manual page:
dspam [--user user1 user2 ...]---%<---
johannes
On 16:04:18 2007-09-30 Johannes Berg johannes@sipsolutions.net wrote:
Sparked from the discussion on the list, I've put my antispam plugin into git and split up the code into a frontend and possibly multiple backends. See http://git.sipsolutions.net/dovecot-antispam.git/ (URL functions as both gitweb and git URL)
Hmm if I'm reading the code correctly one can define multiple spam folders?
Would be nice to include a sample config i.e. all the variables that can be set and possible settings etc...
-- Andraž "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker
Be sure brain is in gear before engaging mouth.
Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
On Sun, 2007-09-30 at 18:12 +0200, "Andraž 'ruskie' Levstik" wrote:
On 16:04:18 2007-09-30 Johannes Berg johannes@sipsolutions.net wrote:
Sparked from the discussion on the list, I've put my antispam plugin into git and split up the code into a frontend and possibly multiple backends. See http://git.sipsolutions.net/dovecot-antispam.git/ (URL functions as both gitweb and git URL)
Hmm if I'm reading the code correctly one can define multiple spam folders?
Would be nice to include a sample config i.e. all the variables that can be set and possible settings etc...
http://git.sipsolutions.net/?p=dovecot-antispam.git;a=commitdiff;h=658e7fe97...
johannes
On 18:33:33 2007-09-30 Johannes Berg johannes@sipsolutions.net wrote:
On Sun, 2007-09-30 at 18:12 +0200, "Andraž 'ruskie' Levstik" wrote:
On 16:04:18 2007-09-30 Johannes Berg johannes@sipsolutions.net wrote:
Sparked from the discussion on the list, I've put my antispam plugin into git and split up the code into a frontend and possibly multiple backends. See http://git.sipsolutions.net/dovecot-antispam.git/ (URL functions as both gitweb and git URL)
Hmm if I'm reading the code correctly one can define multiple spam folders?
Would be nice to include a sample config i.e. all the variables that can be set and possible settings etc...
http://git.sipsolutions.net/?p=dovecot-antispam.git;a=commitdiff;h=658e7fe97...
Many thanks...
btw I am wondering why exactly do you need the dovecot source and wouldn't just the development headers be enough to build it?
There's quite a bit of things installed into: /usr/include/dovecot
When one passes --enable-header-install to configure...
-- Andraž "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker
Be sure brain is in gear before engaging mouth.
Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
On Sun, 2007-09-30 at 18:43 +0200, "Andraž 'ruskie' Levstik" wrote:
btw I am wondering why exactly do you need the dovecot source and wouldn't just the development headers be enough to build it?
There's quite a bit of things installed into: /usr/include/dovecot
When one passes --enable-header-install to configure...
Dunno. Debian doesn't ship a dev package so I haven't tried.
johannes
On Sun, 2007-09-30 at 16:04 +0200, Johannes Berg wrote:
Timothy, you could write the mysql logger as a backend too.
I looked into that using the dict API but had quite a few problems. See here: http://git.sipsolutions.net/?p=dovecot-antispam.git;a=commitdiff;h=306addd1d...
johannes
I just implemented a new feature with which you can easily implement pristine training or such:
http://git.sipsolutions.net/?p=dovecot-antispam.git;a=commitdiff;h=4ee8b72da...
johannes
Johannes Berg wrote:
I just implemented a new feature with which you can easily implement pristine training or such:
http://git.sipsolutions.net/?p=dovecot-antispam.git;a=commitdiff;h=4ee8b72da...
Hi Johannes,
I've just implemented the dspam library backend. I've found some problems.
PACKAGE_VERSION is only defined if you're building in the dovecot source tree. It is set in the config.h file.
If you're building against libdspam you can't define -DHAVE_CONFIG_H or dspam will look for its own dpsam config.h.
I haven't tested the plugin yet, cause I'm traveling atm and on this wifi I can't connect to our VPN enviroment to access my workstation to compile it with the right system.
johannes
Best regards,
-- andreas-- http://www.cynapses.org/ - cybernetic synapses
On 2007-10-02 05:51:38 +0200, Andreas Schneider wrote:
Johannes Berg wrote:
I just implemented a new feature with which you can easily implement pristine training or such:
http://git.sipsolutions.net/?p=dovecot-antispam.git;a=commitdiff;h=4ee8b72da...
Hi Johannes,
I've just implemented the dspam library backend. I've found some problems.
PACKAGE_VERSION is only defined if you're building in the dovecot source tree. It is set in the config.h file.
If you're building against libdspam you can't define -DHAVE_CONFIG_H or dspam will look for its own dpsam config.h.
I haven't tested the plugin yet, cause I'm traveling atm and on this wifi I can't connect to our VPN enviroment to access my workstation to compile it with the right system.
packages should never ever ship config.h conflicting macros like PACKAGE_VERSIONS and HAVE_* can cause a lot of trouble.
darix-- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
On 05:51:38 2007-10-02 Andreas Schneider mail@cynapses.org wrote:
Johannes Berg wrote:
I just implemented a new feature with which you can easily implement pristine training or such:
http://git.sipsolutions.net/?p=dovecot-antispam.git;a=commitdiff;h=4ee8b72da...
Hi Johannes,
I've just implemented the dspam library backend. I've found some problems.
PACKAGE_VERSION is only defined if you're building in the dovecot source tree. It is set in the config.h file.
If you're building against libdspam you can't define -DHAVE_CONFIG_H or dspam will look for its own dpsam config.h.
I haven't tested the plugin yet, cause I'm traveling atm and on this wifi I can't connect to our VPN enviroment to access my workstation to compile it with the right system.
I'd like to point out that dovecot infact installs it's own config.h via the --enable-headers-install option(which I think should be the default and not an option). Here are the lists of headers on my system...
/usr/include/dspam /usr/include/dspam/buffer.h /usr/include/dspam/config.h /usr/include/dspam/config_shared.h /usr/include/dspam/decode.h /usr/include/dspam/diction.h /usr/include/dspam/error.h /usr/include/dspam/heap.h /usr/include/dspam/ldap_client.h /usr/include/dspam/libdspam.h /usr/include/dspam/libdspam_objects.h /usr/include/dspam/nodetree.h /usr/include/dspam/pref.h /usr/include/dspam/storage_driver.h /usr/include/dspam/tokenizer.h
/usr/include /usr/include/dovecot /usr/include/dovecot/config.h /usr/include/dovecot/src /usr/include/dovecot/src/auth /usr/include/dovecot/src/auth/auth-cache.h . . .
-- Andraž "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker
Be sure brain is in gear before engaging mouth.
Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
Hi,
PACKAGE_VERSION is only defined if you're building in the dovecot source tree. It is set in the config.h file.
Hmm. That's too bad, it'd be nice to have the dovecot version built into the plugin.
If you're building against libdspam you can't define -DHAVE_CONFIG_H or dspam will look for its own dpsam config.h.
Hah. Hmm we can do some makefile tricks to only define that for antispam-plugin.c rather than the backends.
johannes
Johannes Berg wrote:
Hi,
Hello,
If you're building against libdspam you can't define -DHAVE_CONFIG_H or dspam will look for its own dpsam config.h.
Hah. Hmm we can do some makefile tricks to only define that for antispam-plugin.c rather than the backends.
This would be a workaround but not really nice. What about reading the output of dovecot --version and adding it.
I've updated the plugin it should work now. The problem is that it always fails for me. It makes no difference if I use the dpsam-exec or dspam-library backend. It looks like call_dspam() is never called.
It reports "Failed to call dspam". I've added a debug message at the beginning of call_dspam() and it gets never displayed.
johannes
-- andreas-- http://www.cynapses.org/ - cybernetic synapses
Hi,
This would be a workaround but not really nice. What about reading the output of dovecot --version and adding it.
Hmm. No, we need the version we're building against not the running version.
I've updated the plugin it should work now. The problem is that it always fails for me. It makes no difference if I use the dpsam-exec or dspam-library backend. It looks like call_dspam() is never called.
Hmm. There was a bug in the crm114 backend after I'd copied it, but I need to verify in the dspam-exec backend. But that shouldn't affect your dspam-library.
It reports "Failed to call dspam". I've added a debug message at the beginning of call_dspam() and it gets never displayed.
Weird. I'll take a look. crm114-exec definitely works, might be worth comparing. I'm out starting immediately until tomorrow night, will take a look then.
johannes
Johannes Berg wrote:
Weird. I'll take a look. crm114-exec definitely works, might be worth comparing. I'm out starting immediately until tomorrow night, will take a look then.
dspam-exec doesn't work too.
johannes
-- andreas-- http://www.cynapses.org/ - cybernetic synapses
On Tue, 2007-10-02 at 21:39 +0200, Andreas Schneider wrote:
Johannes Berg wrote:
Weird. I'll take a look. crm114-exec definitely works, might be worth comparing. I'm out starting immediately until tomorrow night, will take a look then.
dspam-exec doesn't work too.
Are you using DEBUG=stderr by any chance with dspam-exec? That will break it, stupid of me to put the debug call there.
johannes
On Wed, 2007-10-03 at 19:15 +0200, Johannes Berg wrote:
On Tue, 2007-10-02 at 21:39 +0200, Andreas Schneider wrote:
Johannes Berg wrote:
Weird. I'll take a look. crm114-exec definitely works, might be worth comparing. I'm out starting immediately until tomorrow night, will take a look then.
dspam-exec doesn't work too.
Are you using DEBUG=stderr by any chance with dspam-exec? That will break it, stupid of me to put the debug call there.
And I just tested with DEBUG=syslog and we definitely get to the debug() line that prints the command to invoke (used DEBUG=syslog). I'll take another look at your backend.
johannes
On Tue, 2007-10-02 at 20:26 +0200, Andreas Schneider wrote:
If you're building against libdspam you can't define -DHAVE_CONFIG_H or dspam will look for its own dpsam config.h.
Ok I looked into this and it's really crappy. dovecot really *requires* its config.h because of compat.h; you added a bunch of things to the CFLAGS line but it's totally different here so fails with this error:
/usr/include/stdint.h:111: error: conflicting types for ‘uint_fast32_t’ ../dovecot-1.0.5/src/lib/compat.h:46: error: previous declaration of ‘uint_fast32_t’ was here /usr/include/stdint.h:141: error: conflicting types for ‘uintmax_t’ ../dovecot-1.0.5/src/lib/compat.h:38: error: previous declaration of ‘uintmax_t’ was here
In fact, I can't easily make it compile at all without config.h. Maybe we can have dovecot install its config.h as dovecot-config.h and simply include it first thing everywhere?
Right now it looks as though we'll have to compile the different files with different CFLAGS because otherwise I can't guarantee that the other files can compile.
johannes
participants (4)
-
"Andraž 'ruskie' Levstik"
-
Andreas Schneider
-
Johannes Berg
-
Marcus Rueckert