[Dovecot] UW-IMAP style mbox snarfing from /var/mail/ to ~/mbox
http://dovecot.org/patches/mbox-snarf-plugin.c
Also committed to CVS HEAD.
Usage:
mail_location = mbox:~/mail:INBOX=/var/mail/%u
protocol imap { mail_plugins = mbox_snarf } protocol pop3 { mail_plugins = mbox_snarf }
plugin { mbox_snarf = ~/mbox }
If ~/mbox doesn't exist, nothing special is done.
If ~/mbox exists, it's treated as INBOX and mails are moved from /var/mail/%u whenever the mailbox is synchronized. If all the messages couldn't be copied, for example because of out of quota, then none of the messages are copied. I suppose that could be a problem. It might be possible to fix that by changing:
if (mailbox_copy(dest_trans, mail, 0, NULL, NULL) < 0) {
if (!mail->expunged) {
ret = -1;
break;
}
}
to just:
if (mailbox_copy(dest_trans, mail, 0, NULL, NULL) < 0) {
if (!mail->expunged)
break;
}
But I'm not sure about that. Try and tell me. :)
Timo Sirainen wrote:
Hi,
I just tried to setup this plugin on a Debian Etch machine but it crashes the Dovecot daemons.
Debian Etch uses the sourcecode of Dovecot 1.0rc15 + some patches.
I rebuilt the Dovecot packages -common, -imapd and -pop3d using
apt-get install apt-build apt-build build-source dovecot-common
and installed them. Then I compiled the .c file mentioned above inside the sourcedir created by apt-build by interrupting apt-build, then issuing these commands:
cd /var/cache/apt-build/build/dovecot-1.0.rc15/ wget http://dovecot.org/patches/mbox-snarf-plugin.c
export DOVECOT=/var/cache/apt-build/build/dovecot-1.0.rc15
gcc -fPIC -shared -Wall -I$DOVECOT -I$DOVECOT/src/lib -I$DOVECOT/src/lib-storage -I$DOVECOT/src/lib-mail -I$DOVECOT/src/lib-imap -DHAVE_CONFIG_H mbox-snarf-plugin.c -o mbox_snarf_plugin.so
The compiled file mbox_snarf_plugin.so was copied to /usr/lib/dovecot/modules/lib10_mbox_snarf_plugin.so with symlinks inside /usr/lib/dovecot/modules/imap and /usr/lib/dovecot/modules/pop3.
I setup /etc/dovecot/dovecot.conf according to your posting and restarted Dovecot. But accessing Dovecot with Thunderbird produces this:
May 29 16:01:09 bach dovecot: Killed with signal 15 May 29 16:01:10 bach dovecot: Dovecot v1.0.rc15 starting up May 29 16:01:24 bach dovecot: imap-login: Login: user=<mail>, method=plain, rip=x.x.x.x, lip=x.x.x.x, TLS May 29 16:01:24 bach dovecot: child 28786 (imap) killed with signal 11 May 29 16:01:25 bach dovecot: imap-login: Login: user=<mail>, method=plain, rip=x.x.x.x, lip=x.x.x.x, TLS May 29 16:01:25 bach dovecot: child 28791 (imap) killed with signal 11 May 29 16:01:25 bach dovecot: imap-login: Login: user=<mail>, method=plain, rip=x.x.x.x, lip=x.x.x.x, TLS May 29 16:01:25 bach dovecot: child 28795 (imap) killed with signal 11 May 29 16:01:25 bach dovecot: imap-login: Login: user=<mail>, method=plain, rip=x.x.x.x, lip=x.x.x.x, TLS May 29 16:01:25 bach dovecot: child 28806 (imap) killed with signal 11
I suppose I did something wrong when compiling the module, but what?
Greetings, Bernd Kuhls
On Tue, 2007-05-29 at 16:20 +0200, Bernd Kuhls wrote:
Timo Sirainen wrote:
Hi,
I just tried to setup this plugin on a Debian Etch machine but it crashes the Dovecot daemons.
Debian Etch uses the sourcecode of Dovecot 1.0rc15 + some patches.
It's entirely possible that it requires a newer version. I only tried it with v1.0.
gcc -fPIC -shared -Wall -I$DOVECOT -I$DOVECOT/src/lib -I$DOVECOT/src/lib-storage -I$DOVECOT/src/lib-mail -I$DOVECOT/src/lib-imap -DHAVE_CONFIG_H mbox-snarf-plugin.c -o mbox_snarf_plugin.so
Looks ok.
May 29 16:01:24 bach dovecot: child 28786 (imap) killed with signal 11
Getting backtrace of the crash could also show where the problem is. http://dovecot.org/bugreport.html
Timo Sirainen wrote:
Getting backtrace of the crash could also show where the problem is. http://dovecot.org/bugreport.html
Hi,
later I will try to backport the Dovecot 1.0 Debian package to Etch, but for now I can only provide you a backtrace:
(gdb) bt full #0 0x0808a778 in index_storage_get_status_locked () No symbol table info available. #1 0x0808bbf8 in index_mailbox_sync_deinit () No symbol table info available. #2 0xb7fd5c6d in sync_mailbox () from /usr/lib/dovecot/modules/imap/lib10_mbox_snarf_plugin.so No symbol table info available. #3 0xb7fd5c91 in mbox_snarf () from /usr/lib/dovecot/modules/imap/lib10_mbox_snarf_plugin.so No symbol table info available. #4 0xb7fd5eef in mbox_snarf_sync_init () from /usr/lib/dovecot/modules/imap/lib10_mbox_snarf_plugin.so No symbol table info available. #5 0x080614cc in imap_sync_nonselected () No symbol table info available. #6 0x080599d3 in _cmd_select_full () No symbol table info available. #7 0x08059b97 in cmd_select () No symbol table info available. #8 0x0805b4e2 in _client_input () No symbol table info available. #9 0x080b8826 in io_loop_handler_run () No symbol table info available. #10 0x080b7bd8 in io_loop_run () No symbol table info available. #11 0x080632de in main () No symbol table info available.
HTH, Bernd
On Mon, 2007-06-04 at 14:15 +0200, Bernd Kuhls wrote:
Timo Sirainen wrote:
Getting backtrace of the crash could also show where the problem is. http://dovecot.org/bugreport.html
Hi,
later I will try to backport the Dovecot 1.0 Debian package to Etch, but for now I can only provide you a backtrace:
(gdb) bt full #0 0x0808a778 in index_storage_get_status_locked () #1 0x0808bbf8 in index_mailbox_sync_deinit ()
Oh. Hmm. Wonder why it worked even with v1.0. Or maybe I just tested it with hg version and not v1.0 at all.. Anyway, updated http://dovecot.org/patches/mbox-snarf-plugin.c
Timo Sirainen wrote:
Anyway, updated http://dovecot.org/patches/mbox-snarf-plugin.c
Hi,
thanks, this code seems to work with the original Debian package.
It managed to copy the contents of a mbox from /var/mail/$user to /home/$user/.imap_mail/inbox, well done!
I have yet to conduct more testing as Dovecot+Exim will be handling 100+ users soon. Exims current setup delivers directly to directory /home/user/.imap_mail, where spam mails can optionally be delivered into different mbox files. /home is subject to user-based filesystem quotas, also a policy not to bounce any mail is in place.
My idea is to let Exim deliver everything to /var/mail/$user, where enough space is present, and let Dovecot snarf the mails to /home, if quota allows.
Is it possible to snarf more than one mbox from /var/mail to /home/$user, like this?
/var/mail/$user -> /home/.imap_mail/inbox /var/mail/$user.spam -> /home/.imap_mail/Spam /var/mail/$user.virus -> /home/.imap_mail/Virus
Snarfing only one mbox removes the possibility to let Exim move recognized spam mails not into the inbox.
Since using the snarf plugin I have this additional line in syslog:
Jun 4 15:28:27 bach dovecot: IMAP(kuhls): Timeout leak: 0x808ad10
Anything to worry about?
Greetings, Bernd Kuhls
On Mon, 2007-06-04 at 15:37 +0200, Bernd Kuhls wrote:
Is it possible to snarf more than one mbox from /var/mail to /home/$user, like this?
Shouldn't be too difficult to modify the plugin.
Jun 4 15:28:27 bach dovecot: IMAP(kuhls): Timeout leak: 0x808ad10
Fixed and uploaded new version.
Timo Sirainen wrote:
Jun 4 15:28:27 bach dovecot: IMAP(kuhls): Timeout leak: 0x808ad10
Fixed and uploaded new version.
Hi,
thanks, the log message disappeared.
In your original posting you said:
if all the messages couldn't be copied, for example because of out of quota, then none of the messages are copied. I suppose that could be a problem. It might be possible to fix that by changing:
if (mailbox_copy(dest_trans, mail, 0, NULL, NULL) < 0) { if (!mail->expunged) { ret = -1; break; } }
to just:
if (mailbox_copy(dest_trans, mail, 0, NULL, NULL) < 0) { if (!mail->expunged) break; }
But I'm not sure about that. Try and tell me. :)
In your new patch you changed exactly this code, did you have a reason to do so? I have yet to test your patch in an over-quota scenario, so I can´t tell you my experience with the patch.
Greetings, Bernd Kuhls
On Tue, 2007-06-05 at 21:12 +0200, Bernd Kuhls wrote:
In your original posting you said:
if all the messages couldn't be copied, for example because of out of quota, then none of the messages are copied. I suppose that could be a problem. It might be possible to fix that by changing: .. But I'm not sure about that. Try and tell me. :)
In your new patch you changed exactly this code, did you have a reason to do so? I have yet to test your patch in an over-quota scenario, so I can´t tell you my experience with the patch.
I changed it because I remembered my mail about it. With the previous code if you had 1000 messages waiting in /var/spool/mail, either all or none of them would be moved to ~/mbox. Now it should move as many as fits. If it works.
Hi,
Bernd Kuhls wrote:
It managed to copy the contents of a mbox from /var/mail/$user to /home/$user/.imap_mail/inbox, well done!
I have yet to conduct more testing
I did that now and I found another problem.
If /var/mail/$user does not exist, its created by Exim when delivering a mail, the content of the file looks like this:
From kuhls@localhost Sun Jun 10 22:00:16 2007 Return-path: <kuhls@localhost> Envelope-to: overquota@localhost Delivery-date: Sun, 10 Jun 2007 22:00:16 +0200 Received: from withoutHELO (noIP) by localhost (Exim 4.63) id 1HxTa9-0005dE-0Q; Sun, 10 Jun 2007 22:00:13 +0200 To: overquota@localhost Subject: test Date: Sun, 10 Jun 2007 22:00:16 +0200
test
This mailbox is snarfed by Dovecot each time the Inbox is opened, because the mail is not deleted from /var/mail$user, although Dovecot successfully snarfed the mail to /home/$user/.imap_mail/inbox. /home/$user is not overquota.
I found the reason for this, in contrast to the bevaviour described above my first test was done with a /var/mail/$user mbox which had an uw-imap style index, like this:
From MAILER_DAEMON Sat Apr 21 19:48:13 2007 Date: Sat, 21 Apr 2007 19:48:13 +0200 From: Mail System Internal Data <MAILER-DAEMON@localhost> Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA Message-ID: <1177177693@localhost> X-IMAP: 1177169873 0000000082 NonJunk Status: RO
This text is part of the internal format of your mail folder, and is not a real message. It is created automatically by the mail system software. If deleted, important folder data will be lost, and it will be re-created with the data reset to initial values.
After Exim delivered a mail to a file having this content, Dovecot is able to snarf the mail to /home/$user/.imap_mail/inbox _and_ delete it from /var/mail/$user.
How to solve this problem? /var/mail is normally empty and only used by Exim delivering mails when the user is overquota. I could use a cronjob-script-solution to create mbox files with uw-imap indexes for all users present on the system, but it would be an ugly hack.
Greetings, Bernd Kuhls
On 10.6.2007, at 23.10, Bernd Kuhls wrote:
This mailbox is snarfed by Dovecot each time the Inbox is opened, because the mail is not deleted from /var/mail$user, although Dovecot successfully snarfed the mail to /home/$user/.imap_mail/inbox. /home/$user is not overquota.
Check your error log. I'm pretty sure there's something in there
(http://wiki.dovecot.org/Logging).
Timo Sirainen wrote:
On 10.6.2007, at 23.10, Bernd Kuhls wrote:
This mailbox is snarfed by Dovecot each time the Inbox is opened, because the mail is not deleted from /var/mail$user, although Dovecot successfully snarfed the mail to /home/$user/.imap_mail/inbox. /home/$user is not overquota.
Check your error log. I'm pretty sure there's something in there (http://wiki.dovecot.org/Logging).
Hi,
nothing interesting found. The only message I saw, and which I would see disabled, is this one:
Jun 10 22:33:33 bach dovecot: IMAP(ulfb): stat() failed with mbox file /var/mail/someuser: No such file or directory
someuser is a valid mail user, where Dovecot uses /home/someuser/.imap_mail/ to store email, but Exim has never created /var/mail/someuser because the user never was over-quota. Having this log message all the time when 100+ users are using their mail accounts is a bit nasty;-)
Here are the log entries of a user with /var/mail/$user present:
Jun 10 22:22:27 bach dovecot: imap-login: Login: user=<user>, method=plain, rip=x.x.x.x, lip=y.y.y.y.y, TLS Jun 10 22:27:24 bach dovecot: IMAP(user): Disconnected: Logged out
During this imap session the mails from /var/mail/$user were snarfed to $HOME/.imap_mail/inbox, but the snarfed mails from /var/mail/$user were not deleted.
Jun 10 22:28:47 bach dovecot: imap-login: Login: user=<user>, method=plain, rip=x.x.x.x, lip=y.y.y.y, TLS Jun 10 22:28:53 bach dovecot: IMAP(user): Disconnected: Logged out Jun 10 22:29:00 bach dovecot: imap-login: Login: user=<user>, method=plain, rip=x.x.x.x, lip=y.y.y.y, TLS Jun 10 22:29:03 bach dovecot: IMAP(user): Disconnected: Logged out
Then I restarted the mailclient (Thunderbird 2.0) twice, the mails from /var/mail/$user were snarfed again and I saw these mails three times in my imap inbox. No other log messages are present and /var/mail/$user still holds the mails already snarfed three times. Only from a file with mbox index the mails get deleted during snarf process by Dovecot.
Greetings, Bernd Kuhls
Timo Sirainen wrote:
On 10.6.2007, at 23.10, Bernd Kuhls wrote:
This mailbox is snarfed by Dovecot each time the Inbox is opened, because the mail is not deleted from /var/mail$user, although Dovecot successfully snarfed the mail to /home/$user/.imap_mail/inbox. /home/$user is not overquota.
Check your error log. I'm pretty sure there's something in there (http://wiki.dovecot.org/Logging).
Hi,
yesterday I tried with Dovecot 1.0rc15-2 (Debian Etch stable), today I made a backport of the Debian testing package Dovecot 1.0.0-2 to Etch to test the mbox-snarf plugin. Unfortunately the same problem is present in the new version, also without any hints in the logfile.
Greetings, Bernd Kuhls
Timo Sirainen wrote:
mail_location = mbox:~/mail:INBOX=/var/mail/%u
Hi,
I am using Dovecot 1.0.0 (will soon update to 1.0.1) using your patch.
This is my mail_location setting:
mail_location = mbox:~/.imap_mail:INBOX=/var/mail/%u:INDEX=/var/mail/indexes/%u
The index for $HOME/.imap_mail/inbox is however created in $HOME/.imap_mail/.imap/inbox/, while the indexes for other mbox files are created in /var/mail/indexes/%u, like its supposed to be.
Is this a bug or a misconfiguration on my part?
Greetings, Bernd Kuhls
Timo Sirainen wrote:
Hi,
small update from an end-user of this plugin:
generally it works like expected, but some problems I mentioned are not solved yet. Here are my main config settings:
mail_location = mbox:~/.imap_mail:INBOX=/var/mail/%u:INDEX=/var/mail/indexes/%u
mbox_snarf = ~/.imap_mail/inbox
The index for $HOME/.imap_mail/inbox is created in $HOME/.imap_mail/.imap/inbox/, while the indexes for other mbox files are created in /var/mail/indexes/%u, like its supposed to be. How to disable creating index files in $HOME altogether without using links?
if /var/mail/$user does not exist, syslog is cluttered with these messages for each POP3/IMAP login:
Jun 10 22:33:33 server dovecot: IMAP(someuser): stat() failed with mbox file /var/mail/someuser: No such file or directory
the biggest problem is the following scenario:
- /var/mail/$user does not exist
- Exim can not deliver a mail to $HOME/.imap_mail/ so a second router comes into action and delivers the mail to /var/mail/$user
- /var/mail/$user now only contains the mail, without the IMAP headers Dovecot normally writes to a mbox file
- the user logs into the account and Dovecot tries to snarf the mail
- if snarfing is sucessful Dovecot must delete the mail from /var/mail/$user, but this fails due to the missing IMAP headers
- when the user logs into the account the next time the mail is snarfed again, this can be repeated endlessly
- the only situation where the snarf plugin works like expected is when /var/mail/$user contains the IMAP headers
To circumvent this problem I created a cronjob running once per minute which creates /var/mail/$user for $HOME/* with this content:
From MAILER_DAEMON Sat Apr 21 19:48:15 2007 Date: Sat, 21 Apr 2007 19:48:15 +0200 From: Mail System Internal Data <MAILER-DAEMON@server> Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA Message-ID: <1177177695@server> X-IMAP: 1177169799 0000003411 NonJunk Junk $Forwarded
Status: RO
This text is part of the internal format of your mail folder, and is not a real message. It is created automatically by the mail system software. If deleted, important folder data will be lost, and it will be re-created with the data reset to initial values.
This solution is annoying because it does not really fix the problem. Can you help me with this problem? I am using Dovecot 1.0.0, might updating to 1.0.1 help fixing some of the problems mentioned above?
Greetings, Bernd
On Fri, 2007-07-06 at 11:54 +0200, Bernd Kuhls wrote:
mail_location = mbox:~/.imap_mail:INBOX=/var/mail/%u:INDEX=/var/mail/indexes/%u
mbox_snarf = ~/.imap_mail/inbox
- The index for $HOME/.imap_mail/inbox is created in $HOME/.imap_mail/.imap/inbox/, while the indexes for other mbox files are created in /var/mail/indexes/%u, like its supposed to be. How to disable creating index files in $HOME altogether without using links?
This is a bit problematic to fix because of how it works internally.
if /var/mail/$user does not exist, syslog is cluttered with these messages for each POP3/IMAP login:
Jun 10 22:33:33 server dovecot: IMAP(someuser): stat() failed with mbox file /var/mail/someuser: No such file or directory
I can't reproduce this.
export MAIL_PLUGINS=mbox_snarf export MBOX_SNARF=~/mbox export MAIL=mbox:~/mail4:INBOX=/var/mail/tss:INDEX=/tmp/index
rm -rf ~/mbox ~/.imap ~/mail4 /var/mail/tss ./imap x select inbox --> no errors
rm -rf ~/mbox ~/.imap ~/mail4 /var/mail/tss touch ~/mbox ./imap x select inbox --> no errors
What plugins are you using?
- the biggest problem is the following scenario:
- /var/mail/$user does not exist
- Exim can not deliver a mail to $HOME/.imap_mail/ so a second router comes into action and delivers the mail to /var/mail/$user
- /var/mail/$user now only contains the mail, without the IMAP headers Dovecot normally writes to a mbox file
- the user logs into the account and Dovecot tries to snarf the mail
- if snarfing is sucessful Dovecot must delete the mail from /var/mail/$user, but this fails due to the missing IMAP headers
- when the user logs into the account the next time the mail is snarfed again, this can be repeated endlessly
- the only situation where the snarf plugin works like expected is when /var/mail/$user contains the IMAP headers
Looks like this is broken only with mbox_lazy_writes=yes, which is why I didn't notice it first.
And looks like it's a bug in Dovecot itself. Fixed: http://hg.dovecot.org/dovecot-1.0/rev/1b6c41524c6a
Hi,
Timo Sirainen wrote:
On Fri, 2007-07-06 at 11:54 +0200, Bernd Kuhls wrote:
- The index for $HOME/.imap_mail/inbox is created in $HOME/.imap_mail/.imap/inbox/, while the indexes for other mbox files are created in /var/mail/indexes/%u, like its supposed to be. How to disable creating index files in $HOME altogether without using links?
This is a bit problematic to fix because of how it works internally.
ok, not a big problem for me. I can live with the current situation.
if /var/mail/$user does not exist, syslog is cluttered with these messages for each POP3/IMAP login:
Jun 10 22:33:33 server dovecot: IMAP(someuser): stat() failed with mbox file /var/mail/someuser: No such file or directory
I can't reproduce this.
Since your patch below the snarf-bug is gone, Dovecot creates a zero-byte file for /var/mail/$user now.
Looks like this is broken only with mbox_lazy_writes=yes, which is why I didn't notice it first.
And looks like it's a bug in Dovecot itself. Fixed: http://hg.dovecot.org/dovecot-1.0/rev/1b6c41524c6a
Big thanks! Your patch fixed the bug, now I can throw away my ugly work-arounds for this. Weird enough I did not activate mbox_lazy_writes.
# dovecot -n # 1.0.3: /etc/dovecot/dovecot.conf log_path: /var/log/dovecot/dovecot.main log_timestamp: %Y-%m-%d %H:%M:%S protocols: imap imaps pop3 pop3s login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login mail_extra_groups: mail mail_location: mbox:~/.imap_mail:INBOX=/var/mail/%u:INDEX=/var/mail/indexes/%u mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_plugins(default): quota imap_quota mbox_snarf mail_plugins(imap): quota imap_quota mbox_snarf mail_plugins(pop3): mbox_snarf mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 imap_client_workarounds(default): outlook-idle netscape-eoh tb-extra-mailbox-sep delay-newmail imap_client_workarounds(imap): outlook-idle netscape-eoh tb-extra-mailbox-sep delay-newmail imap_client_workarounds(pop3): outlook-idle pop3_uidl_format(default): pop3_uidl_format(imap): pop3_uidl_format(pop3): %08Xu%08Xv auth default: passdb: driver: pam userdb: driver: passwd plugin: quota: fs mbox_snarf: ~/.imap_mail/inbox
Happy greetings, Bernd Kuhls
On Thu, 2007-08-09 at 20:43 +0200, Bernd Kuhls wrote:
Big thanks! Your patch fixed the bug, now I can throw away my ugly work-arounds for this. Weird enough I did not activate mbox_lazy_writes.
It's the default when imap/pop3 is started by Dovecot master, but I was testing it by running imap directly..
participants (2)
-
Bernd Kuhls
-
Timo Sirainen