January 2011 - dovecot

[Dovecot] Running two different versions of Dovecot (was: making folders unmovable)
by David Salisbury 14 Jan '11

14 Jan '11

OK, so I decided to go ahead and just upgrade to the latest 1 series Dovecot and see if that solves my ACL/config issues I've been having. (I tried compiling 2.0.9, but it errored out and I assume that's because it's a pretty old machine/compiler.) Anyway, 1.2.16 compiled fine, and I installed it in another location from the currently running 1.1 series install. I have this new install running (IMAP) on a non-standard port while I test it out, and it starts fine and all seems well. However, I'm wondering, is it OK to run it and have it look at the same Maildir mailboxes as the currently running 1.1 series install? Does that have the potential to mess with indexes or change anything in a bad way? (FWIW, I tried it briefly, and after changing the port number in and restarting my mail client [Thunderbird], it had trouble pulling up the mailbox I was trying to access.) David

1 0

Re: [Dovecot] Time jumped forwards
by Ian B 14 Jan '11

14 Jan '11

On Fri Jan 14 07:23:32 EET 2011, Eric Shubert wrote: >See >http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType… > > >In particular, see NTP Recommendations and VMware Tools bits at the bottom. Thanks, I've read through that document a couple of times now & I'm fairly sure my system 'ticks all the boxes' yet the warning messages continues. I can see no noticeable time discrepancy when I do periodic time checks from the command line comparing against another system's clock - certainly not 2 minute error margin Could this be a time mismatch between imap client & server? Ian.

3 4

[Dovecot] email addresses as usernames with Kerberos
by Peter Mogensen 14 Jan '11

14 Jan '11

Hi, I was trying out Kerberos authentication with som sample users for Dovecot and stumbled into this problem: The user names are of the form local-part@domain, so the Kerberos principal becomes "local-part\@domain@REALM". But it seems Dovecot (1.2.9) doesn't understand that syntax. Looking at the 2.0.8 sources I guess it's not supported. But isn't this a valid Kerberos principal? Is it a bug, or a missing feature or is there a special reason for not supporting it ? kind regards, Peter

1 0

[Dovecot] Time jumped forwards
by Ian B 14 Jan '11

14 Jan '11

Running Dovecot 2.0.8 on 32bit Centos5.5. The machine is a VMWare ESX VM. I'm seeing a lot of warning messages in syslog as follows: 2011-01-14T11:45:37.315917+08:00 imap4 dovecot: imap: Warning: Time jumped forwards 105 seconds 2011-01-14T11:46:00.598006+08:00 imap4 dovecot: imap: Warning: Time jumped forwards 106 seconds 2011-01-14T11:46:25.364405+08:00 imap4 dovecot: imap: Warning: Time jumped forwards 105 seconds 2011-01-14T11:46:27.030658+08:00 imap4 dovecot: imap: Warning: Time jumped forwards 106 seconds 2011-01-14T11:46:49.712202+08:00 imap4 dovecot: imap: Warning: Time jumped forwards 106 seconds 2011-01-14T11:48:07.600748+08:00 imap4 dovecot: imap: Warning: Time jumped forwards 106 seconds 2011-01-14T11:48:23.195587+08:00 imap4 dovecot: imap: Warning: Time jumped forwards 106 seconds 2011-01-14T11:48:37.342804+08:00 imap4 dovecot: imap: Warning: Time jumped forwards 106 seconds 2011-01-14T11:48:42.671037+08:00 imap4 dovecot: imap: Warning: Time jumped forwards 106 seconds 2011-01-14T11:48:45.903081+08:00 imap4 dovecot: imap: Warning: Time jumped forwards 105 seconds 2011-01-14T11:48:49.001119+08:00 imap4 dovecot: imap: Warning: Time jumped forwards 105 seconds 2011-01-14T11:48:58.935835+08:00 imap4 dovecot: imap: Warning: Time jumped forwards 105 seconds 2011-01-14T11:49:15.046253+08:00 imap4 dovecot: imap: Warning: Time jumped forwards 104 seconds 2011-01-14T11:49:16.842962+08:00 imap4 dovecot: imap: Warning: Time jumped forwards 106 seconds I've checked the clock settings in Centos and it all looks OK. NTP is running and not complaining about clock drift. Vmware recommend appending 'divider=10 clocksource=acpi_pm' kernel boot options to prevent timekeeping issues, which I've done. Has anyone else encountered this message? Is it something to be concerned about? Thanks, Ian.

2 1

Re: [Dovecot] Making shared folders "unmovable"
by Dave 13 Jan '11

13 Jan '11

Well, I just noticed this in my logs after I re-loaded the latest Dovecot config I tried: Jan 13 15:09:45 mail dovecot: SIGHUP received - reloading configuration Jan 13 15:09:45 mail dovecot: read(imap dump-capability process) failed: Interrupted system call Jan 13 15:09:45 mail dovecot: Invalid configuration, keeping old one Jan 13 15:09:45 mail dovecot: child 2085 (unknown) returned error 82 (Internal logging error) It's apparently been doing this every time I've reloaded the config, so this is probably why none of my changes with the ACLs are working. :/ Any thoughts on what could be causing this kind of error?? Does that error just basically mean something's set wrong somewhere in dovecot.conf? David

1 0

Re: [Dovecot] Best Cluster Storage
by Jonathan Tripathy 13 Jan '11

13 Jan '11

On 13/01/11 10:57, Stan Hoeppner wrote: > Jonathan Tripathy put forth on 1/13/2011 2:24 AM: > >> Ok so this is interesting. As long as I use Postfix native delivery, >> along with >> Dovecot director, NFS should work ok? > One has nothing to do with the other. Director doesn't touch smtp > (afaik), only > imap. The reason for having Postfix use its native local(8) delivery > agent for > writing into the maildir, instead of Dovecot deliver, is to avoid > Dovecot index > locking/corruption issues with a back end NFS mail store. So if you > want to do > sorting you'll have to use something other than sieve, such as > maildrop or > procmail. These don't touch Dovecot's index files, while Deliver > (LSA) does > write to them during message delivery into the maildir. Yes, I thought it had something to do with that >>> For any meaningful use of virtualized clusters with Xen, ESX, etc, a >>> prerequisite is shared storage. If you don't have it, get it. The >>> hypervisor >>> is what gives you fault tolerance. This requires shared storage. >>> If you do not >>> intend to install shared storage, and intend to use things like drbd >>> between >>> guests to get your storage redundancy, then you really need to >>> simply throw out >>> your hypervisor, in this case Xen, and do direct bare metal host >>> clustering with >>> drbd, gfs2, NFS, etc. >> Why is this the case? Apart from the fact that Virtualisation becomes >> "more >> useful" with shared storage (which I agree with), is there anything >> wrong with >> doing DR between guests? We don't have shared storage set up yet for the >> location this email system is going. We will get one in time though. > I argue that datacenter virtualization is useless without shared > storage. This > is easy to say for those of us who have done it both ways. You > haven't yet. > Your eyes will be opened after you do Xen or ESX atop a SAN. If > you're going to > do drbd replication between two guests on two physical Xen hosts then > you may as > well not use Xen at all. It's pointless. Where did I say I havn't done that yet? I have indeed worked with VM infrastructures using SAN storage, and yes, it's fantastic. Just this particular location doesn't have a SAN box installed. And we will have to agree to disagree as I personally do see the benefit of using VMs with local storage > What you need to do right now is build the justification case for > installing the > SAN storage as part of the initial build out and setup your virtual > architecture > around shared SAN storage. Don't waste your time on this other > nonsense of > replication from one guest to another, with an isolated storage pool > attached to > each physical Xen server. That's just nonsense. Do it right or don't > do it at all. > > Don't take my word for it. Hit Novell's website and VMWare's and pull > up the > recommended architecture and best practices docs. You don't need to tell me :) I already know how great it is > One last thing. I thought I read something quite some time ago about Xen > working on adding storage layer abstraction which would allow any Xen > server to > access directly connected storage on another Xen server, creating a > sort of > quasi shared SAN storage over ethernet without the cost of the FC > SAN. Did > anything ever come of that? > I haven't really been following how the 4.x branch is going as it wasn't stable enough for our needs. Random lockups would always occur. The 3.x branch is rock solid. There have been no crashes (yet!) Would DRBD + GFS2 work better than NFS? While NFS is simple, I don't mind experimenting with DRBD and GFS2 is it means fewer problems?

1 0

[Dovecot] Problem after migration dovecot 1.2 -> dovecot 2.0
by Javier de Miguel Rodríguez 13 Jan '11

13 Jan '11

I have migrated from dovecot 1.2 to dovecot 2.0. When I connect via telnet to 110 port of the dovecot server the client hangs: telnet 192.168.4.80 110 Trying 192.168.4.80... /Connected to 192.168.4.80. Escape character is '^]'./ In syslog I got the following error: /Jan 12 12:14:44 buzon dovecot: imap-login: Error: auth: connect(login) in directory / failed: Permission denied (euid=107(<unknown>) egid=110(<unknown>) missing +x perm: /, euid is not dir owner)/ My /var/run/dovecot directory listing is the following: ls -lhR /var/run/dovecot //var/run/dovecot: total 12K srw------- 1 root root 0 ene 12 11:40 anvil srw------- 1 root root 0 ene 12 11:40 anvil-auth-penalty srw------- 1 root root 0 ene 12 11:40 auth-client srw------- 1 dovecot root 0 ene 12 11:40 auth-login srw------- 1 entrega root 0 ene 12 11:40 auth-master srw------- 1 entrega root 0 ene 12 11:40 auth-userdb srw------- 1 dovecot root 0 ene 12 11:40 auth-worker srw------- 1 root root 0 ene 12 11:40 config srw------- 1 root root 0 ene 12 11:40 dict srwxrwxrwx 1 root root 0 dic 27 21:36 dict-server srw------- 1 root root 0 ene 12 11:40 director-admin srw------- 1 root root 0 ene 12 09:17 director-userdb srw-rw-rw- 1 root root 0 ene 12 11:40 dns-client srw------- 1 root root 0 ene 12 11:40 doveadm-server lrwxrwxrwx 1 root root 25 ene 12 11:40 dovecot.conf -> /etc/dovecot/dovecot.conf drwxr-xr-x 2 root root 4,0K ene 12 09:05 empty drwxr-x--- 2 root root 4,0K ene 12 11:40 login -rw------- 1 root root 6 ene 12 11:40 master.pid /var/run/dovecot/empty: total 0 /var/run/dovecot/login: total 4,0K srw-rw-rw- 1 root root 0 ene 12 11:40 dns-client srw-rw-rw- 1 root root 0 ene 12 11:40 imap srw-rw-rw- 1 root root 0 ene 12 11:40 login srw-rw-rw- 1 root root 0 ene 12 11:40 pop3 srw-rw-rw- 1 root root 0 ene 12 11:40 sieve -rw-r--r-- 2 root root 230 ene 9 20:56 ssl-parameters.dat srw-rw-rw- 1 root root 0 ene 12 11:40 ssl-params / My doveconf -n is the following: / # OS: Linux 2.6.18-194.26.1.el5 x86_64 Red Hat Enterprise Linux Server release 5.5 (Tikanga) ext3 auth_debug = yes auth_master_user_separator = * auth_mechanisms = plain login base_dir = /var/run/dovecot/ default_client_limit = 4096 default_process_limit = 2500 disable_plaintext_auth = no dotlock_use_excl = yes mail_fsync = never mail_gid = entrega mail_location = maildir:/buzones/us.es/%2.26Hn/%2.200Hn/%n:INDEX=/buzones/ramdisk/%2.26Hn/%2.200Hn/%n mail_plugins = " zlib" mail_uid = entrega managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date passdb { driver = shadow } passdb { args = /etc/dovecot/dovecot-ldap.conf driver = ldap } passdb { args = /etc/usuario_maestro.txt driver = passwd-file master = yes } passdb { args = /etc/dovecot/dovecot-ldap.conf driver = ldap } plugin { quota = maildir:Cuota de usuario quota_rule2 = Trash:storage=+10%% quota_warning = storage=95%% /usr/local/bin/quota-warning.sh 95 quota_warning2 = storage=80%% /usr/local/bin/quota-warning.sh 80 sieve = /buzones/us.es/%2.26Hn/%2.200Hn/%n/dovecot.sieve sieve_dir = /buzones/us.es/%2.26Hn/%2.200Hn/%n/sieve/ zlib_save = gz zlib_save_level = 9 } protocols = pop3 imap sieve service auth { unix_listener auth-master { user = entrega } unix_listener auth-userdb { user = entrega } user = root } service imap-login { executable = /usr/libexec/dovecot/imap-login process_limit = 2000 } service imap { executable = /usr/libexec/dovecot/rawlog /usr/libexec/dovecot/imap process_limit = 2000 } service managesieve-login { executable = /usr/libexec/dovecot/managesieve-login inet_listener sieve { port = 2000 } process_limit = 2000 } service managesieve { executable = /usr/libexec/dovecot/managesieve process_limit = 2000 } service pop3-login { executable = /usr/libexec/dovecot/pop3-login process_limit = 2000 } service pop3 { executable = /usr/libexec/dovecot/pop3 process_limit = 2000 } ssl_ca = </etc/pki/generico/cacert.crt.pem ssl_cert = </etc/pki/generico/wildcard-us_es.crt ssl_key = </etc/pki/generico/wildcard-key.pem userdb { driver = passwd } userdb { args = /etc/dovecot/dovecot-ldap.conf driver = ldap } userdb { args = /etc/dovecot/dovecot-ldap-userdb.conf driver = ldap } verbose_proctitle = yes protocol sieve { managesieve_implementation_string = dovecot managesieve_logout_format = bytes=%i/%o managesieve_max_line_length = 65536 } protocol lda { hostname = us.es info_log_path = log_path = mail_fsync = optimized mail_plugins = quota sieve zlib postmaster_address = evcorreo(a)us.es syslog_facility = mail } protocol imap { mail_plugins = quota imap_quota zlib } protocol pop3 { mail_plugins = zlib pop3_enable_last = yes pop3_uidl_format = %08Xv%08Xu } /UID & GID of my users: [root@buzon login]# id entrega uid=500(entrega) gid=500(entrega) grupos=500(entrega) [root@buzon login]# id dovecot uid=104(dovecot) gid=107(dovecot) grupos=107(dovecot) [root@buzon login]# id dovenull uid=107(dovenull) gid=110(dovenull) grupos=110(dovenull) What am I doing wrong? I have migrated a identical server from dovecot 1.2 to dovecot 2.0 without this problem. Regards Javier

2 3

[Dovecot] Denying authentication
by Romer Ventura 13 Jan '11

13 Jan '11

Hello, I've been running dovecot for over 3 years now and it works with no problems. I have it setup so that it authenticates users against Active Directory via LDAP and so far no problems. What I would like to know is if there is any way that I could deny access for users trying to access email via cellphones or email clients outside the company. I can close everything since there are a few users that need to get emails from outside the company via cell phone of email clients. I was thinking if there was a way to lets say create a group in AD named: "remote-email" that will allow connection and authentication from any network, any user not in that group will only be able to authenticate if the source is 192.168.xx.xx/24. Is this possible? Maybe not with Dovecot, but maybe someone else has any ideas..? Thanks -------- Romer Ventura

3 4

[Dovecot] Making shared folders "unmovable"
by Dave 13 Jan '11

13 Jan '11

I have set up an area of shared folders with Dovecot 1.2 that is accessed by several people (by way of one account, and everyone who logs in sees these same folders), and the only problem with this setup is that occasionally somebody moves one of the folders underneath another folder or somewhere else in the folder structure, and this sometimes disrupts some automatic procmail filters and the like. Is there a way to keep folders in a shared setup such as this "static" or "unmovable" so that the users can't disrupt the structure? Like, where the folder structure itself can't be changed, but new messages can still come in to the folders? David

5 9

[Dovecot] Backtrace:dovecot/imap
by Ralf Hildebrandt 12 Jan '11

12 Jan '11

This may be identical to the one I posted previously. >From the log: Jan 12 15:25:55 postamt dovecot: imap(mfxxxch): Panic: file squat-trie.c: line 876 (squat_build_word): assertion failed: (i + bytelen <= size) Jan 12 15:25:55 postamt dovecot: imap(mfxxxch): Error: Raw backtrace: /usr/dovecot-2/lib/dovecot/libdovecot.so.0(+0x3b861) [0xb7721861] -> /usr/dovecot-2/lib/dovecot/libdovecot.so.0(+0x3b8cf) [0xb77218cf] -> /usr/dovecot-2/lib/dovecot/libdovecot.so.0(i_fatal+0) [0xb76f869e] -> /usr/dovecot-2/lib/dovecot/lib21_fts_squat_plugin.so(+0x55ca) [0xb75105ca] -> /usr/dovecot-2/lib/dovecot/lib21_fts_squat_plugin.so(squat_trie_build_more+0x126)[0xb7510e46] -> /usr/dovecot-2/lib/dovecot/lib21_fts_squat_plugin.so(+0x2b2c)[0xb750db2c] -> /usr/dovecot-2/lib/dovecot/lib20_fts_plugin.so(fts_backend_build_more+0x1f)[0xb755658f] -> /usr/dovecot-2/lib/dovecot/lib20_fts_plugin.so(+0x576c) [0xb755976c]-> /usr/dovecot-2/lib/dovecot/libdovecot-storage.so.0(mailbox_search_next_nonblock+0x38)[0xb777f9b8] -> dovecot/imap [mfxxxch 141.42.206.38 UID]() [0x805cbb6] -> dovecot/imap [mfxxxch 141.42.206.38 UID]() [0x805cf84] -> /usr/dovecot-2/lib/dovecot/libdovecot.so.0(io_loop_handle_timeouts+0xd7)[0xb772eea7] -> /usr/dovecot-2/lib/d Jan 12 15:25:59 postamt dovecot: master: Error: service(imap): child 7414 killed with signal 6 (core dumped) GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/dovecot-2/libexec/dovecot/imap...done. Reading symbols from /usr/dovecot-2/lib/dovecot/libdovecot-storage.so.0...done. Loaded symbols for /usr/dovecot-2/lib/dovecot/libdovecot-storage.so.0 Reading symbols from /usr/dovecot-2/lib/dovecot/libdovecot.so.0...done. Loaded symbols for /usr/dovecot-2/lib/dovecot/libdovecot.so.0 Reading symbols from /lib/i686/cmov/libc.so.6...Reading symbols from /usr/lib/debug/lib/i686/cmov/libc-2.11.2.so...done. (no debugging symbols found)...done. Loaded symbols for /lib/i686/cmov/libc.so.6 Reading symbols from /lib/i686/cmov/libdl.so.2...Reading symbols from /usr/lib/debug/lib/i686/cmov/libdl-2.11.2.so...done. (no debugging symbols found)...done. Loaded symbols for /lib/i686/cmov/libdl.so.2 Reading symbols from /lib/i686/cmov/librt.so.1...Reading symbols from /usr/lib/debug/lib/i686/cmov/librt-2.11.2.so...done. (no debugging symbols found)...done. Loaded symbols for /lib/i686/cmov/librt.so.1 Reading symbols from /lib/ld-linux.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.11.2.so...done. (no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/i686/cmov/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/i686/cmov/libpthread-2.11.2.so...done. (no debugging symbols found)...done. Loaded symbols for /lib/i686/cmov/libpthread.so.0 Reading symbols from /usr/dovecot-2/lib/dovecot/lib10_quota_plugin.so...done. Loaded symbols for /usr/dovecot-2/lib/dovecot/lib10_quota_plugin.so Reading symbols from /usr/dovecot-2/lib/dovecot/lib11_imap_quota_plugin.so...done. Loaded symbols for /usr/dovecot-2/lib/dovecot/lib11_imap_quota_plugin.so Reading symbols from /usr/dovecot-2/lib/dovecot/lib11_trash_plugin.so...done. Loaded symbols for /usr/dovecot-2/lib/dovecot/lib11_trash_plugin.so Reading symbols from /usr/dovecot-2/lib/dovecot/lib15_notify_plugin.so...done. Loaded symbols for /usr/dovecot-2/lib/dovecot/lib15_notify_plugin.so Reading symbols from /usr/dovecot-2/lib/dovecot/lib20_fts_plugin.so...done. Loaded symbols for /usr/dovecot-2/lib/dovecot/lib20_fts_plugin.so Reading symbols from /usr/dovecot-2/lib/dovecot/lib20_mail_log_plugin.so...done. Loaded symbols for /usr/dovecot-2/lib/dovecot/lib20_mail_log_plugin.so Reading symbols from /usr/dovecot-2/lib/dovecot/lib20_zlib_plugin.so...done. Loaded symbols for /usr/dovecot-2/lib/dovecot/lib20_zlib_plugin.so Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/libbz2.so.1.0...(no debugging symbols found)...done. Loaded symbols for /lib/libbz2.so.1.0 Reading symbols from /usr/dovecot-2/lib/dovecot/lib21_fts_squat_plugin.so...done. Loaded symbols for /usr/dovecot-2/lib/dovecot/lib21_fts_squat_plugin.so Reading symbols from /usr/lib/gconv/ISO8859-1.so...Reading symbols from /usr/lib/debug/usr/lib/gconv/ISO8859-1.so...done. (no debugging symbols found)...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libgcc_s.so.1 Core was generated by `dovecot/imap'. Program terminated with signal 6, Aborted. #0 0xb781c430 in __kernel_vsyscall () #0 0xb781c430 in __kernel_vsyscall () No symbol table info available. #1 0xb75bd751 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 resultvar = <value optimized out> pid = -1217572876 selftid = 7414 #2 0xb75c0b82 in *__GI_abort () at abort.c:92 act = {__sigaction_handler = {sa_handler = 0xbf9bc380, sa_sigaction = 0xbf9bc380}, sa_mask = {__val = {3078733232, 3214656340, 3078775202, 3214656324, 3077479936, 3214656312, 3078855252, 0, 3077414184, 1, 0, 1, 3078732792, 37, 3214656232, 3077705632, 3077700459, 3077919976, 3214656316, 212213488, 0, 3214656384, 3214656312, 3214656324, 3077705325, 3078732792, 0, 1393, 3214656344, 3077505783, 3214656316, 10}}, sa_flags = -1080310860, sa_restorer = 0xb77569cc <pid.3441>} sigs = {__val = {32, 0 <repeats 31 times>}} #3 0xb7721875 in default_fatal_finish (type=<value optimized out>, status=<value optimized out>) at failures.c:187 backtrace = 0xca616e0 "/usr/dovecot-2/lib/dovecot/libdovecot.so.0(+0x3b861) [0xb7721861] -> /usr/dovecot-2/lib/dovecot/libdovecot.so.0(+0x3b8cf) [0xb77218cf] -> /usr/dovecot-2/lib/dovecot/libdovecot.so.0(i_fatal+0) [0xb76f8"... #4 0xb77218cf in i_internal_fatal_handler (ctx=0xbf9bc424, format=0xb7515fd4 "file %s: line %d (%s): assertion failed: (%s)", args=0xbf9bc444 "UaQ\267l\003") at failures.c:645 status = 0 #5 0xb76f869e in i_panic ( format=0xb7515fd4 "file %s: line %d (%s): assertion failed: (%s)") at failures.c:259 ctx = {type = LOG_TYPE_PANIC, exit_status = 0, timestamp = 0x0} args = 0xbf9bc444 "UaQ\267l\003" #6 0xb75105ca in squat_build_word (ctx=0xa08cee8, uid=52317, data=0xca44741 "\201", char_lengths=0xca271e1 "\002\003", size=1) at squat-trie.c:876 trie = 0xa0a1988 i = <value optimized out> j = <value optimized out> bytelen = <value optimized out> __FUNCTION__ = "squat_build_word" #7 0xb7510e46 in squat_trie_build_more_real (ctx=0xa08cee8, uid=26158, type=SQUAT_INDEX_TYPE_HEADER, input=0xc9c8ec8 "\037\357\277\275\b\b\357\277\275K2,S\n0\357\277\275\067\001\357\277\275W\n\357\277\275\004\304\273\357\277\275I\016\357\277\275\005\004\rI\357\277\275[\357\277\275&@\357\277\275TH^\357\277\275\070\357\277\275\\\003\357\277\275\177'/{M`\n?\357\277\275\062\357\277\275I\357\277\275AXS\f\357\277\275\035\357\277\275Q\357\277\275\061\357\277\275\330\267\357\277\275 P\357\277\275\017\357\277\275.0\357\277\275D\b\357\277\275\327\260\357\277\275Z\357\277\275D\357\277\275\037\357\277\275^O\031\357\277\275U\037\362\232\273\267\357\277\275\017\063\001B}\357\277\275\f\357\277\275W\357\277\275T\032`\357\277\275\037\357\277\275,PF\357\277\275/\tP\357"..., size=120157) at squat-trie.c:934 trie = <value optimized out> data = 0xca44150 "" char_lengths = 0xca26bf0 "\001\003\001\001\001\001\003\001\001\001\001\001\001\001\001\003\001\001\001\001\003\001\001\001\001\003\001\001\001\002\001\003\001\001\001\001\003\001\001\001\001\001\001\003\001\001\001\003\001\001\001\001\003\001\001\001\001\001\003\001\001\001\003\001\001\001\001\003\001\001\001\001\001\001\001\001\001\001\003\001\001\001\003\001\001\001\003\001\001\001\001\001\001\003\001\001\001\003\001\001\001\003\001\001\001\003\001\001\002\001\003\001\001\001\001\003\001\001\001\003\001\001\001\001\003\001\001\001\001\003\001\001\002\001\003\001\001\001\003\001\001\001\003\001\001\001\003\001\001\001\001\001\003\001\001\001\001\004\001\001\001\003\001\001\001\001\001\001\001\003\001\001\001\003\001\001\001\003\001\001\001\001\001\003\001\001\001\003\001\001\001\001\001\003\001\001\001\001\001\003"... i = <value optimized out> multibyte_chars = true ret = 0 start = <value optimized out> #8 squat_trie_build_more (ctx=0xa08cee8, uid=26158, type=SQUAT_INDEX_TYPE_HEADER, input=0xc9c8ec8 "\037\357\277\275\b\b\357\277\275K2,S\n0\357\277\275\067\001\357\277\275W\n\357\277\275\004\304\273\357\277\275I\016\357\277\275\005\004\rI\357\277\275[\357\277\275&@\357\277\275TH^\357\277\275\070\357\277\275\\\003\357\277\275\177'/{M`\n?\357\277\275\062\357\277\275I\357\277\275AXS\f\357\277\275\035\357\277\275Q\357\277\275\061\357\277\275\330\267\357\277\275 P\357\277\275\017\357\277\275.0\357\277\275D\b\357\277\275\327\260\357\277\275Z\357\277\275D\357\277\275\037\357\277\275^O\031\357\277\275U\037\362\232\273\267\357\277\275\017\063\001B}\357\277\275\f\357\277\275W\357\277\275T\032`\357\277\275\037\357\277\275,PF\357\277\275/\tP\357"..., size=120157) at squat-trie.c:963 _data_stack_cur_id = 5 ret = 1523 #9 0xb750db2c in fts_backend_squat_build_more (_ctx=0xa08cf08, data=0xc9c8ec8 "\037\357\277\275\b\b\357\277\275K2,S\n0\357\277\275\067\001\357\277\275W\n\357\277\275\004\304\273\357\277\275I\016\357\277\275\005\004\rI\357\277\275[\357\277\275&@\357\277\275TH^\357\277\275\070\357\277\275\\\003\357\277\275\177'/{M`\n?\357\277\275\062\357\277\275I\357\277\275AXS\f\357\277\275\035\357\277\275Q\357\277\275\061\357\277\275\330\267\357\277\275 P\357\277\275\017\357\277\275.0\357\277\275D\b\357\277\275\327\260\357\277\275Z\357\277\275D\357\277\275\037\357\277\275^O\031\357\277\275U\037\362\232\273\267\357\277\275\017\063\001B}\357\277\275\f\357\277\275W\357\277\275T\032`\357\277\275\037\357\277\275,PF\357\277\275/\tP\357"..., size=120157) at fts-backend-squat.c:166 ctx = 0xa08cf08 #10 0xb755658f in fts_backend_build_more (ctx=0xa08cf08, data=0xc9c8ec8 "\037\357\277\275\b\b\357\277\275K2,S\n0\357\277\275\067\001\357\277\275W\n\357\277\275\004\304\273\357\277\275I\016\357\277\275\005\004\rI\357\277\275[\357\277\275&@\357\277\275TH^\357\277\275\070\357\277\275\\\003\357\277\275\177'/{M`\n?\357\277\275\062\357\277\275I\357\277\275AXS\f\357\277\275\035\357\277\275Q\357\277\275\061\357\277\275\330\267\357\277\275 P\357\277\275\017\357\277\275.0\357\277\275D\b\357\277\275\327\260\357\277\275Z\357\277\275D\357\277\275\037\357\277\275^O\031\357\277\275U\037\362\232\273\267\357\277\275\017\063\001B}\357\277\275\f\357\277\275W\357\277\275T\032`\357\277\275\037\357\277\275,PF\357\277\275/\tP\357"..., size=120157) at fts-api.c:124 No locals. #11 0xb755976c in fts_build_mail_flush_headers (ctx=0xa08cc00, mail=0xa092dc8, tryagain_r=0xbf9bc6ff) at fts-storage.c:83 No locals. #12 fts_build_mail (ctx=0xa08cc00, mail=0xa092dc8, tryagain_r=0xbf9bc6ff) at fts-storage.c:240 decoder_flags = <value optimized out> parser = 0x0 decoder = 0x0 raw_block = {part = 0xa0440b0, hdr = 0x0, data = 0x0, size = 0} prev_part = 0xa0440b0 skip_body = false block = {part = 0xa0440b0, hdr = 0x0, data = 0xc9b9e90 "\031\357\277\275\067S\357\277\275^\fP\357\277\275B\357\277\275Q\357\277\275]\020\357\277\275=Z\357\277\275NL]}\357\277\275\023\357\277\275!U\357\277\275WV\357\277\275$\357\277\275I\357\277\275\020Z$\357\277\275J\357\277\275A\357\277\275S6\357\277\275T\357\277\275\031#\357\277\275@\357\277\275\006\357\277\275\070\357\277\275W6`\357\277\275A\357\277\275\r6\357\277\275S\034\357\277\275\017\357\277\275\v\357\277\275\n\357\277\275\024\357\277\275\017\357\277\275^\357\277\275{\357\277\275\n\357\277\275-\357\277\275\322\256PV\021\357\277\275\001T\357\277\275O\357\277\275~W\357\277\275JQ!*\357\277\275\002*YLK9\310\224\357\277\275Z\003"..., size = 207} ret = <value optimized out> input = 0xc7fb3c8 parts = 0xa0440b0 body_part = true #13 fts_build_more (ctx=0xa08cc00, mail=0xa092dc8, tryagain_r=0xbf9bc6ff) at fts-storage.c:625 _data_stack_cur_id = 4 count = 20 ret = 168349528 #14 fts_mailbox_search_next_nonblock (ctx=0xa08cc00, mail=0xa092dc8, tryagain_r=0xbf9bc6ff) at fts-storage.c:728 fbox = 0xa08b498 fctx = 0xa08ccd8 ret = <value optimized out> #15 0xb777f9b8 in mailbox_search_next_nonblock (ctx=0xa08cc00, mail=0xa092dc8, tryagain_r=0xbf9bc6ff) at mail-storage.c:1182 box = <value optimized out> #16 0x0805cbb6 in cmd_search_more (cmd=0xa06e048) at imap-search.c:347 ctx = 0xa06e108 opts = SEARCH_RETURN_ALL sync_flags = <value optimized out> end_time = {tv_sec = 171970592, tv_usec = -1080309992} range = <value optimized out> count = <value optimized out> id = <value optimized out> id_min = 0 id_max = 0 ok_reply = <value optimized out> time_msecs = <value optimized out> tryagain = <value optimized out> minmax = false lost_data = <value optimized out> __FUNCTION__ = "cmd_search_more" #17 0x0805cf84 in cmd_search_more_callback (cmd=0xa06e048) at imap-search.c:430 client = 0xa06dbe0 finished = <value optimized out> #18 0xb772eea7 in io_loop_handle_timeouts_real (ioloop=0xa04c368) at ioloop.c:353 timeout = 0xa401020 item = 0xa401020 tv = {tv_sec = 0, tv_usec = 0} tv_call = {tv_sec = 1294842354, tv_usec = 702529} t_id = 3 #19 io_loop_handle_timeouts (ioloop=0xa04c368) at ioloop.c:368 _data_stack_cur_id = 2 #20 0xb772ff64 in io_loop_handler_run (ioloop=0xa04c368) at ioloop-epoll.c:186 ctx = 0xa04c490 events = <value optimized out> event = <value optimized out> list = <value optimized out> io = <value optimized out> tv = {tv_sec = 0, tv_usec = 0} events_count = 6 msecs = 0 ret = 0 i = <value optimized out> j = <value optimized out> call = <value optimized out> #21 0xb772ed00 in io_loop_run (ioloop=0xa04c368) at ioloop.c:404 No locals. #22 0xb771a8ea in master_service_run (service=0xa04c2b8, callback=0x805fc20 <client_connected>) at master-service.c:484 No locals. #23 0x08060365 in main (argc=1, argv=0xa04c1c0) at main.c:375 set_roots = {0x8062ce0, 0x0} service_flags = <value optimized out> storage_service_flags = <value optimized out> postlogin_socket_path = <value optimized out> username = <value optimized out> c = <value optimized out> ----- End forwarded message ----- -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt(a)charite.de | http://www.charite.de

1 0