[Dovecot] Dovecot and Bogofilter
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:
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
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:
- 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 | LDA
Would that be an option?
Regards, Thorsten
-----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:
- 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 | LDA
With 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-----
Patrick Nagel wrote:
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:
- 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 | LDA
With postfix, just add bogofilter as transport to master.cf and make it the 'mailbox_transport'.
Does Postfix understand the pipe syntax? If so everything would be fine.
Regards, Matthias-Christian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matthias-Christian Ott wrote:
Patrick Nagel wrote:
With postfix, just add bogofilter as transport to master.cf and make it the 'mailbox_transport'.
Does Postfix understand the pipe syntax? If so everything would be fine.
Umm, well, it "pipes" the mail through the command specified as 'mail_transport' - don't know if that works with shell script style pipes (|) directly - but in any case you could easily create a wrapper shell script.
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
iD8DBQFJF/TX7yMg/OiDoAURArRMAJ98wma7/pjbcS7bcUCV1DqMBszUSQCgl4ay GxESbmr50vW8/OMyZGXqjqY= =g2O6 -----END PGP SIGNATURE-----
On Mon, 10 Nov 2008, Patrick Nagel wrote:
Matthias-Christian Ott wrote:
Patrick Nagel wrote:
With postfix, just add bogofilter as transport to master.cf and make it the 'mailbox_transport'.
Does Postfix understand the pipe syntax? If so everything would be fine.
Umm, well, it "pipes" the mail through the command specified as 'mail_transport' - don't know if that works with shell script style pipes (|) directly - but in any case you could easily create a wrapper shell script.
Postfix's pipe(8) transport runs the command directly rather than spawning /bin/sh; so it does not support shell expansions such as pipes.
-- Matthias Andree
On Mon, 10 Nov 2008, Patrick Nagel wrote:
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:
- 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 | LDA
With 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. :)
Hi,
it's not quite clear to me how this would work with bogofilter as a mailbox_transport - bogofilter isn't designed to do final delivery.
It's also not quite clear to me why people would use procmail. Although defended by its maintainers, it's an unusable and unconfigurable piece of software from ancient past -- getting error handling right in procmail is next to impossible, requires forfeiting :e rules and bloating procmailrc with explicit error handling recipes.
If you want something and Dovecot's deliver doesn't fit your needs, consider maildrop, http://www.courier-mta.org/maildrop/
Bogofilter has an "integrating-with-postfix" document in the doc/ directory that shows how to use Postfix's content_filter and does not need procmail. Unfortunately, it does not show how to integrate updates; there are several approaches to achieve that. One way is to use separate mailboxes where users can send mail to and where they are picked up by cron - best when using Dovecot is probably to make users move spam into particular folders via IMAP.
I'm happy to update or add instructions to bogofilter, but may not have the time to do sufficient R&D myself in the near future to obtain relevant knowledge that I could document myself.
-- Matthias Andree
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Matthias
Matthias Andree wrote:
On Mon, 10 Nov 2008, Patrick Nagel wrote:
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. :)
Hi,
it's not quite clear to me how this would work with bogofilter as a mailbox_transport - bogofilter isn't designed to do final delivery.
It's also not quite clear to me why people would use procmail. Although defended by its maintainers, it's an unusable and unconfigurable piece of software from ancient past -- getting error handling right in procmail is next to impossible, requires forfeiting :e rules and bloating procmailrc with explicit error handling recipes.
You're right, and that's why I don't want to continue using it. It had a lot of security issues, and the syntax of procmailrc looked like a bad joke to me when I encountered it for the first time.
Not being able to pipe mail through an arbitrary program surely makes sieve more secure, but it also makes things much more complicated sometimes. Also I think beginners tend to use procmail, just because in many guides / tutorials / howtos it's the LDA of choice. (I, for example, started out with this howto: http://www.gentoo-wiki.info/HOWTO_Email_System_for_the_Home_Network )
If you want something and Dovecot's deliver doesn't fit your needs, consider maildrop, http://www.courier-mta.org/maildrop/
I didn't even know about it until very recently. ;)
Bogofilter has an "integrating-with-postfix" document in the doc/ directory that shows how to use Postfix's content_filter and does not need procmail. Unfortunately, it does not show how to integrate updates; there are several approaches to achieve that. One way is to use separate mailboxes where users can send mail to and where they are picked up by cron - best when using Dovecot is probably to make users move spam into particular folders via IMAP.
That's how I'm doing it, but surely the Antispam plugin is a nicer (and more user-friendly) approach - the classification direction (Spam->Ham or Ham->Spam) is determined by the source and target mailbox.
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
iD8DBQFJF/pB7yMg/OiDoAURAmNyAJ9rFGEPU/mylzF9ec+I07sfMo2q6QCgnGbQ j4SQHfYXV3zt7FNVXDMA+YE= =qeP/ -----END PGP SIGNATURE-----
Patrick Nagel wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Matthias
Matthias Andree wrote:
On Mon, 10 Nov 2008, Patrick Nagel wrote:
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. :)
Hi,
it's not quite clear to me how this would work with bogofilter as a mailbox_transport - bogofilter isn't designed to do final delivery.
It's also not quite clear to me why people would use procmail. Although defended by its maintainers, it's an unusable and unconfigurable piece of software from ancient past -- getting error handling right in procmail is next to impossible, requires forfeiting :e rules and bloating procmailrc with explicit error handling recipes.
You're right, and that's why I don't want to continue using it. It had a lot of security issues, and the syntax of procmailrc looked like a bad joke to me when I encountered it for the first time.
I think the syntax is not that worse if got a bit used to it. Even this exitcode issues are just a matter of standardisation. But look at this (taken from procmail.c):
[...] int main(argc,argv)int argc;const char*const argv[]; { register char*chp,*chp2; #if 0 /* enable this if you want to trace procmail */ kill(getpid(),SIGSTOP);/*raise(SIGSTOP);*/ #endif newid(); ;{ int presenviron,override;char*fromwhom=0; const char*idhint=0;gid_t egid=getegid(); presenviron=Deliverymode=mailfilter=override=0; Openlog(procmailn,LOG_PID,LOG_MAIL); /* for the syslogd */ if(argc) /* sanity check, any argument at all? */ { Deliverymode=!!strncmp(lastdirsep(argv0=argv[0]),procmailn, STRLEN(procmailn)); [...]
The whole source code looks like this. I mean, who is supposed to read this and who wrote this? I don't want to use such software, it's a nightmare.
Not being able to pipe mail through an arbitrary program surely makes sieve more secure, but it also makes things much more complicated sometimes. Also I think beginners tend to use procmail, just because in many guides / tutorials / howtos it's the LDA of choice. (I, for example, started out with this howto: http://www.gentoo-wiki.info/HOWTO_Email_System_for_the_Home_Network )
If you want something and Dovecot's deliver doesn't fit your needs, consider maildrop, http://www.courier-mta.org/maildrop/
I didn't even know about it until very recently. ;)
$ aptitude search ~dprocmail [...] p maildrop - mail delivery agent with filtering abilities [...]
That's how I found it ;).
Bogofilter has an "integrating-with-postfix" document in the doc/ directory that shows how to use Postfix's content_filter and does not need procmail. Unfortunately, it does not show how to integrate updates; there are several approaches to achieve that. One way is to use separate mailboxes where users can send mail to and where they are picked up by cron - best when using Dovecot is probably to make users move spam into particular folders via IMAP.
That's how I'm doing it, but surely the Antispam plugin is a nicer (and more user-friendly) approach - the classification direction (Spam->Ham or Ham->Spam) is determined by the source and target mailbox.
You could simply run the cron on your SPAM folder and also delete old spam mail during that run. That's how I initially planned it.
Patrick.
Regards, Matthias-Christian
Matthias Andree wrote:
On Mon, 10 Nov 2008, Patrick Nagel wrote:
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:
- 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 | LDA
With 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. :)
Hi,
it's not quite clear to me how this would work with bogofilter as a mailbox_transport - bogofilter isn't designed to do final delivery.
It's also not quite clear to me why people would use procmail. Although defended by its maintainers, it's an unusable and unconfigurable piece of software from ancient past -- getting error handling right in procmail is next to impossible, requires forfeiting :e rules and bloating procmailrc with explicit error handling recipes.
If you haven't puked today, just look at their source code and programming style. I think the configuration and exit code handling is not the worst problem in this software.
If you want something and Dovecot's deliver doesn't fit your needs, consider maildrop, http://www.courier-mta.org/maildrop/
Looks a bit bloated to me.
Bogofilter has an "integrating-with-postfix" document in the doc/ directory that shows how to use Postfix's content_filter and does not need procmail. Unfortunately, it does not show how to integrate updates; there are several approaches to achieve that. One way is to use separate mailboxes where users can send mail to and where they are picked up by cron - best when using Dovecot is probably to make users move spam into particular folders via IMAP.
I read that document some days ago, but the content_filter approach looks strange to me, because they use sendmail to reinject the E-Mail in the queue.
Regards, Matthias-Christian
On Mon, 10 Nov 2008, Matthias-Christian Ott wrote:
it's not quite clear to me how this would work with bogofilter as a mailbox_transport - bogofilter isn't designed to do final delivery.
It's also not quite clear to me why people would use procmail. Although defended by its maintainers, it's an unusable and unconfigurable piece of software from ancient past -- getting error handling right in procmail is next to impossible, requires forfeiting :e rules and bloating procmailrc with explicit error handling recipes.
If you haven't puked today, just look at their source code and programming style. I think the configuration and exit code handling is not the worst problem in this software.
I know that I don't want to read that code. It looks like something in between a "dirty C tricks to squeeze the final cycle from compilers that predate even peephole optimization" and a submission to obfuscated C contest. User interface? Fallthrough behaviour on delivery errors? Nevermind how randomly mail is spread across your mailboxen :-)
If you want something and Dovecot's deliver doesn't fit your needs, consider maildrop, http://www.courier-mta.org/maildrop/
Looks a bit bloated to me.
Nevermind the bloated build, it works like a charm and has a rather concise source (if you read a bit of C++, that is).
Bogofilter has an "integrating-with-postfix" document in the doc/ directory that shows how to use Postfix's content_filter and does not need procmail. Unfortunately, it does not show how to integrate updates; there are several approaches to achieve that. One way is to use separate mailboxes where users can send mail to and where they are picked up by cron - best when using Dovecot is probably to make users move spam into particular folders via IMAP.
I read that document some days ago, but the content_filter approach looks strange to me, because they use sendmail to reinject the E-Mail in the queue.
Well, I co-authored that document, but it's just a refined version of the "Simple Content Filter" as per Postfix's FILTER_README... check http://www.postfix.org/FILTER_README.html#simple_filter
Postfix's content_filter=... setting diverts the mail from regular routing, and the sendmail command (without -t!) reinjects with original headers and recipients (from envelope) for then regular routing.
Looks scary to some, but works.
BTDT, although I've moved on to amavisd-new since. Saves the hassle of training spamfilters with virucide fodder...
-- Matthias Andree
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 10 Nov 2008, Matthias-Christian Ott wrote:
If you want something and Dovecot's deliver doesn't fit your needs, consider maildrop, http://www.courier-mta.org/maildrop/
Looks a bit bloated to me.
I'm not sure if I missed that part about the shell script, someone suggested.
You could use something like:
#!/bin/bash
bogofilter | dovecot-deliver "$@"
replacing the orginal dovecot-deliver in the conf. If bogofilter does not support to pipe the message through, there will be other ways.
Besides that you have just one additional exec() (the shell) for each delivery and you already inject the modified message to deliver. Or did I misunderstood the problem, and you want the antispam to change the message, when a mail is copied into / out of the SPAM folder via IMAP?
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJGXAGVJMDrex4hCIRAhlvAKCcIA6KcRxhdIj1oPBam/pcWUu3uwCgvw0T sgzJ2i4nzHcxR+UCY591n5w= =xLhH -----END PGP SIGNATURE-----
Steffen Kaiser wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 10 Nov 2008, Matthias-Christian Ott wrote:
If you want something and Dovecot's deliver doesn't fit your needs, consider maildrop, http://www.courier-mta.org/maildrop/
Looks a bit bloated to me.
I'm not sure if I missed that part about the shell script, someone
suggested.You could use something like:
#!/bin/bash
bogofilter | dovecot-deliver "$@"
replacing the orginal dovecot-deliver in the conf. If bogofilter does not support to pipe the message through, there will be other ways.
Besides that you have just one additional exec() (the shell) for each
delivery and you already inject the modified message to deliver. Or did I misunderstood the problem, and you want the antispam to change the
message, when a mail is copied into / out of the SPAM folder via IMAP?
Yes, but currently it doesn't matter, because I decided to not use spam filtering at the moment. Mutt just sucks and all this crappy mail software that's still around. I can't see this from a pragmatic point of view anymore, it's so fucked up.
It just annoys me, I'll keep my mail server at low traffic and avoid to use all these things. This whole issue just showed me yet another time that UNIX is really dead and forgotten. I have better things to do than just configuring my computers, finding workarounds etc. I wish we could somehow turn the clocks back 30 years and do all this crap right. In my opinion the whole software industry (including the Free Software community which degenerated into a periphery position) is just a bloated bubble that will disastrously collapse at some point of time. I'm yet another time glad that I don't have to work in this business.
So I think we can regard this issue as resolved.
Sorry for annoying you with my pessimistic opinion about software, but it just bothers that after nearly four centuries of UNIX that nobody can get simple tasks like mail delivery right (Yes, I know there are workarounds, but there are tons of magazines that deal with workarounds for some big proprietary operating system and it's still pain to use it).
Bye,
- -- Steffen Kaiser
Regards, Matthias-Christian
For the last four weeks or so, I have been getting very occasional reports of "stuck" messages from three users of my mail server. When this occurs, Thunderbird's status display in the bottom left will alternate rapidly between "Opening folder" and "Checking mail server capabilities", and will never display the message.
I'm not sure if this is something which crept into a recent release of Dovecot, or a problem with T'bird, or something else entirely. I had suspected corrupt messages the first time or two, and was once able to copy such a message into my own "Maildir/cur" directory and have it fail for me. Since then I've not been able to replicate this feat. I also thought that it might have been the Dovecot indices becoming corrupt but today I tried purging them for an affected user, and the problem still showed up. In addition, for the first time today that user reported a message which originally (as of 6 Nov. 2008) worked fine but today demonstrates the issue.
If anyone has seen anything like this or has suggestions to try, please let me know. If necessary I can go to full debug-logging with Dovecot but I'd prefer to avoid that if possible :)
Thanks, Allen
-- Allen Belletti allen@isye.gatech.edu 404-894-6221 Phone Industrial and Systems Engineering 404-385-2988 Fax Georgia Institute of Technology
On 11/11/2008 12:52 PM, Allen Belletti wrote:
I'm not sure if this is something which crept into a recent release of Dovecot, or a problem with T'bird, or something else entirely. I had suspected corrupt messages the first time or two, and was once able to copy such a message into my own "Maildir/cur" directory and have it fail for me. Since then I've not been able to replicate this feat. I also thought that it might have been the Dovecot indices becoming corrupt but today I tried purging them for an affected user, and the problem still showed up. In addition, for the first time today that user reported a message which originally (as of 6 Nov. 2008) worked fine but today demonstrates the issue.
If anyone has seen anything like this or has suggestions to try, please let me know. If necessary I can go to full debug-logging with Dovecot but I'd prefer to avoid that if possible :)
Maybe some basic info would be helpful?
Dovecot version? Output of dovecot -n?
--
Best regards,
Charles
On Tue, 2008-11-11 at 12:52 -0500, Allen Belletti wrote:
I'm not sure if this is something which crept into a recent release of Dovecot, or a problem with T'bird, or something else entirely. I had suspected corrupt messages the first time or two, and was once able to copy such a message into my own "Maildir/cur" directory and have it fail for me. Since then I've not been able to replicate this feat. I also thought that it might have been the Dovecot indices becoming corrupt but today I tried purging them for an affected user, and the problem still showed up. In addition, for the first time today that user reported a message which originally (as of 6 Nov. 2008) worked fine but today demonstrates the issue.
If there's a problem with indexes, Dovecot most likely would have logged an error message. Do you see any errors logged?
If anyone has seen anything like this or has suggestions to try, please let me know. If necessary I can go to full debug-logging with Dovecot but I'd prefer to avoid that if possible :)
Knowing what Thunderbird and Dovecot talk to each others would be pretty much the only way to know what's going on. http://wiki.dovecot.org/Debugging/Rawlog would help.
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 folders
postfix 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 the file location.
- deliver the reclassified message
- if ok, delete the original one. this means the plugin needs to know
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:
- 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.
- 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/
participants (9)
-
Allen Belletti
-
Charles Marcus
-
Matthias Andree
-
Matthias-Christian Ott
-
mouss
-
Patrick Nagel
-
Steffen Kaiser
-
Thorsten Vollmer
-
Timo Sirainen