Hi,
on my small Xen-virtualised server with 48 MiB RAM I use Postfix and
Dovecot, because the Debian administrators dislike qmail [1], which is in
my opinion despite some maintainability and code quality issues a quite
well designed software, because it mostly follows the UNIX principles.
Postfix is not able to sort my E-Mail into different Maildir folders and
after I looked at procmail's source code, I decided to use Dovecot's
LDA,
because it supports sieve via a plugin.
All in all it worked after some tweaking and Dovecot is now responsible
for authentication and delivery.
Furthermore I want to setup a spam filter and due to the memory
constraints I decided in favour of bogofilter (I made no real world tests,
but the authors claim that it's fast and has a small memory footprint).
My first idea was train bogofilter via a cronjob that runs bogofilter
for each E-Mail in my spam folder and deletes them afterwards. Then I
stumbled upon the dovecot antispam [2] plugin and quickly wrote a backend
for bogofilter. During the development I realised that bogofilter has
to update the X-Bogosity header of the reclassified E-Mails. Johannes
Berg told me that he wasn't sure whether dovecot would be able to do
this and recommended to ask this on the mailing list.
An other problem is that each mail needs to be initially classified and
due to the fact that sieve is not able to execute external programmes,
deliver has to do this task. I'm currently thinking of possibilities to
implement this, so far I came up with the following:
1. Write a generic pipe plugin which can execute an arbitrary number of
programmes. The problem with this is that I'm not sure how to
integrate this is in Dovecot's configuration file. I thought of
something like this: pipe = prg1 | prg2
2. Write a bogofilter-specific plugin for this.
Anyhow I would like to take this opportunity to criticise Dovecot
for being a bloated (unnecessary abstractions, verbose, pseudo
object-oriented, ...), non-suckless [3] and non-unixish (plugin
architecture, monolithic design, ...) software which in return works
quite well and stable so far.
I appreciate any suggestions, ideas or criticism. I would really like
to finish configuring my mail server as soon as possible.
Regards,
Matthias-Christian
[1] http://smarden.org/pape/Debian/1215531259.4854_332.werc
[2] http://johannes.sipsolutions.net/Projects/dovecot-antispam
[3] http://www.suckless.org/common/
On Sun, 2008-11-09 at 22:39 +0100, Matthias-Christian Ott wrote:> An other problem is that each mail needs to be initially classified and > due to the fact that sieve is not able to execute external programmes, > deliver has to do this task. I'm currently thinking of possibilities to > implement this, so far I came up with the following: > > 1. Write a generic pipe plugin which can execute an arbitrary number of > programmes. The problem with this is that I'm not sure how to > integrate this is in Dovecot's configuration file. I thought of > something like this: pipe = prg1 | prg2You do not need a plugin if you do the classification before the delivery: MTA | classification | LDA Would that be an option? Regards, Thorsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 489 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20081109/978e0a5f/attachment-0002.bin>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thorsten Vollmer wrote:> On Sun, 2008-11-09 at 22:39 +0100, Matthias-Christian Ott wrote: >> An other problem is that each mail needs to be initially classified and >> due to the fact that sieve is not able to execute external programmes, >> deliver has to do this task. I'm currently thinking of possibilities to >> implement this, so far I came up with the following: >> >> 1. Write a generic pipe plugin which can execute an arbitrary number of >> programmes. The problem with this is that I'm not sure how to >> integrate this is in Dovecot's configuration file. I thought of >> something like this: pipe = prg1 | prg2 > > You do not need a plugin if you do the classification before the > delivery: MTA | classification | LDAWith postfix, just add bogofilter as transport to master.cf and make it the 'mailbox_transport'. The problem with modifying the mail after reclassification persists, hope this can be solved. Then I could also finally move from postfix-procmail-bogofilter-cron-dovecot to postfix-deliver-antispam-bogofilter-dovecot. :) Patrick. - -- STAR Software (Shanghai) Co., Ltd. http://www.star-group.net/ Phone: +86 (21) 3462 7688 x 826 Fax: +86 (21) 3462 7779 PGP key: E883A005 https://stshacom1.star-china.net/keys/patrick_nagel.asc Fingerprint: E09A D65E 855F B334 E5C3 5386 EF23 20FC E883 A005 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFJF5Rh7yMg/OiDoAURAkE4AJ4zYh/J4WKCsN/xwGGKA66N3sKNQwCeNDrh prjS37amcH+vDH1kwyqyDxY=f9Rm -----END PGP SIGNATURE-----
Matthias-Christian Ott wrote:> Hi, > on my small Xen-virtualised server with 48 MiB RAM I use Postfix and > Dovecot, because the Debian administrators dislike qmail [1], which is in > my opinion despite some maintainability and code quality issues a quite > well designed software, because it mostly follows the UNIX principles. > > Postfix is not able to sort my E-Mail into different Maildir folderspostfix can, with the help of other programs. "unix principles", you know ;-p postfix can pass mail to any program you want. A wrapper would do something like - pass the message to a filter. - save the filtered message to a temp file - parse the temp file to determine the destination folder - run dovecot deliver with the -m option to specify the destination folder of course, you need to catch errors. maildrop may be a better tool at this job, though.> and > after I looked at procmail's source code, I decided to use Dovecot's LDA, > because it supports sieve via a plugin. > > All in all it worked after some tweaking and Dovecot is now responsible > for authentication and delivery. > > Furthermore I want to setup a spam filter and due to the memory > constraints I decided in favour of bogofilter (I made no real world tests, > but the authors claim that it's fast and has a small memory footprint). > > My first idea was train bogofilter via a cronjob that runs bogofilter > for each E-Mail in my spam folder and deletes them afterwards. Then I > stumbled upon the dovecot antispam [2] plugin and quickly wrote a backend > for bogofilter. During the development I realised that bogofilter has > to update the X-Bogosity header of the reclassified E-Mails. Johannes > Berg told me that he wasn't sure whether dovecot would be able to do > this and recommended to ask this on the mailing list. >one possibility would be - deliver the reclassified message - if ok, delete the original one. this means the plugin needs to know the file location.> An other problem is that each mail needs to be initially classified and > due to the fact that sieve is not able to execute external programmes, > deliver has to do this task. I'm currently thinking of possibilities to > implement this, so far I came up with the following: > > 1. Write a generic pipe plugin which can execute an arbitrary number of > programmes. The problem with this is that I'm not sure how to > integrate this is in Dovecot's configuration file. I thought of > something like this: pipe = prg1 | prg2 >keep it simple ... if you need to pipe between multiple programs, just use shell wrappers.> 2. Write a bogofilter-specific plugin for this. >I guess we will end up with a foo-specific plugin, for every possible foo filter. A generic plugin is better even if that means executing shell wrappers.> Anyhow I would like to take this opportunity to criticise Dovecot > for being a bloated (unnecessary abstractions, verbose, pseudo > object-oriented, ...), non-suckless [3] and non-unixish (plugin > architecture, monolithic design, ...) software which in return works > quite well and stable so far. ><ot> non-unixish? well - plugins are simply loadable libraries. if you think they are windowish, you are wrong. They fit perfectly into the "simple pieces of code to do fewtasks" philosophy. just because dynamic libs weren't usable a long time ago doesn't mean unix should stick with old stuff. - the unix kernel is monolithic. loadable modules support has been added but the kernel is still a large piece of code. - and before I forget, my favourite provaction: unix is obsolete ;-p </ot>> I appreciate any suggestions, ideas or criticism. I would really like > to finish configuring my mail server as soon as possible. > > Regards, > Matthias-Christian > > [1] http://smarden.org/pape/Debian/1215531259.4854_332.werc > [2] http://johannes.sipsolutions.net/Projects/dovecot-antispam > [3] http://www.suckless.org/common/