Re: [Dovecot] v1.1.0 released
Congrats timo! Cor
Re: [Dovecot] v1.1.0 released
Congratulations on your new major release. We all appreciate the fine work you are doing.
Re: [Dovecot] no maildirsize file being created -dovecot v1.1
On Jun 21, 2008, at 6:00 AM, Barry R Cisna wrote: It looks to me after setting the mail_debug=yes in the dovecot.conf quota is looking for the maildir to be Maildir (/home/superuser/Maildir, rwx). my install has mailboxes listed as mail>> /home/superuser/mail ( not Maildir) How do i comment the quota to make a directive to correct this? maildir=mail >>not mail=Maildir I'm not sure what you want. Is the ~/mail/ directory a mbox or a maildir? If maildir, you'll need to set: mail_location = maildir:~/mail If it is mbox, you can't use maildir quota backend. You should have had the exact same problem with v1.0.. PGP.sig Description: This is a digitally signed message part
[Dovecot] no maildirsize file being created -dovecot v1.1
It looks to me after setting the mail_debug=yes in the dovecot.conf quota is looking for the maildir to be Maildir >>(/home/superuser/Maildir, rwx). my install has mailboxes listed as mail>> /home/superuser/mail ( not Maildir) How do i comment the quota to make a directive to correct this? maildir=mail >>not mail=Maildir Jun 20 21:35:05 hi3 dovecot: IMAP(superuser): Loading modules from directory: /usr/lib/dovecot/imap Jun 20 21:35:05 hi3 dovecot: IMAP(superuser): Module loaded: /usr/lib/dovecot/imap/lib10_quota_plugin.so Jun 20 21:35:05 hi3 dovecot: IMAP(superuser): Module loaded: /usr/lib/dovecot/imap/lib11_imap_quota_plugin.so Jun 20 21:35:05 hi3 dovecot: IMAP(superuser): Effective uid=500, gid=500, home=/home/superuser Jun 20 21:35:05 hi3 dovecot: IMAP(superuser): Quota root: name= backend=maildir args= Jun 20 21:35:05 hi3 dovecot: IMAP(superuser): Quota rule: root= mailbox=* bytes=104857600 (0%) messages=0 (0%) Jun 20 21:35:05 hi3 dovecot: IMAP(superuser): Quota rule: root= mailbox=Trash bytes=10485760 (10%) messages=0 (0%) Jun 20 21:35:05 hi3 dovecot: IMAP(superuser): Quota rule: root= mailbox=Spam bytes=20971520 (20%) messages=0 (0%) Jun 20 21:35:05 hi3 dovecot: IMAP(superuser): maildir: access(/home/superuser/Maildir, rwx): failed: No such file or directory Jun 20 21:35:05 hi3 dovecot: IMAP(superuser): maildir: couldn't find root dir Jun 20 21:35:05 hi3 dovecot: IMAP(superuser): maildir: Couldn't create mail storage : Root mail directory not given Jun 20 21:35:05 hi3 dovecot: IMAP(superuser): mbox: root exists (/home/superuser/mail) Jun 20 21:35:05 hi3 dovecot: IMAP(superuser): mbox: INBOX exists (/var/mail/superuser) Jun 20 21:35:05 hi3 dovecot: imap-login: Login: user=, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Jun 20 21:35:05 hi3 dovecot: IMAP(superuser): fs: root=/home/superuser/mail, index=, control=, inbox=/var/mail/superuser Jun 20 21:35:05 hi3 dovecot: IMAP(superuser): quota maildir: No maildir storages, ignoring quota. Jun 20 21:35:05 hi3 dovecot: IMAP(superuser): Log synchronization error at seq=2,offset=64 for /home/superuser/mail/.imap/Trash/dovecot.index: uid_validity updated unexpectedly: 1 -> 1213899748 Jun 20 21:35:05 hi3 dovecot: IMAP(superuser): fscking index file /home/superuser/mail/.imap/Trash/dovecot.index Thanks Timo Barry Cisna
Re: [Dovecot] v1.1.0 released
On Jun 21, 2008, at 5:58 AM, Luca Corti wrote: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/lib -I../../src/lib-sql -I../../src/lib-settings -I../../src/lib-ntlm -I../../src/lib-otp -DAUTH_MODULE_DIR=\""/usr/local/lib/dovecot/auth"\" -DPKG_LIBEXECDIR= \""/usr/local/libexec/dovecot"\"-std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -MT auth-master-listener.o -MD -MP -MF .deps/auth-master- listener.Tpo -c -o auth-master-listener.o auth-master-listener.c make[3]: *** [auth-master-listener.o] Segmentation fault make[3]: Leaving directory `/usr/local/src/dovecot/dovecot-1.1.0/src/auth' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/dovecot/dovecot-1.1.0/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/dovecot/dovecot-1.1.0' make: *** [all] Error 2 But if I type just 'make' again after this the build completes successfully. Everything else is fine. Is this dovecot related? Always at the same source file or just somewhat randomly? Either a gcc bug or your memory is broken. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] v1.1.0 released
On Sat, 2008-06-21 at 04:46 +0300, Timo Sirainen wrote: > http://dovecot.org/releases/1.1/dovecot-1.1.0.tar.gz > http://dovecot.org/releases/1.1/dovecot-1.1.0.tar.gz.sig > > Two hours later than promised, I slept longer than intended. :) First of all, great work... > No changes since v1.1.rc13. Below are the largest changes since v1.0: I've been testing 1.1 betas/rcs since a long time with my few gigabites of maildirs. Noticed no big isses. All I had to do lately was $ ./configure && make an then rebuild sieve, install and restart dovecot. With 1.1rc3/1.1.0 i experience this minor compile issue. Basically if I do: $ ./configure && make build fails with gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/lib -I../../src/lib-sql -I../../src/lib-settings -I../../src/lib-ntlm -I../../src/lib-otp -DAUTH_MODULE_DIR=\""/usr/local/lib/dovecot/auth"\" -DPKG_LIBEXECDIR= \""/usr/local/libexec/dovecot"\"-std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -MT auth-master-listener.o -MD -MP -MF .deps/auth-master-listener.Tpo -c -o auth-master-listener.o auth-master-listener.c make[3]: *** [auth-master-listener.o] Segmentation fault make[3]: Leaving directory `/usr/local/src/dovecot/dovecot-1.1.0/src/auth' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/dovecot/dovecot-1.1.0/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/dovecot/dovecot-1.1.0' make: *** [all] Error 2 But if I type just 'make' again after this the build completes successfully. Everything else is fine. Is this dovecot related? ciao Luca
Re: [Dovecot] Cygwin and dovecot-auth problems
On Sat, 2008-06-21 at 00:45 +, TBlack wrote: > Warning: fd limit 256 is lower than what Dovecot can use under full load > (more than 640). Either grow the limit or change login_max_processes_count > and max_mail_processes settings > Warning: Last died with error (see error log for more information): Auth > process died too early - shutting down Look at the logs for the exact reason why auth process died. http://wiki.dovecot.org/Logging > Trying to run just dovecot-auth outputs: > > dovecot-auth: Fatal: MECHANISMS environment is unset This is normal. You shouldn't try to run dovecot-auth directly. signature.asc Description: This is a digitally signed message part
[Dovecot] v1.1.0 released
http://dovecot.org/releases/1.1/dovecot-1.1.0.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.0.tar.gz.sig Two hours later than promised, I slept longer than intended. :) No changes since v1.1.rc13. Below are the largest changes since v1.0: * After Dovecot v1.1 has modified index or dovecot-uidlist files, they can't be opened anymore with Dovecot versions earlier than v1.0.2. * See doc/wiki/Upgrading.1.1.txt (or for latest changes, http://wiki.dovecot.org/Upgrading/1.1) for list of changes since v1.0 that you should be aware of when upgrading. + IMAP: Added support for UIDPLUS and LIST-EXTENDED extensions. + IMAP SORT: Sort keys are indexed, which makes SORT commands faster. + When saving messages, update cache file immediately with the data that we expect client to fetch later. + NFS caches are are flushed whenever needed. See mail_nfs_storage and mail_nfs_index settings. + Out of order command execution (SEARCH, FETCH, LIST), nonstandard command cancellation (X-CANCEL ) + IMAP: STATUS-IN-LIST draft implementation + Expire plugin can be used to keep track of oldest messages in specific mailboxes. A nightly run can then quickly expunge old messages from the mailboxes that have them. The tracking is done using lib-dict, so you can use either Berkeley DB or SQL database. + Namespaces are supported everywhere now. + Namespaces have new list and subscriptions settings. + Full text search indexing support with Lucene and Squat backends. + OTP and S/KEY authentication mechanisms (by Andrey Panin). + mbox and Maildir works with both Maildir++ and FS layouts. You can change these by appending :LAYOUT=maildir++ or :LAYOUT=fs to mail_location. + LDAP: Support templates in pass_attrs and user_attrs + Support for listening in multiple IPs/ports. + Quota plugin rewrite: Support for multiple quota roots, warnings, allow giving storage size in bytes or kilo/mega/giga/terabytes, per-mailbox quota rules. + Filesystem quota backend supports inode limits, group quota and RPC quota for NFS. + SEARCH and SORT finally compare non-ASCII characters case-insensitively. We use i;unicode-casemap algorithm. + Config files support splitting values to multiple lines with \ signature.asc Description: This is a digitally signed message part
Re: [Dovecot] SSL + compression?
On Sat, 2008-06-21 at 00:17 +0200, Johannes Berg wrote: > On Sat, 2008-06-21 at 00:13 +0200, Johannes Berg wrote: > > > > Back to the original question - discount SSH - how do we get > > > > compression + SSL out of openssl.. > > > > > > I don't think it's possible. OpenSSL says, in the NOTES section of > > > SSL_COMP_add_compression_method(3): > > > > > > The TLS standard (or SSLv3) allows the integration of > > > compression methods into the communication. The TLS RFC does > > > however not specify compression methods or their corresponding > > > identifiers, so there is currently no compatible way to > > > integrate compression with unknown peers. It is therefore > > > currently not recommended to integrate compression into > > > applications. Applications for non-public use may agree on > > > certain compression methods. Using different compression methods > > > with the same identifier will lead to connection failure. > > > > However, there is http://tools.ietf.org/html/draft-ietf-tls-compression, > > but openssl doesn't support that (only zlib and rle) > > I'm way behind the times. > http://www.faqs.org/rfc/rfc3749.txt Looking at OpenSSL code, I think the patch below will give 0.9.8 ability to support deflate compression. I'm not sure if I should include that to Dovecot though. At least not for v1.1. :) diff -r 68a0be847980 src/login-common/ssl-proxy-openssl.c --- a/src/login-common/ssl-proxy-openssl.c Fri Jun 20 12:20:17 2008 +0300 +++ b/src/login-common/ssl-proxy-openssl.c Sat Jun 21 04:29:51 2008 +0300 @@ -719,6 +719,7 @@ ssl_clean_free); SSL_library_init(); SSL_load_error_strings(); + (void)SSL_COMP_get_compression_methods(); extdata_index = SSL_get_ex_new_index(0, dovecot, NULL, NULL, NULL); signature.asc Description: This is a digitally signed message part
Re: [Dovecot] acl imap_capability ? 1.1.rc12
On Fri, 2008-06-20 at 18:44 +0200, Robert Schetterer wrote: > Hi all, is acl ( with acl plugin enabled ) > anounced in imap_capability list by dovecot > i cant find it in telnet tests, so is it my fault or > is it default beavior using 1.1.rc12 ACL capability announces support for IMAP ACL commands, but they aren't implemented in Dovecot yet. ACL plugin only allows Dovecot to read manually created dovecot-acl files. signature.asc Description: This is a digitally signed message part
[Dovecot] Cygwin and dovecot-auth problems
Hi all. I'm trying to install Dovecot 1.1.rc13 on Cygwin. I've read the related posts, and I realize that maybe there's no solution at present; since I'm having a different error, though, I'm posting it here. Compilation succeeds. Starting dovecot from command line results in: Warning: fd limit 256 is lower than what Dovecot can use under full load (more than 640). Either grow the limit or change login_max_processes_count and max_mail_processes settings Warning: Last died with error (see error log for more information): Auth process died too early - shutting down Trying to run just dovecot-auth outputs: dovecot-auth: Fatal: MECHANISMS environment is unset Now, if I try to set an environment variable called MECHANISMS (say, export MECHANISMS=plain) I get a different error: dovecot-auth: Fatal: No passdbs specified in configuration file. PLAIN mechanism needs one This is the output of dovecot -n: # 1.1.rc13: /usr/local/etc/dovecot.conf Warning: fd limit 256 is lower than what Dovecot can use under full load (more than 640). Either grow the limit or change login_max_processes_count and max_mail_processes settings log_path: /tmp/logs/dovecot-error.log info_log_path: /tmp/logs/dovecot-other.log listen: 127.0.0.1 ssl_disable: yes ssl_cipher_list: ALL:!LOW:!SSLv2 disable_plaintext_auth: no login_dir: /usr/local/var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/imap-login login_user: MyUser login_greeting: Yo, mate. login_process_per_connection: no login_greeting_capability: yes login_process_size: 0 mail_max_userip_connections: 20 verbose_proctitle: yes mail_location: maildir:~/Maildir mail_process_size: 0 auth default: verbose: yes debug: yes process_size: 0 passdb: driver: passwd-file args: /etc/passwd userdb: driver: passwd-file args: /etc/passwd Any clues or suggestions, anything I could try...? ^__^ Thanks, Angelo ___ Scopri il Blog di Yahoo! Mail: trucchi, novità, consigli... e la tua opinione! http://www.ymailblogit.com/blog/
Re: [Dovecot] no maildirsize file being created -dovecot v1.1
On Jun 21, 2008, at 1:26 AM, Barry R Cisna wrote: Problem: I can not get my dovecot 1.1 rc10(rpm) to generate an maildirsize file in each of the users homedir. I have re-edited the dovecot.conf file many many times but still no joy. Set mail_debug=yes and see what gets logged. How would I go about troubleshooting this. The only error I get in maillog is when I log into SM I do see were dovecot tries to check for the maildirsize file but it can not find it of course and then says " skipping quota check",, Really? I don't remember Dovecot having any such log message. Please paste it entirely and exactly. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] v1.1.rc13 released
On Jun 20, 2008, at 11:04 PM, Diego Liziero wrote: Any chance to have this assert converted to error as last patch before 1.1? Or am I the only one that is still getting this in rc13? Yes, you're the only one.. I should try looking into that bug again at some point.. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] Random quirks in 1.1-rc11
On Jun 20, 2008, at 7:45 PM, Marc Perkel wrote: A little more information. One ove my server side folders became essentially inaccessable. The folder was empty. This folder is actually emptied by another process that reads and deletes the content of this folder. Using Thunderbird the message count showed as having 1 message but no messages showed up. I dragged a new message into the folder and that new message wasn't visible. I then restarted dovecot and the folder started behaving normally again. I'm going to download and install the latests to see if the bug goes away. Unfortunately it's not a consistent bug to reproduce. Enable rawlogs (http://wiki.dovecot.org/Debugging/Rawlog). Then you'll see what exactly Dovecot is sending to TB. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] SSL + compression?
On Fri, 2008-06-20 at 18:25 +0100, Ed W wrote: > OK, my interested is piqued now - does anyone have a recipe for how to > make openssl compress the traffic before encrypting it? (Or perhaps it > does by default?) Incidentally, and you may complain about it being off-topic again, there's also an IMAP compression extension: http://tools.ietf.org/html/rfc4978 No idea if anybody implements it yet though. johannes signature.asc Description: This is a digitally signed message part
[Dovecot] no maildirsize file being created -dovecot v1.1
Hello List,
Getting ready to setup a new dovecot sendmail squirrelmail server for
our school which is currently running on a 4 year old install of the
same, which has worked like a champ by the way.
-
EL5
dovecot-1.1 rc10 rpm
sendmail
squirrelmail
-
Problem: I can not get my dovecot 1.1 rc10(rpm) to generate an
maildirsize file in each of the users homedir. I have re-edited the
dovecot.conf file many many times but still no joy.
If I uninstall and install the default dovecot 1.0.1x rpm that ships
with EL5 i get the maildirsize file to generate correctly without a
hitch. I am wanting to use the check_quota plugin for SM this time so I
need to get this functioning correctly.
How would I go about troubleshooting this. The only error I get in
maillog is when I log into SM I do see were dovecot tries to check for
the maildirsize file but it can not find it of course and then says "
skipping quota check",,so I think I have my dovecot.conf file setup
correctly. Dovecot is simply not generating the maildirsize file.
Following lines added to the end of dovecot.conf file:
protocol imap {
mail_plugins = quota imap_quota
}
protocol pop3 {
mail_plugins = quota
}
# In case you're using deliver:
protocol lda {
mail_plugins = quota
}
plugin {
quota = maildir
quota_rule = *:storage=1GB
# 10% of 1GB = 100MB
quota_rule2 = Trash:storage=10%%
# 20% of 1GB = 200MB
quota_rule3 = Spam:storage=20%%
}
,,I have reversed the above to have quota=maildir,,etc
above the protocol directives as well and still no joy.
Sidenote: I also tried dovecot v1.1 rc5 rpm as well with the same results.
Any tips from anyone would be appreciated.
Thanks,
Barry Cisna
Re: [Dovecot] SSL + compression?
On Sat, 2008-06-21 at 00:13 +0200, Johannes Berg wrote: > > > Back to the original question - discount SSH - how do we get > > > compression + SSL out of openssl.. > > > > I don't think it's possible. OpenSSL says, in the NOTES section of > > SSL_COMP_add_compression_method(3): > > > > The TLS standard (or SSLv3) allows the integration of > > compression methods into the communication. The TLS RFC does > > however not specify compression methods or their corresponding > > identifiers, so there is currently no compatible way to > > integrate compression with unknown peers. It is therefore > > currently not recommended to integrate compression into > > applications. Applications for non-public use may agree on > > certain compression methods. Using different compression methods > > with the same identifier will lead to connection failure. > > However, there is http://tools.ietf.org/html/draft-ietf-tls-compression, > but openssl doesn't support that (only zlib and rle) I'm way behind the times. http://www.faqs.org/rfc/rfc3749.txt johannes signature.asc Description: This is a digitally signed message part
Re: [Dovecot] SSL + compression?
> > Back to the original question - discount SSH - how do we get > > compression + SSL out of openssl.. > > I don't think it's possible. OpenSSL says, in the NOTES section of > SSL_COMP_add_compression_method(3): > > The TLS standard (or SSLv3) allows the integration of > compression methods into the communication. The TLS RFC does > however not specify compression methods or their corresponding > identifiers, so there is currently no compatible way to > integrate compression with unknown peers. It is therefore > currently not recommended to integrate compression into > applications. Applications for non-public use may agree on > certain compression methods. Using different compression methods > with the same identifier will lead to connection failure. However, there is http://tools.ietf.org/html/draft-ietf-tls-compression, but openssl doesn't support that (only zlib and rle) johannes signature.asc Description: This is a digitally signed message part
Re: [Dovecot] SSL + compression?
On Fri, 2008-06-20 at 23:04 +0100, Ed W wrote: > Johannes Berg wrote: > > > I don't think it does be default. The only what I know is to establish a > > > compressed SSH tunnel to your server and then access the server over the > > > tunnel. It will compress and give you an extra layer of encryption. > > > > > > > Umm, no. It will not compress. Think about it, encrypted data is > > fundamentally not compressible, that's the whole point. > > > > > > We are way off topic... :) > Back to the original question - discount SSH - how do we get > compression + SSL out of openssl.. I don't think it's possible. OpenSSL says, in the NOTES section of SSL_COMP_add_compression_method(3): The TLS standard (or SSLv3) allows the integration of compression methods into the communication. The TLS RFC does however not specify compression methods or their corresponding identifiers, so there is currently no compatible way to integrate compression with unknown peers. It is therefore currently not recommended to integrate compression into applications. Applications for non-public use may agree on certain compression methods. Using different compression methods with the same identifier will lead to connection failure. johannes signature.asc Description: This is a digitally signed message part
Re: [Dovecot] SSL + compression?
Johannes Berg wrote: I don't think it does be default. The only what I know is to establish a compressed SSH tunnel to your server and then access the server over the tunnel. It will compress and give you an extra layer of encryption. Umm, no. It will not compress. Think about it, encrypted data is fundamentally not compressible, that's the whole point. We are way off topic... Back to the original question - discount SSH - how do we get compression + SSL out of openssl.. Ed W
Re: [Dovecot] Time moved backwards by 4398 seconds
Bill Cole wrote: > At 11:10 AM +0200 6/20/08, Anders wrote: >>By that line, the entire "time moved backwards" thing does not belong >>in Dovecot. > > I suspect that you don't understand why that is in Dovecot. Timo has > explained it in detail a few times, but the bottom line is simple: > running through the same system-clock time more than once induces a > very real risk of destroying mail. ... and running through the same system clock twice is exactly what you will do if you fail to detect a temporary forward jump of 1.2 hours when it happens. I might follow your advice of "notsc", it makes me a bit uncomfortable that gettimeofday() can fail for other applications as well. Cheers, Anders.
Re: [Dovecot] SSL + compression?
> > IOW, > > dovecot would see an SSL connection too. > > Hmm, yes. I took it to mean that the 'encrypt' of > > encrypt(compress(imap stream)) > > was the "extra layer". But, I think your interpretation is more easily > arrived at, and if it's what Mark meant, you're absolutely right that the > tunnel won't help. > > A compressed SSH tunnel to regular, non-SSL IMAP should work to reduce > traffic, though. Absolutely. And it'll even be considered 'secure' since local connections are secure. OTOH, if you're going to the trouble to use ssh anyway, can Thunderbird do something like a "connect command"? I use that in evolution, and mine looks like something like this: ssh -C mailserver '/usr/sbin/dovecot --exec-mail imap' where 'mailserver' really is an alias in my .ssh/config johannes signature.asc Description: This is a digitally signed message part
Re: [Dovecot] SSL + compression?
On Fri, 20 Jun 2008, Johannes Berg wrote: I don't think it does be default. The only what I know is to establish a compressed SSH tunnel to your server and then access the server over the tunnel. It will compress and give you an extra layer of encryption. Umm, no. It will not compress. Think about it, encrypted data is fundamentally not compressible, that's the whole point. [...me...] Well, as far as I understood Marc, since he was saying "an extra layer of encryption" I understood him to mean that he wanted to encrypt(compress(encrypt(imap stream))) by building an ssh-tunnelled imaps (or imap/tls) connection. IOW, dovecot would see an SSL connection too. Hmm, yes. I took it to mean that the 'encrypt' of encrypt(compress(imap stream)) was the "extra layer". But, I think your interpretation is more easily arrived at, and if it's what Mark meant, you're absolutely right that the tunnel won't help. A compressed SSH tunnel to regular, non-SSL IMAP should work to reduce traffic, though. Best, Ben
Re: [Dovecot] SSL + compression?
> >> I don't think it does be default. The only what I know is to establish > >> a compressed SSH tunnel to your server and then access the server over > >> the tunnel. It will compress and give you an extra layer of encryption. > > > > Umm, no. It will not compress. Think about it, encrypted data is > > fundamentally not compressible, that's the whole point. > > x = length(compress(encrypt(data))) > y = length(encrypt(compress(data))) > z = length(encrypt(data)) > > Then, usually, x > y and z > y, but x is approximately the same as z. > (That's speaking very generally; there may be optimizations in some case > or another given your data.) > > That is: encrypted data is less compressible than the original data, but > if you compress first, then encrypt, it should be a win. > > If I recall correctly, a "compressed SSH tunnel" would do 'y' (compress > then encrypt). i.e., dovecot would see a non-SSL connection which gets > compressed-then-encrypted, or decrypted-then-uncompressed by the endpoints > of the tunnel. Well, as far as I understood Marc, since he was saying "an extra layer of encryption" I understood him to mean that he wanted to encrypt(compress(encrypt(imap stream))) by building an ssh-tunnelled imaps (or imap/tls) connection. IOW, dovecot would see an SSL connection too. johannes signature.asc Description: This is a digitally signed message part
Re: [Dovecot] SSL + compression?
On Fri, 20 Jun 2008, Johannes Berg wrote: I don't think it does be default. The only what I know is to establish a compressed SSH tunnel to your server and then access the server over the tunnel. It will compress and give you an extra layer of encryption. Umm, no. It will not compress. Think about it, encrypted data is fundamentally not compressible, that's the whole point. x = length(compress(encrypt(data))) y = length(encrypt(compress(data))) z = length(encrypt(data)) Then, usually, x > y and z > y, but x is approximately the same as z. (That's speaking very generally; there may be optimizations in some case or another given your data.) That is: encrypted data is less compressible than the original data, but if you compress first, then encrypt, it should be a win. If I recall correctly, a "compressed SSH tunnel" would do 'y' (compress then encrypt). i.e., dovecot would see a non-SSL connection which gets compressed-then-encrypted, or decrypted-then-uncompressed by the endpoints of the tunnel. Best, Ben
Re: [Dovecot] v1.1.rc13 released
Any chance to have this assert converted to error as last patch before 1.1?
Or am I the only one that is still getting this in rc13?
Regards,
Diego
--- ./src/lib-storage/index/index-sync.c-orig 2008-03-13
16:46:36.0 +0100
+++ ./src/lib-storage/index/index-sync.c2008-03-13
16:51:38.0 +0100
@@ -36,7 +36,9 @@
void index_mailbox_set_recent_uid(struct index_mailbox *ibox, uint32_t uid)
{
if (uid <= ibox->recent_flags_prev_uid) {
- i_assert(seq_range_exists(&ibox->recent_flags, uid));
+ /*i_assert(seq_range_exists(&ibox->recent_flags, uid));*/
+ if (!seq_range_exists(&ibox->recent_flags, uid))
+ i_error("seq_range_exists(&ibox->recent_flags,
uid) uid=%d",uid);
return;
}
ibox->recent_flags_prev_uid = uid;
Re: [Dovecot] SSL + compression?
> I don't think it does be default. The only what I know is to establish a > compressed SSH tunnel to your server and then access the server over the > tunnel. It will compress and give you an extra layer of encryption. Umm, no. It will not compress. Think about it, encrypted data is fundamentally not compressible, that's the whole point. johannes signature.asc Description: This is a digitally signed message part
Re: [Dovecot] SSL + compression?
Ed W wrote: OK, my interested is piqued now - does anyone have a recipe for how to make openssl compress the traffic before encrypting it? (Or perhaps it does by default?) Ed W I don't think it does be default. The only what I know is to establish a compressed SSH tunnel to your server and then access the server over the tunnel. It will compress and give you an extra layer of encryption.
[Dovecot] SSL + compression?
OK, my interested is piqued now - does anyone have a recipe for how to make openssl compress the traffic before encrypting it? (Or perhaps it does by default?) Ed W
Re: [Dovecot] Random quirks in 1.1-rc11
A little more information. One ove my server side folders became essentially inaccessable. The folder was empty. This folder is actually emptied by another process that reads and deletes the content of this folder. Using Thunderbird the message count showed as having 1 message but no messages showed up. I dragged a new message into the folder and that new message wasn't visible. I then restarted dovecot and the folder started behaving normally again. I'm going to download and install the latests to see if the bug goes away. Unfortunately it's not a consistent bug to reproduce.
[Dovecot] acl imap_capability ? 1.1.rc12
Hi all, is acl ( with acl plugin enabled ) anounced in imap_capability list by dovecot i cant find it in telnet tests, so is it my fault or is it default beavior using 1.1.rc12 -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: [Dovecot] Time moved backwards by 4398 seconds
At 11:10 AM +0200 6/20/08, Anders wrote: Johannes Berg <[EMAIL PROTECTED]> writes: On Fri, 2008-06-20 at 10:53 +0200, Anders wrote: I was puzzled that it was always 4398 seconds, in particular because this server runs an NTP daemon. A little searching for this problem shows that it is an issue with the Linux kernel gettimeofday(), see e.g. http://lkml.org/lkml/2007/8/23/96 The thread puts it down to buggy hardware and puts a workaround into the kernel where it belongs, not in dovecot. I think it is more accurate to say "hardware being used for a purpose its designers did not intend" instead. Using the TSC as a clock has been iffy for quite some time, and defaulting to it in the kernel is a risky design choice and must be implemented with extreme caution. It's not that the hardware is buggy,but rather that it does things by design that are not obvious from a high-level description. That's not helpful. By that line, the entire "time moved backwards" thing does not belong in Dovecot. I suspect that you don't understand why that is in Dovecot. Timo has explained it in detail a few times, but the bottom line is simple: running through the same system-clock time more than once induces a very real risk of destroying mail. Anyway, I was not proposing the patch to be included, just asking for advice as to whether it would be safe. I even noted that it was ugly. "Safe" is subjective. I think it would be safer (at the cost of a bounded amount of time) to nanosleep or maybe usleep once and retry the call rather than to go into the loop. As I am already compiling Dovecot myself, I prefer a patch there, rather than diverting from the distribution kernel. You might even be better off configuring your system to not use the TSC as a clock source. There's a strong chance that you won't really be sacrificing anything that you actually use. -- Bill Cole [EMAIL PROTECTED]
[Dovecot] Quota warning question
Hi. Read the example conf and doku about the quota warning stuff, but how might such a "sh" file may look? If i want to sent a mail to the user, how to get the mail address? Wheres the glue between the "sh" file and the percentage given and the user? thx for hints Torsten -- Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge. Siehe http://www.gnu.org/philosophy/no-word-attachments.de.html Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect." -- Linus Torvalds smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] v1.2 development tree started
On Fri, 2008-06-20 at 13:39 +0100, Ed W wrote: > >> Can I make a very weak suggestion to look at that ZLIB compression > >> extension I think you mentioned in the past? > > > > It would have to be done by proxying in imap-login similar to how SSL > > connections are handled. But aren't you using SSL already, and why > > not? Using that would give compression for free. Although I haven't > > really looked at if it's already automatically enabled or if I or > > clients should do something special.. > > I don't think that SSL in general has compression enabled? Could be > wrong, but I believe it's a option, but badly supported? I'm not an > expert though so I don't know that for sure... I would be interested if > someone had a recipe for enabling compression on TLS? Personally, just as a data point, I use SS_H_ (dovecot --exec-mail imap) to connect to my imap host and enable compression using -C, which seems to have a good effect. johannes signature.asc Description: This is a digitally signed message part
Re: [Dovecot] v1.2 development tree started
Can I make a very weak suggestion to look at that ZLIB compression extension I think you mentioned in the past? It would have to be done by proxying in imap-login similar to how SSL connections are handled. But aren't you using SSL already, and why not? Using that would give compression for free. Although I haven't really looked at if it's already automatically enabled or if I or clients should do something special.. I don't think that SSL in general has compression enabled? Could be wrong, but I believe it's a option, but badly supported? I'm not an expert though so I don't know that for sure... I would be interested if someone had a recipe for enabling compression on TLS? Also if you use SSL then you can no longer do after the fact compression. By definition, encryption done well produces an output which cannot be compressed. So it's even more important to precompress before encryption Anyway, just a thought - I'm assuming that the probable implementation is going to be fairly simple. I would think that zlib and/or lzo would be good compressors if there is a choice of implementations? Certainly LZO would be a good choice for faster 100mbit connections http://www.ietf.org/rfc/rfc4978.txt specifies DEFLATE format that can be implemented using zlib. I think this is probably what you referenced before. My own experience is using a very powerful (cpu hungry) compressor where it doesn't seem to matter all that much if stuff is base64 encoded or not. Long shot is that whilst all that reflushing sounds really nice I think it's just icing compared with just doing blind compression of everything... My guess is that with the replication stuff you are going to see a 5x-10x speedup on exchanging long lists of guids to compare folders, etc. Compression on the actual mailbodies may be much less. In my case even with an incompressible jpg file which is base64 encoded we still knock off the expected 1/3 in file size due to the base64 encoding so it's a nice benefit (My customers are on dialup connections of just 2,400 baud... ie 20KB per *minute* http://www.mailasail.com ) For replication I would have thought support of an optional non RFC LZO compressor would be beneficial on anything under gigabit links..? Ed W
Re: [Dovecot] v1.2 development tree started
On Jun 20, 2008, at 3:02 PM, Ed W wrote: Timo Sirainen wrote: This one is the last major unimplemented v1.2 feature. Can I make a very weak suggestion to look at that ZLIB compression extension I think you mentioned in the past? It would have to be done by proxying in imap-login similar to how SSL connections are handled. But aren't you using SSL already, and why not? Using that would give compression for free. Although I haven't really looked at if it's already automatically enabled or if I or clients should do something special.. Anyway, just a thought - I'm assuming that the probable implementation is going to be fairly simple. I would think that zlib and/or lzo would be good compressors if there is a choice of implementations? Certainly LZO would be a good choice for faster 100mbit connections http://www.ietf.org/rfc/rfc4978.txt specifies DEFLATE format that can be implemented using zlib. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] v1.1.rc13 released
Timo Sirainen wrote: http://dovecot.org/releases/1.1/rc/dovecot-1.1.rc13.tar.gz http://dovecot.org/releases/1.1/rc/dovecot-1.1.rc13.tar.gz.sig There's always time for one more release candidate. :) I was planning on releasing v1.1.0 a couple of minutes before summer solstice (23:59 UTC according to Wikipedia). Maybe it'll bring luck to the release. :) - mbox: Fixed a crash when adding a new X-IMAPbase: header with keywords. - Message parser: Fixed assert-crash if cached MIME structure was broken. - Squat: Potential crashfix with mmap_disable=yes. Hmm, I get two extra compile warnings compared to 1.1.rc12: mail-cache-fields.c: In function `mail_cache_header_fields_update': mail-cache-fields.c:485: warning: passing arg 2 of `mail_cache_lock' makes integer from pointer without a cast test-lib.c: In function `test_array': test-lib.c:21: warning: this decimal constant is unsigned only in ISO C90 Solaris 8 sparc/gcc 3.3.2 as usual :) Anything to worry about? Chris -- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, [EMAIL PROTECTED] IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
Re: [Dovecot] sig11 in 1.1rc5 fts
On Fri, Jun 20, 2008 at 11:55:02AM +0300, Timo Sirainen wrote: On Thu, 2008-06-19 at 17:14 -0400, Adam McDougall wrote: > This happened from one user near noon on the 17th and 19th (today) of > this month. From the backtrace it looks like they were searching, but I > won't know for sure unless I need to ask them. Is this possibly fixed > already? I just haven't upgraded dovecot in a while due to lack of > problems. The sig11 happened a few dozen times, a few seconds apart > each day. I have one coredump from each day, and the size was the > same. This is a trace from only one. The other backtrace looks pretty > much the same. > > Version: 1.1rc5 > OS: FreeBSD 7.0-STABLE > > > #0 0x4101bf11 in node_read_children (trie=0x40c5a800, > node=0x40c5a800, level=1) at squat-trie.c:461 I think this will help: http://hg.dovecot.org/dovecot-1.1/rev/2c279e5e1cb9 Thanks, I upgraded my testing server to rc13 and had the user try searching and success was reported. I have around 8-10 people testing rc13 and if all goes well, I'll roll that (or 1.1 final) out to the rest of my users.
Re: [Dovecot] v1.2 development tree started
Timo Sirainen wrote: This one is the last major unimplemented v1.2 feature. Can I make a very weak suggestion to look at that ZLIB compression extension I think you mentioned in the past? The motivation is that I find my "8 mbit broadband" link seems to saturate at quite low numbers of headers per second when Thunderbird is pulling down new mailbox messages. As you know on most of my machines I use our compression proxy application which is very noticably increasing my mailbox access speeds even on cutting edge broadband (for europe). Now whilst probably zero clients implement the compression extension this is also a chicken/egg thing so we could start by having a working implementation on the server end at least Second reason is that this suggests that a typical rented server with a meagre 100mbit connection could be network limited while replicating, rather than being network or CPU bound. A lightly compressed protocol *might* be a win even on fairly fast connections simply because many of the imap command outputs seem to compress extremely well (13:1 is typical based on the rather inefficient way OE accesses IMAP and 4:1 average is very normal even for more efficient implementations - YMMV) Anyway, just a thought - I'm assuming that the probable implementation is going to be fairly simple. I would think that zlib and/or lzo would be good compressors if there is a choice of implementations? Certainly LZO would be a good choice for faster 100mbit connections Ed W
Re: [Dovecot] Time moved backwards by 4398 seconds
> This bug causes Dovecot to run the IO loop in the future for one > iteration, and then die when we get back to present time. > > By the time Dovecot dies, some damage could already have happend, for > example if ioloop_time is stored to permanent storage. Hmm, ok, I was under the impression it aborted early enough. > BTW, can you send a link to the post with the resolution for the kernel? > I didn't manage to find any final conclusion, but I would like to > propose the fix to our kernel provider :). I didn't actually look up any fix just there were fixes in the thread. Didn't check which one if any was merged though. johannes signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Time moved backwards by 4398 seconds
Johannes Berg wrote: On Fri, 2008-06-20 at 11:10 +0200, Anders wrote: Johannes Berg <[EMAIL PROTECTED]> writes: On Fri, 2008-06-20 at 10:53 +0200, Anders wrote: I was puzzled that it was always 4398 seconds, in particular because this server runs an NTP daemon. A little searching for this problem shows that it is an issue with the Linux kernel gettimeofday(), see e.g. http://lkml.org/lkml/2007/8/23/96 The thread puts it down to buggy hardware and puts a workaround into the kernel where it belongs, not in dovecot. That's not helpful. By that line, the entire "time moved backwards" thing does not belong in Dovecot. Why? That's a different thing, dovecot is detecting that something is wrong and that it will be unsafe for it to continue operating. That's an entirely different class than trying to work around the detected problem, imho. This bug causes Dovecot to run the IO loop in the future for one iteration, and then die when we get back to present time. By the time Dovecot dies, some damage could already have happend, for example if ioloop_time is stored to permanent storage. BTW, can you send a link to the post with the resolution for the kernel? I didn't manage to find any final conclusion, but I would like to propose the fix to our kernel provider :). Thanks, Anders.
Re: [Dovecot] Time moved backwards by 4398 seconds
On Fri, 2008-06-20 at 11:10 +0200, Anders wrote: > Johannes Berg <[EMAIL PROTECTED]> writes: > > > On Fri, 2008-06-20 at 10:53 +0200, Anders wrote: > >> > >> I was puzzled that it was always 4398 seconds, in particular because > >> this server runs an NTP daemon. A little searching for this problem > >> shows that it is an issue with the Linux kernel gettimeofday(), see > >> e.g. http://lkml.org/lkml/2007/8/23/96 > > > > The thread puts it down to buggy hardware and puts a workaround into the > > kernel where it belongs, not in dovecot. > > That's not helpful. > > By that line, the entire "time moved backwards" thing does not belong > in Dovecot. Why? That's a different thing, dovecot is detecting that something is wrong and that it will be unsafe for it to continue operating. That's an entirely different class than trying to work around the detected problem, imho. > Anyway, I was not proposing the patch to be included, just asking for > advice as to whether it would be safe. I even noted that it was ugly. Ok. Yeah, it does seem safe, but as Timo said it'll loop there in case there is an actual forward jump. > As I am already compiling Dovecot myself, I prefer a patch there, > rather than diverting from the distribution kernel. Heh, ok. johannes signature.asc Description: This is a digitally signed message part
[Dovecot] v1.1.rc13 released
http://dovecot.org/releases/1.1/rc/dovecot-1.1.rc13.tar.gz http://dovecot.org/releases/1.1/rc/dovecot-1.1.rc13.tar.gz.sig There's always time for one more release candidate. :) I was planning on releasing v1.1.0 a couple of minutes before summer solstice (23:59 UTC according to Wikipedia). Maybe it'll bring luck to the release. :) - mbox: Fixed a crash when adding a new X-IMAPbase: header with keywords. - Message parser: Fixed assert-crash if cached MIME structure was broken. - Squat: Potential crashfix with mmap_disable=yes. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Time moved backwards by 4398 seconds
On Fri, 2008-06-20 at 10:53 +0200, Anders wrote: > Dovecot (v1.1.rc8) died tonight, with an error about time moving > backwards by 4398 seconds. I can see from logs that this has happend a > few times before with the imap processes, without me noticing. I sure > noticed the master process missing, though :-). > > I was puzzled that it was always 4398 seconds, in particular because > this server runs an NTP daemon. A little searching for this problem > shows that it is an issue with the Linux kernel gettimeofday(), see > e.g. http://lkml.org/lkml/2007/8/23/96 > > Below is a patch (untested) to work around this issue. Do you see > something wrong with this approach, apart from the uglyness? Only problem I can see is that if there's a legitimate jump of 4395 seconds it'll busy-loop for 5 seconds before continuing. Probably not very likely to happen. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Time moved backwards by 4398 seconds
Johannes Berg <[EMAIL PROTECTED]> writes: > On Fri, 2008-06-20 at 10:53 +0200, Anders wrote: >> >> I was puzzled that it was always 4398 seconds, in particular because >> this server runs an NTP daemon. A little searching for this problem >> shows that it is an issue with the Linux kernel gettimeofday(), see >> e.g. http://lkml.org/lkml/2007/8/23/96 > > The thread puts it down to buggy hardware and puts a workaround into the > kernel where it belongs, not in dovecot. That's not helpful. By that line, the entire "time moved backwards" thing does not belong in Dovecot. Anyway, I was not proposing the patch to be included, just asking for advice as to whether it would be safe. I even noted that it was ugly. As I am already compiling Dovecot myself, I prefer a patch there, rather than diverting from the distribution kernel. Cheers, Anders.
Re: [Dovecot] Time moved backwards by 4398 seconds
On Fri, 2008-06-20 at 10:53 +0200, Anders wrote: > Dovecot (v1.1.rc8) died tonight, with an error about time moving > backwards by 4398 seconds. I can see from logs that this has happend a > few times before with the imap processes, without me noticing. I sure > noticed the master process missing, though :-). > > I was puzzled that it was always 4398 seconds, in particular because > this server runs an NTP daemon. A little searching for this problem > shows that it is an issue with the Linux kernel gettimeofday(), see > e.g. http://lkml.org/lkml/2007/8/23/96 The thread puts it down to buggy hardware and puts a workaround into the kernel where it belongs, not in dovecot. johannes signature.asc Description: This is a digitally signed message part
Re: [Dovecot] While searching: Assertion failed (offset > = ctx- >input->v_offset)
On Friday 20 June 2008, Timo Sirainen wrote: > On Fri, 2008-06-20 at 09:42 +0200, Diego Liziero wrote: > > > > Timo, > > here is an anonymized mbox file that causes it at every body search > > (tested with rc12). > > Did you test it without index files? I couldn't reproduce the crash. Deleting index files solved the crash. I sent broken index files privately to Timo. Diego.
Re: [Dovecot] sig11 in 1.1rc5 fts
On Thu, 2008-06-19 at 17:14 -0400, Adam McDougall wrote: > This happened from one user near noon on the 17th and 19th (today) of > this month. From the backtrace it looks like they were searching, but I > won't know for sure unless I need to ask them. Is this possibly fixed > already? I just haven't upgraded dovecot in a while due to lack of > problems. The sig11 happened a few dozen times, a few seconds apart > each day. I have one coredump from each day, and the size was the > same. This is a trace from only one. The other backtrace looks pretty > much the same. > > Version: 1.1rc5 > OS: FreeBSD 7.0-STABLE > > > #0 0x4101bf11 in node_read_children (trie=0x40c5a800, > node=0x40c5a800, level=1) at squat-trie.c:461 I think this will help: http://hg.dovecot.org/dovecot-1.1/rev/2c279e5e1cb9 signature.asc Description: This is a digitally signed message part
[Dovecot] Time moved backwards by 4398 seconds
Dovecot (v1.1.rc8) died tonight, with an error about time moving
backwards by 4398 seconds. I can see from logs that this has happend a
few times before with the imap processes, without me noticing. I sure
noticed the master process missing, though :-).
I was puzzled that it was always 4398 seconds, in particular because
this server runs an NTP daemon. A little searching for this problem
shows that it is an issue with the Linux kernel gettimeofday(), see
e.g. http://lkml.org/lkml/2007/8/23/96
Below is a patch (untested) to work around this issue. Do you see
something wrong with this approach, apart from the uglyness?
I just picked the 4395-4400 values by chance. Can you figure out how
big the window should be?
Thanks,
Anders.
--- ./src/lib/ioloop.c-orig 2008-06-20 10:45:54.0 +0200
+++ ./src/lib/ioloop.c 2008-06-20 10:47:36.0 +0200
@@ -230,8 +230,13 @@
struct timeval tv, tv_call;
unsigned int t_id;
- if (gettimeofday(&ioloop_timeval, &ioloop_timezone) < 0)
- i_fatal("gettimeofday(): %m");
+ /* The Linux gettimeofday() will sometimes jump forward
+* by approximately 4398 seconds. Ignore that reading. */
+ do {
+ if (gettimeofday(&ioloop_timeval, &ioloop_timezone) < 0)
+ i_fatal("gettimeofday(): %m");
+ } while (4395 < (ioloop_timeval.tv_sec - ioloop_time)
+&& (ioloop_timeval.tv_sec - ioloop_time) < 4400);
/* Don't bother comparing usecs. */
if (ioloop_time > ioloop_timeval.tv_sec) {
Re: [Dovecot] While searching: Assertion failed (offset > = ctx- >input->v_offset)
On Fri, 2008-06-20 at 11:23 +0300, Timo Sirainen wrote: > On Fri, 2008-06-20 at 16:21 +0800, Patrick Nagel wrote: > > On Friday 20 June 2008, Timo Sirainen wrote: > > > > > Now I get this with 1.1.rc10: > > > > > > > > > > Jun 20 11:53:53 stshamail1 dovecot: Panic: IMAP(username): file > > > > > message-parser.c: line 770 (message_parser_parse_next_block): > > > > > assertion failed: (ctx->input->eof || ctx->input->closed || > > > > > ctx->input->stream_errno != 0) [..] Fixed the assert-crash: http://hg.dovecot.org/dovecot-1.1/rev/ca97501642c5 It now reports "Broken MIME parts for mail" errors instead. At least in Diego's case it was clearly caused by the broken v1.1.rc8 release which added empty lines to headers and caused the MIME structures to be cached wrong. I don't know about Patrick though. Hopefully also caused by a bug that was fixed in newer versions. :) signature.asc Description: This is a digitally signed message part
Re: [Dovecot] While searching: Assertion failed (offset > = ctx- >input->v_offset)
On Fri, 2008-06-20 at 16:21 +0800, Patrick Nagel wrote: > On Friday 20 June 2008, Timo Sirainen wrote: > > > > Now I get this with 1.1.rc10: > > > > > > > > Jun 20 11:53:53 stshamail1 dovecot: Panic: IMAP(username): file > > > > message-parser.c: line 770 (message_parser_parse_next_block): > > > > assertion failed: (ctx->input->eof || ctx->input->closed || > > > > ctx->input->stream_errno != 0) [..] > > > > > > > > Patrick. > > > > > > Timo, > > > here is an anonymized mbox file that causes it at every body search > > > (tested with rc12). > > > > Did you test it without index files? I couldn't reproduce the crash. Do > > you use 32bit or 64bit Dovecot? > > For me it's the 32bit version (atrpms.net RPM package). > > Do you mean I should try again after deleting the index files? I mostly meant it for Diego since he's able to reproduce it but I'm not. But do you mean you can also reproduce it? If so, sure, try if deleting index helps. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] v1.1.rc12 released
On Thu, 2008-06-19 at 22:01 -0700, Woonsan Ko wrote: > Hi Timo, > > I finally succeeded in compiling dovecot-1.1.rc12 on AIX with the following > patch: > > http://users.handysoft.co.kr/~wsko/resource/aix.diff > + -e 's/\"\/usr\/include\/rpcsvc\/rquota\.h\"/\"rquota.h\"/' \ I don't think I want to include this. If rpcgen generates this wrong, it sounds more like a problem with the rpcgen itself. This kind of a include might be correct on another system.. > + echo "#include " > rquota.h I could add this, but since it might break another system I'll wait until after v1.1.0 release for this change. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] While searching: Assertion failed (offset > = ctx- >input->v_offset)
On Friday 20 June 2008, Timo Sirainen wrote: > > > Now I get this with 1.1.rc10: > > > > > > Jun 20 11:53:53 stshamail1 dovecot: Panic: IMAP(username): file > > > message-parser.c: line 770 (message_parser_parse_next_block): > > > assertion failed: (ctx->input->eof || ctx->input->closed || > > > ctx->input->stream_errno != 0) [..] > > > > > > Patrick. > > > > Timo, > > here is an anonymized mbox file that causes it at every body search > > (tested with rc12). > > Did you test it without index files? I couldn't reproduce the crash. Do > you use 32bit or 64bit Dovecot? For me it's the 32bit version (atrpms.net RPM package). Do you mean I should try again after deleting the index files? 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: https://stshacom1.star-china.net/keys/patrick_nagel.asc Fingerprint: E09A D65E 855F B334 E5C3 5386 EF23 20FC E883 A005 signature.asc Description: This is a digitally signed message part.
Re: [Dovecot] While searching: Assertion failed (offset > = ctx- >input->v_offset)
On Fri, 2008-06-20 at 09:42 +0200, Diego Liziero wrote: > On 6/20/08, Patrick Nagel <[EMAIL PROTECTED]> wrote: > > Hi, > > [..] > > > > Now I get this with 1.1.rc10: > > > > Jun 20 11:53:53 stshamail1 dovecot: Panic: IMAP(username): file > > message-parser.c: line 770 (message_parser_parse_next_block): assertion > > failed: (ctx->input->eof || ctx->input->closed || ctx->input->stream_errno > > != 0) > > [..] > > > > Patrick. > > Timo, > here is an anonymized mbox file that causes it at every body search > (tested with rc12). Did you test it without index files? I couldn't reproduce the crash. Do you use 32bit or 64bit Dovecot? signature.asc Description: This is a digitally signed message part
