[Dovecot] Internal Error - Cannot select inbox
Hi, I am new to this list although i have been using dovecot for some time now, i've come accross this error when a user tries to log in * OK Dovecot ready. 1 login username password 1 OK Logged in. 1 select inbox 1 NO Internal error occurred. Refer to server log for more information. [2007-12-07 12:51:56] there are no errors reported in the log files related to that issue for both dovecot.log and maillog what i do receive in the log files is dovecot: Dec 07 12:55:46 Info: imap-login: Login: user=<[EMAIL PROTECTED]>, method=PLAIN, rip=:::127.0.0.1, lip=:::127.0.0.1, secured dovecot: Dec 07 12:55:46 Info: IMAP([EMAIL PROTECTED]): Effective uid=500, gid=500 dovecot: Dec 07 12:55:46 Info: IMAP([EMAIL PROTECTED]): mbox: data=/var/spool/mail/vmail/domain/username:INBOX=/var/spool/mail/vmail/domain/username/Inbox:INDEX=/var/spool/mail/vmail/domain/username:home=/var/spool/mail/vmail/domain/username/.imap/.imap dovecot: Dec 07 12:55:46 Info: IMAP([EMAIL PROTECTED]): mbox: root=/var/spool/mail/vmail/domain/username, index=/var/spool/mail/vmail/domain/username, inbox=/var/spool/mail/vmail/domain/username/Inbox dovecot: Dec 07 12:55:46 Info: IMAP([EMAIL PROTECTED]): Disconnected i can't seem to pinpoint what is going wrong, some things to note i have existing users who can read email succesfully, its when i create a new user via postfixadmin, one should note that all directories are created and owned by vmail whose gid and uid is 500 and for the new users the directories and mboxes are created succesfully, but even if i copy over a working inbox of previous user to new user i still get an error so i don't think it is an mbox formatting issue another thing is that i can successfully check mail using mutt facility, even sending using mail clients (outlook express) is possible other configurations that might be helpful # dovecot --version 1.0.rc15 #cat /etc/group |grep vmail dovecot:x:97:vmail vmail:x:500:dovecot # /etc/dovecot.conf log_path: /var/log/dovecot.log protocols: pop3 pop3s imap imaps ssl_disable: yes login_dir: /var/run/dovecot/login login_executable(default): /usr/libexec/dovecot/imap-login login_executable(imap): /usr/libexec/dovecot/imap-login login_executable(pop3): /usr/libexec/dovecot/pop3-login mail_location: mbox:/var/spool/mail/vmail/%d/%n:INBOX=/var/spool/mail/vmail/%d/%n/Inbox:INDEX=/var/spool/mail/vmail/%d/%n:home=/var/spool/mail/vmail/%d/%n/.imap/.imap mail_debug: yes maildir_copy_with_hardlinks: yes mbox_min_index_size: 200 mail_executable(default): /usr/libexec/dovecot/imap mail_executable(imap): /usr/libexec/dovecot/imap mail_executable(pop3): /usr/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/lib/dovecot/imap mail_plugin_dir(imap): /usr/lib/dovecot/imap mail_plugin_dir(pop3): /usr/lib/dovecot/pop3 auth default: mechanisms: plain login passdb: driver: pam passdb: driver: sql args: /etc/dovecot/dovecot-mysql.conf userdb: driver: sql args: /etc/dovecot/dovecot-mysql.conf socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix master:
Re: [Dovecot] exim/kmail vs. dovecot
I have found getmail+sieve works a lot nicer. Then just use kmail as
a IMAP client.
On Wed, 5 Dec 2007 18:45:22 +0100
Kristian Koehntopp <[EMAIL PROTECTED]> wrote:
>
> I am using exim via dovecot_deliver to store messages in Maildir in
> my $HOME. I am using kmail to retrieve stuff. Unfortunately,
> something in my data crashes dovecot.
>
> I was using 1.0.rc14 from opensuse, but downloaded and installed
> 1.0.8 from the site.
>
> Here is the crash:
>
>
> Dec 5 18:05:09 h743107 dovecot: IMAP(kris): file
> mail-index-transaction.c: line 629
> (mail_index_update_flags_range): assertion failed: (seq1 <= seq2 &&
> seq1 > 0) Dec 5 18:05:09 h743107 dovecot: child 13896 (imap)
> killed with signal 6 Dec 5 18:05:09 h743107 dovecot: IMAP(kris):
> Raw backtrace: imap [0x8006cf7d] -> imap [0x8006ce58] ->
> imap(mail_index_update_flags_range+0x194) [0x8004d034] ->
> imap(mail_index_sync_begin+0x5c9) [0x8004fb79] ->
> imap(maildir_sync_index_begin+0x61) [0x80021c71] -> imap
> [0x8002350a] -> imap(maildir_storage_sync_init+0x56) [0x80023646]
> -> imap(mailbox_sync_init+0x16) [0x8005d566] ->
> imap(imap_sync_nonselected+0x28) [0x8001b838] ->
> imap(_cmd_select_full+0xd7) [0x80012c47] -> imap(cmd_select+0x25)
> [0x80012e25] -> imap [0x800143ea] -> imap[0x8001446c] ->
> imap(_client_input+0x7d) [0x80014bcd]
> ->imap(io_loop_handler_run+0x127) [0x80073987]->
> imap(io_loop_run+0x28) [0x80072ac8] -> imap(main+0x518)
> [0x8001d898] -> /lib/libc.so.6(__libc_start_main+0xdc) [0xb7e8d02c]
> -> imap[0x8000f0c1]
>
> I took the liberty to syslog() the seq numbers before the assert
> and indeed
>
> h743107:/etc/dovecot # grep "imap: seq1" /var/log/messages | head -3
> Dec 5 18:30:18 h743107 imap: seq1 1 seq2 1
> Dec 5 18:30:18 h743107 imap: seq1 1 seq2 1
> Dec 5 18:30:18 h743107 imap: seq1 1 seq2 1
> h743107:/etc/dovecot # grep "imap: seq1" /var/log/messages | awk
> '($9 < $7) { print }'
> Dec 5 18:30:42 h743107 imap: seq1 28 seq2 16
> Dec 5 18:32:43 h743107 imap: seq1 28 seq2 16
>
> What exactly is broken here and how can I fix that?
>
> Kris
>
> --
> Kristian =?iso-8859-15?q?K=F6hntopp?= <[EMAIL PROTECTED]>
Re: [Dovecot] imap crash with fts squat enabled.
Hi Timo, Just tested with the latest build, no crash but also no fts result. I found the following in the log: dovecot: Dec 07 10:45:06 Info: IMAP(joewong99:joew.outblaze.com): maildir++: root=/mailfs/4/22/3/joewong99:[EMAIL PROTECTED]/Maildir, index=, control=, inbox=/mailfs/4/22/3/joewong99:[EMAIL PROTECTED]/Maildir dovecot: Dec 07 10:45:12 Error: IMAP(joewong99:joew.outblaze.com): Corrupted squat uidlist file /mailfs/4/22/3/joewong99:[EMAIL PROTECTED]/Maildir/dovecot.index.search.uids: Broken uidlists dovecot: Dec 07 10:45:22 Error: IMAP(joewong99:joew.outblaze.com): Corrupted squat uidlist file /mailfs/4/22/3/joewong99:[EMAIL PROTECTED]/Maildir/dovecot.index.search.uids: Broken uidlists dovecot: Dec 07 10:45:27 Error: IMAP(joewong99:joew.outblaze.com): Corrupted squat uidlist file /mailfs/4/22/3/joewong99:[EMAIL PROTECTED]/Maildir/dovecot.index.search.uids: Broken uidlists dovecot: Dec 07 10:45:39 Error: IMAP(joewong99:joew.outblaze.com): Corrupted squat uidlist file /mailfs/4/22/3/joewong99:[EMAIL PROTECTED]/Maildir/dovecot.index.search.uids: Broken uidlists dovecot: Dec 07 10:45:44 Error: IMAP(joewong99:joew.outblaze.com): Corrupted squat uidlist file /mailfs/4/22/3/joewong99:[EMAIL PROTECTED]/Maildir/dovecot.index.search.uids: Broken uidlists dovecot: Dec 07 10:45:49 Error: IMAP(joewong99:joew.outblaze.com): Corrupted squat uidlist file /mailfs/4/22/3/joewong99:[EMAIL PROTECTED]/Maildir/dovecot.index.search.uids: Broken uidlists dovecot: Dec 07 10:45:53 Info: IMAP(joewong99:joew.outblaze.com): Disconnected: Logged out bytes=159/3278 What else do I missed? Mailbox and indexes are on NFS, is this the cause of the problem? Regards, - Joe On Thu, 6 Dec 2007, Timo Sirainen wrote: > On Thu, 2007-12-06 at 12:13 +0800, Joe Wong wrote: > > Here is the backtrace for your reference. I have already applied > > dovecot-97702c9c4111 changes to my 1.1 beta10 code base. > > > > I am running dovecot on FC7, gcc 4.1.2, mailbox is on NFS. Whenever I did > > > > UID SEARCH body "" > > > > imap crashes. > .. > > #4 0x080c9f2c in i_panic (format=0x80ebb5c "Leaked a t_pop() call in > > timeout handler %p") at failures.c:197 > > Try http://dovecot.org/nightly/dovecot-latest.tar.gz. I've rewritten > t_push/t_pop handling there so that this should never happen anymore. > > --
[Dovecot] Compiling with SQL support
Hello all, I am currently having a slight problem (ok well more likely me just not doing it right), with compiling Dovecot with MySQL support. The version is 1.0.8. I have tried running configure with --with-sql and --with-sql-drivers, but this however still does not compile MySQL support, I do no wish to install MySQL on this server, as I am using a network SQL server, but I do have the compiled source available on this server. I have tried running: gcc -shared -fPIC -DHAVE_CONFIG_H -DBUILD_MYSQL \ -I../.. -I../lib -I../lib-settings -I/data/mysql/include/mysql \ driver-mysql.c -o driver_mysql.so -lmysqlclient inside the /src/lib-sql, but this just returns an error that mysqlclient cannot be found. I have tried running dovecot --build-options, but MySQL is not listed here, the operating system is FreeBSD 6.2. The documentation does not seem to be giving any hints as to why this is not working, nor do How Tos. Any help would be appreciated. Mark Smith
Re: [Dovecot] Automatic Index Generation
On Thu, 2007-12-06 at 13:35 +0100, Maciej Poszywak wrote: > I'm looking for an application/script/etc. which will allow me to > recreate dovecot indexes by hand from shell. I'm preparing myself for > migration to dovecot 1.0.rc15 (debian stable) Post-v1.0.0 releases would be better, there have been a lot of fixes since then. backports.org for example has newer releases. > and would like to create > indexes before users start to login into new server to ease the load. > My other option is to write a script which will log as each user and > create indexes, however this seems a bit of painful way to do it. > Anybody can point me in right direction? I guess you're using maildirs? And you're migrating existing users' mailboxes? Do your users use actual IMAP clients or webmail? I'm not sure if you should worry about creating the indexes. If your users use IMAP clients, just make sure you preserve UIDVALIDITY and UIDs for messages, otherwise most of the clients will download all mails again. If you use webmail, there's some point in placing fields it accesses to dovecot.index.cache files. The only way to do this is to execute IMAP FETCH commands that accesses those fields. If you were thinking about just generating dovecot-uidlist and the main dovecot.index file, don't bother. Their creation is practically free. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Automatic Index Generation
Maciej Poszywak wrote: Gabriel Millerd wrote: On Dec 6, 2007 6:35 AM, Maciej Poszywak <[EMAIL PROTECTED]> wrote: I'm looking for an application/script/etc. which will allow me to recreate dovecot indexes by hand from shell. I'm preparing myself for migration to dovecot 1.0.rc15 (debian stable) and would like to create indexes before users start to login into new server to ease the load. My other option is to write a script which will log as each user and create indexes, however this seems a bit of painful way to do it. Anybody can point me in right direction? I have a perl script that will rip through all the users using imap and touch every folder (or every subscribed folder). if you dont have the authentication for a proper login you can always setup a temporary method that returns "username, 'static password', and homedir" before going live. Dunno if this was what you were asking. That's what I'm looking for. It would be nice if you sent me that script. -- Maciej Poszywak I thing I have to precise my needs. A perfect script should allow me to recreate the indexes given only the path to the mailbox. -- Maciej Poszywak
Re: [Dovecot] "pipe" plugin - is anyone interested (or using it)?
On Thu, 2007-12-06 at 15:29 +0100, Nicolas Boullis wrote: > > I think write() can return partially written data if the other side > > isn't reading it fast enough. Using write_full() instead would anyway be > > better/safer. > > I just reread my code, and I think my use of write looks safe, since > only the amount that was correctly written is skipped with > i_stream_skip. Do you think I'm missing something? Oh, you're right. It's probably better that way. > > Do you really need to wait for the executed process to finish? Since > > this is the only plugin currently creating child processes, I'd setup a > > SIGCHLD handler and waitpid() there to get rid of the zombie: > > lib_signals_set_handler(SIGCHLD, TRUE, chld_handler, NULL); > > Waiting is required if we want the append to fail if the command fails. > I guess it should better be a configurable option, don't you think so? Hmm. Maybe it's good the way it is now. > One question still: would you consider merging my plugin in dovecot if I > ported it to 1.1? Yes. Although I had been thinking about also some kind of a generic "event" plugin, which would allow executing commands for different kinds of events, not just for save and copy (like flag changes). But since I'm not planning on writing that myself anytime soon, I guess save/copy would be useful enough for a lot of people. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Sieve MySQL integration
On 2007-12-06 14:57:54 +0100, Stephan Bosch wrote: > Steven Murphy wrote: > >I have dovecot running with sieve performing vacation autoreply. > > > >Can sieve do sql lookups for vacation messages instead of having to do flat > >files in the users home directory? > > > No, unfortunately. To my knowledge, there is also no sieve extension > that specifies such behavior. The only proposed extension that has the > ability to do a background lookup is extlists, but that has nothing to > do with retrieving arbitrary strings from a database and will not be > useful for your purpose. If you feel that is might be commonly desired > feature of the sieve language, you could ask around on the > [EMAIL PROTECTED] mailing list whether such an extension would be > viable and whether someone is willing to adopt the responsibility to > write a proper specification. > > And then it still needs to be implemented of course... :) or just implement a webinterface that allows editing the values in the DB and afterwards dumps a new vacation script for the user to disk darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
Re: [Dovecot] "pipe" plugin - is anyone interested (or using it)?
Timo Sirainen wrote:
>
> I downloaded it when you first mentioned it, but looks like I never got
> around to actually looking at it. Yes, something like this would be
> nice..
>
> One thing at least that should be changed is to configure it using
> virtual mailbox names instead of full mailbox paths. This isn't really
> possible with v1.0, but v1.1 should make it pretty easy.
You already told me about this last time, but I haven't yet come to read
the source code of dovecot 1.1...
> A few things about the code:
>
> save_dest_mail = mail_alloc(ctx->transaction,
> MAIL_FETCH_PHYSICAL_SIZE, NULL);
>
> Quota plugin wanted to know the message's physical size, but your plugin
> doesn't need it. So you could just use 0 instead of
> MAIL_FETCH_PHYSICAL_SIZE.
Thanks for pointing this.
> I think write() can return partially written data if the other side
> isn't reading it fast enough. Using write_full() instead would anyway be
> better/safer.
I just reread my code, and I think my use of write looks safe, since
only the amount that was correctly written is skipped with
i_stream_skip. Do you think I'm missing something?
> Do you really need to wait for the executed process to finish? Since
> this is the only plugin currently creating child processes, I'd setup a
> SIGCHLD handler and waitpid() there to get rid of the zombie:
> lib_signals_set_handler(SIGCHLD, TRUE, chld_handler, NULL);
Waiting is required if we want the append to fail if the command fails.
I guess it should better be a configurable option, don't you think so?
> Multiple commands are now processed sequentially. I don't know if
> there's real need for multiple commands, but it would be faster to read
> the message input just once and send it to all pipes in parallel.
I don't think there is real need for multiple commands, but I think it
was easier for me to program things like this... ;-)
> "return 0 * WEXITSTATUS(status);" returns always 0 :)
Hummm... I guess I should avoid drinking alcohol before I program... ;-)
It probably should be "return WEXITSTATUS(status);"; I have no idea why
I changed this in such a strange way...
> I'd also leave stderr as-is for the child process so it could log
> errors, and for handling syscall failures use:
> i_fatal("dup2() failed: %m");
OK, point taken.
One question still: would you consider merging my plugin in dovecot if I
ported it to 1.1?
Cheers,
Nicolas
[Dovecot] Roadmap to future
v1.1.0 is finally getting closer, so it's time to start planning what
happens after it. Below is a list of some of the larger features I'm
planning on implementing. I'm not yet sure in which order, so I think
it's time to ask again what features companies would be willing to pay
for?
Sponsoring Dovecot development gets you:
- listed in Credits in www.dovecot.org
- listed in AUTHORS file
- you can tell me how you want to use the feature and I'll make sure
that it's possible (within reasonable limits)
- allows you to change the order in which features are implemented
(more or less)
As you can see below, some features are easier to implement when other
features are implemented first. Several of them depend on v2.0 master
rewrite, so I'm thinking that maybe it's time to finally finish that
first.
I know several companies have requested replication support, but since
it kind of depends on several other features, it might be better to
leave that for v2.1. But of course sponsoring development of those
features that replication depends on gets you the replication support
faster. :)
I'm still trying to go to school (and this year I started taking CS
classes as well as biotech classes..), so it might take a while for some
features to get implemented. I'm anyway hoping for a v1.2 or v2.0
release before next summer.
So, the list..
--
Implemented, but slightly buggy so not included in v1.1 (yet):
- Mailbox list indexes
- THREAD REFERENCES indexes
- THREAD X-REFERENCES2 algorithm where threads are sorted by their latest
message instead of the thread root message
Could be implemented for v1.2:
- Shared mailboxes and ACLs
http://www.dovecot.org/list/dovecot/2007-April/021624.html
- Virtual mailboxes:
http://www.dovecot.org/list/dovecot/2007-May/022828.html
- Depends on mailbox list indexes
dbox plans, could be implemented for v1.2:
- Support for single instance attachment storage
- Global dbox storage so copying messages from mailbox to another involves
only small metadata updates
- Support some kind of hashed directories for storing message files, instead
of storing everything in a single directory.
- Finish support for storing multiple messages in a file
v2.0 master/config rewrite
--
It's mostly working already. One of the larger problems left is how to
handle plugin settings. Currently Dovecot just passes everything in plugin
{} section to mail processes without doing any checks. I think plugin
settings should be checked just as well as the main settings. Also plugins
should be able to create new sections instead of having to use plain
key=value settings for everything.
v2.0 currently runs a perl script on Dovecot's source tree to find
settiongs from different places then then creates a single all-settings.c
for config process. This obviously doesn't work for out-of-tree plugins, so
there needs to be some other way for them to pass the allowed settings.
There are two possibilities:
a) Read them from separate files. This is a bit annoying, because it's not
anymore possible to distribute simple plugin.c files and have them compiled
into plugin.so files.
b) Read them from the plugin itself. This would work by loading the plugin
and then reading the variable containing the configuration. I'm a bit
worried about security implications though, because the plugins could
execute some code while they're loaded. But I guess a new unprivileged
process could be created for doing this. Of course normally admins won't
run any user-requested plugins anyway so this might not be a real issue
anyway. :)
Index file optimizations
- Since these are not backwards compatible changes, the major version
number should be increased whenever these get implemented. So I think these
should be combined with v2.0 master/config rewrite. I'd rather not release
v3.0 soon after v2.0 just for these..
- dovecot.index.log: Make it take less space! Get rid of the current
"extension introduction" records that are large and written over and over
again. Compress UID ranges using similar methods than Squat uses now. Try
all kinds of other methods to reduce space usage.
Write transaction boundaries, so the reader can process entire transactions
at a time. This will make some things easier, such as avoiding NFS data
cache flushes, replication support and also allows lockless writes using
O_APPEND.
- dovecot.index: Instead of keeping a single message record array, split
it into two: A compressed list of message UIDs and array containing the
rest of the data. This makes the file smaller and keeping UIDs separate
allows better CPU cache (and maybe disk I/O) utilization for UID ->
sequence lookups. At least this is the theory, I should benchmark this
before committing to this design. :)
There could also be a separate expunged UIDs list. UIDs existing in there
would be removed from existing UIDs list, but it wouldn't affect
calculating offsets to record
Re: [Dovecot] "pipe" plugin - is anyone interested (or using it)?
Hi,
Ben Schumacher wrote:
>
> Could you maybe explain how the configuration works in a little more
> detail? For some reason I'm having a bit of trouble wrapping my head
> around how this works:
What is the part you don't understand?
> namespace private {
>separator = .
>location = maildir:/var/mail/%u
>inbox = yes
>hidden = no
> }
>
> namespace public {
>separator = .
>prefix = learn.
>location = maildir:/var/learn/%u
>inbox = no
>hidden = no
> }
This is a simple namespace definition, nothing specific to my plugin.
The learn.* part of the namespace is declared public and stored an a
specific location. I did this to avoid counting the learnt messages to
the quota.
> plugin {
> (...)
> pipe = /var/learn/%u/.spam:spamc -d some.host -L spam
> pipe2 = /var/learn/%u/.ham:spamc -d some.host -L ham
> (...)
And here I define that any message stored to /var/learn/%u/.spam where
%u is the username (that is learn.spam in the user's IMAP namespace) has
to be piped to the "spamc -d some.host -L spam" command. And the same
for ham.
Hope this helps,
Nicolas
Re: [Dovecot] Sieve MySQL integration
Steven Murphy wrote: I have dovecot running with sieve performing vacation autoreply. Can sieve do sql lookups for vacation messages instead of having to do flat files in the users home directory? No, unfortunately. To my knowledge, there is also no sieve extension that specifies such behavior. The only proposed extension that has the ability to do a background lookup is extlists, but that has nothing to do with retrieving arbitrary strings from a database and will not be useful for your purpose. If you feel that is might be commonly desired feature of the sieve language, you could ask around on the [EMAIL PROTECTED] mailing list whether such an extension would be viable and whether someone is willing to adopt the responsibility to write a proper specification. And then it still needs to be implemented of course... :) Regards, Stephan.
[Dovecot] Sieve MySQL integration
I have dovecot running with sieve performing vacation autoreply. Can sieve do sql lookups for vacation messages instead of having to do flat files in the users home directory? Thank you in advance. Steve
Re: [Dovecot] How to copy Spammail for learning out of Postfix and Dovecot (vmail)
On 06.12.2007 15:13, Sven Schmidt wrote: Wolfram Schlich schrieb: Put them in a dedicated mail folder (mbox or maildir doesn't matter) and process them either periodically via a cron job or on-demand via inotify-enabled software. All mails are revieved by POP. No user can sort mails by Spam You may even do this without procmail I'm using postfix only for such job. But in my case I'm using spamtrap addresses and alias it to something like [EMAIL PROTECTED] where mx1 is postfix server itself and its responsible for delivering to maildir but not to @example.com, it job for dovecot.
Re: [Dovecot] Automatic Index Generation
Gabriel Millerd wrote: On Dec 6, 2007 6:35 AM, Maciej Poszywak <[EMAIL PROTECTED]> wrote: I'm looking for an application/script/etc. which will allow me to recreate dovecot indexes by hand from shell. I'm preparing myself for migration to dovecot 1.0.rc15 (debian stable) and would like to create indexes before users start to login into new server to ease the load. My other option is to write a script which will log as each user and create indexes, however this seems a bit of painful way to do it. Anybody can point me in right direction? I have a perl script that will rip through all the users using imap and touch every folder (or every subscribed folder). if you dont have the authentication for a proper login you can always setup a temporary method that returns "username, 'static password', and homedir" before going live. Dunno if this was what you were asking. That's what I'm looking for. It would be nice if you sent me that script. -- Maciej Poszywak
[Dovecot] Automatic Index Generation
Hello, I'm looking for an application/script/etc. which will allow me to recreate dovecot indexes by hand from shell. I'm preparing myself for migration to dovecot 1.0.rc15 (debian stable) and would like to create indexes before users start to login into new server to ease the load. My other option is to write a script which will log as each user and create indexes, however this seems a bit of painful way to do it. Anybody can point me in right direction? -- Maciej Poszywak
Re: [Dovecot] How to copy Spammail for learning out of Postfix and Dovecot (vmail)
Wolfram Schlich schrieb: Put them in a dedicated mail folder (mbox or maildir doesn't matter) and process them either periodically via a cron job or on-demand via inotify-enabled software. All mails are revieved by POP. No user can sort mails by Spam
Re: [Dovecot] How to copy Spammail for learning out of Postfix and Dovecot (vmail)
* Sven Schmidt <[EMAIL PROTECTED]> [2007-12-06 11:59]: > Hi! Hi! > I am using Postfix 2.3.8 and Dovecot 1.0.rc15. > Virtual Domains and Mailboxes are configured. > > I tried to copy spammy Mail with Procmail, but Procmail only sees local > mails. > How to configure it to get a copy of spammy mails in a mbox or mail-dir? Put them in a dedicated mail folder (mbox or maildir doesn't matter) and process them either periodically via a cron job or on-demand via inotify-enabled software. -- Regards, Wolfram Schlich <[EMAIL PROTECTED]> Gentoo Linux * http://dev.gentoo.org/~wschlich/
[Dovecot] How to copy Spammail for learning out of Postfix and Dovecot (vmail)
Hi! I am using Postfix 2.3.8 and Dovecot 1.0.rc15. Virtual Domains and Mailboxes are configured. I tried to copy spammy Mail with Procmail, but Procmail only sees local mails. How to configure it to get a copy of spammy mails in a mbox or mail-dir?
Re: [Dovecot] exim/kmail vs. dovecot
On Thursday, 6. December 2007 11:01:40 Stephen Usher wrote: > Kristian Koehntopp wrote: > > I am using exim via dovecot_deliver to store messages in Maildir in my > > $HOME. I am using kmail to retrieve stuff. Unfortunately, something in my > > data crashes dovecot. > > > > I was using 1.0.rc14 from opensuse, but downloaded and installed 1.0.8 > > from the site. > > Kmail doesn't use a proper version of Maildir internally, it also assumes > that it's the only program accessing the files and so play fast and loose. I am using (d)IMAP only with kmail. The kmail is on my laptop, the dovecot is elsewhere (a strato dedicated server in Berlin). Kris -- Kristian =?iso-8859-15?q?K=F6hntopp?= <[EMAIL PROTECTED]>
Re: [Dovecot] exim/kmail vs. dovecot
Kristian Koehntopp wrote: I am using exim via dovecot_deliver to store messages in Maildir in my $HOME. I am using kmail to retrieve stuff. Unfortunately, something in my data crashes dovecot. I was using 1.0.rc14 from opensuse, but downloaded and installed 1.0.8 from the site. Kmail doesn't use a proper version of Maildir internally, it also assumes that it's the only program accessing the files and so play fast and loose. Not only this but it also has its own index files and gets extremely confused if things change underneath it. It's really a nasty client underneath the skin. I would suggest that you deliver your e-mail elsewhere and have kmail access the folders via IMAP, even though it's not very nice to do so. (Kmail will overload the IMAP server if you're not careful.) I can tell you this from experience as I used Kmail for a number of years in a production environment until quite recently. Steve -- --- Computer Systems Administrator,E-Mail:[EMAIL PROTECTED] Department of Earth Sciences, Tel:- +44 (0)1865 282110 University of Oxford, Parks Road, Oxford, UK. Fax:- +44 (0)1865 272072
Re: [Dovecot] imap crash with fts squat enabled.
On Thu, 2007-12-06 at 12:13 +0800, Joe Wong wrote: > Here is the backtrace for your reference. I have already applied > dovecot-97702c9c4111 changes to my 1.1 beta10 code base. > > I am running dovecot on FC7, gcc 4.1.2, mailbox is on NFS. Whenever I did > > UID SEARCH body "" > > imap crashes. .. > #4 0x080c9f2c in i_panic (format=0x80ebb5c "Leaked a t_pop() call in > timeout handler %p") at failures.c:197 Try http://dovecot.org/nightly/dovecot-latest.tar.gz. I've rewritten t_push/t_pop handling there so that this should never happen anymore. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Worse now: Cores
On Wed, Dec 05, 2007 at 10:02:01PM +0200, Timo Sirainen wrote: [snip] > The glibc free() error then is a pretty serious problem. It just should > never happen no matter what you do. The backtrace shows that it's [snap] I recently had similar (not dovecot related) troubles on a box with corrupt/defective memory. Do a memtest if you can; this could probably be a hardware defect. best regards, Adi Kriegisch
Re: [Dovecot] "pipe" plugin - is anyone interested (or using it)?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 5 Dec 2007, Nicolas Boullis wrote: It's on my todo list in order to support user-site SPAM training. BTW: Could you please add the example of your first message into the plugin tgz? So the useage info is with the package. Bye, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBR1eswi9SORjhbDpvAQJLzwf+O9rHYeOiZsllYd/kfM/VV2UTy3ZFL+Wi cJRq3JKYSq3lYeGVKntXqHfp7HqeB6hAr4qHhGAmcStA6mVM4OgjQ5NQZMT7veyI exweEGKQDpAMvEXZ4wL09Jydf8f+TYZMOyLMmZUzdnKVJyk9tUUy8JR+2PeUbubq RgL/NGsygmuEIY8fOVLQRdZwjZ5uO5OoN1vvGFN2TUFsePo7c/ro/bq1S4dhst4f mjsKa/aqxPNlQPK+gKrnKfbX0V84e3u4XsgYYaPyCwnD3yMqnVe4nE0nIYeoGDFq DP8C8kVGtMVz300229lK/HcuxSWbUh2Z9l/XJWdIT2R9HfOT2fvE7Q== =ccab -END PGP SIGNATURE-
