Re: [Dovecot] Vacation?
Charles Marcus wrote: http://wiki.dovecot.org/LDA/Sieve Oh, im prey what someone update a FreeBSD port of it. :-( -- Best Regards, Proskurin Kirill
Re: [Dovecot] Vacation?
Hi, On Tue, Jul 1, 2008 at 8:25 AM, Proskurin Kirill [EMAIL PROTECTED] wrote: Charles Marcus wrote: http://wiki.dovecot.org/LDA/Sieve Oh, im prey what someone update a FreeBSD port of it. :-( Geoffroy Desvernay on Thu, Jun 26, 2008 at 12:05 PM wrote: updated freebsd ports for dovecot, sieve plugin and managesieve here: http://dgeo.perso.ec-marseille.fr/dovecot Not very well tested, but 'it works for us'™ regards, p.
[Dovecot] Server power loss and Dovecot is already running with PID xxx
Hi, I'm running Dovecot 1.0.7 (with various patches) on CentOS 5.2. The server has suffered a couple of power loss events. Dovecot is run as a standalone server. The problem is that dovecot refuses to start up at boot because the PID file from before the power loss is left behind. The message is as follows: $ /sbin/service dovecot start Starting Dovecot Imap: Error: Dovecot is already running with PID 10825 (read from /var/run/dovecot/master.pid) Fatal: Invalid configuration in /etc/dovecot.conf [FAILED] (Note: there is nothing wrong in the configuration file so the error message is somewhat misleading.) I looked at the release notes of 1.0.xx releases and they didn't mention this. Is this already a known problem? Should the start-up logic be made more robust (e.g. check whether a process corresponding to the PID actually exists)? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
[Dovecot] sieve doesn't work with 1.1.1
Hello This is my dovecot.conf : /etc/dovecot/dovecot.conf log_path: /var/log/dovecot.log info_log_path: /var/log/dovecot.info protocols: imap imaps managesieve login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(managesieve): /usr/lib/dovecot/managesieve-login mail_location: maildir:/var/spool/imap/%u mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(managesieve): /usr/lib/dovecot/managesieve mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(managesieve): /usr/lib/dovecot/modules/managesieve sieve_storage(default): sieve_storage(imap): sieve_storage(managesieve): ~/sieve sieve(default): sieve(imap): sieve(managesieve): ~/.dovecot.sieve auth default: passdb: driver: pam userdb: driver: passwd socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix I have updated from 1.0.15 to 1.1.1 because it was necessity to change the sieve path. Furthermore i needed the managesieve. If i create a file named .dovecot.sieve in the home directory the file will be ignored. But in the 1.0.15 version with the cmusieve plugin it worked I would be thankful for your help Kind regards Benjamin Andreas
Re: [Dovecot] Server power loss and Dovecot is already running with PID xxx
On Tue, 2008-07-01 at 00:14 +0300, Pekka Savola wrote: $ /sbin/service dovecot start Starting Dovecot Imap: Error: Dovecot is already running with PID 10825 (read from /var/run/dovecot/master.pid) Fatal: Invalid configuration in /etc/dovecot.conf [FAILED] (Note: there is nothing wrong in the configuration file so the error message is somewhat misleading.) Yes, it's a bit misleading. But I don't think I'll bother fixing it before rewriting the master/config handling for v2.0. Is this already a known problem? Should the start-up logic be made more robust (e.g. check whether a process corresponding to the PID actually exists)? It already checks if the PID exists, but it doesn't check what that process is (and I don't think there is a portable way to do it anyway). I don't think it's too much to ask to delete the master.pid if in rare situations it fails to start due to a PID conflict. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] sieve doesn't work with 1.1.1
Benjamin Andreas schreef: Hello This is my dovecot.conf snip I have updated from 1.0.15 to 1.1.1 because it was necessity to change the sieve path. Furthermore i needed the managesieve. If i create a file named .dovecot.sieve in the home directory the file will be ignored. But in the 1.0.15 version with the cmusieve plugin it worked I am assuming that you have problems upon delivery. To see what the deliver and the sieve plugin are doing it is best to turn on mail_debug in your config file and see what deliver is logging when it tries to deliver a message. Something similar holds for managesieve, that also writes verbose data to your log (probably syslog) when mail_debug is set. In either case you should find the cause of your problem in the logs. Regards, -- Stephan Bosch [EMAIL PROTECTED]
Re: [Dovecot] can't download attachment from the wiki
Hi Andrew and Dimitrij, The following discussion took place on the Dovecot mailinglist. Dimitrij recently had a similar problem which I 'solved' by pointing him to the broken url. Andrew Schulman schreef: Hi. At http://wiki.dovecot.org/ManageSieve#line-229 , I want to download the patch that's supposed to fix two problems in Avelsieve. Unfortunately, when I click on the link to the patch, I always get an error message: You are not allowed to do AttachFile on this page. Ouch, sorry, I advised Timo to disable AttachFile because somebody was using the dovecot wiki to distribute some key files for something that had nothing to do with dovecot. Johannes, thanks. While we're waiting for that to get sorted out, could someone be so kind as to email me the patch? Thanks, Andrew. Ok, that is not practical. I've recovered it from my mail discussion with Hanspeter Kunz who provided the definitive version of this patch. I've put it online here: http://www.rename-it.nl/dovecot/client-patches/avelsieve-1.9.7-dovecot.diff I hope this resolves Adrew's and Dimitrij's problems. Regards, -- Stephan Bosch [EMAIL PROTECTED]
[Dovecot] [Fwd: Re: University of Washington lays off 66 technology workers.]
I would expect this means the end of UWIMAPwhich probably leaves DC as open-source IMAP of choice. There were 66 people doing IMAP and Pine/Alpine development that were laid off at UWash due to funding cuts; Mark Crispin, one of the fathers of IMAP, was among those laid off. From the keyboard of: James Morris Lead Engineer, UW Technology University of Washington = Here's the official text on the status of Alpine and UW imapd development for those that were asking: --- Here is what we know about our future plans for development of Alpine and UW IMAPd products. We are committed to completing our work on a new Web Alpine user interface and a corresponding release of Alpine and UW IMAPd. After this next release, which is anticipated later this summer, we'll continue assessing any future development plans and resources we can allocate to this effort. Thanks. == -- Stewart Dean, Unix System Admin, Henderson Computer Resources Center of Bard College, Annandale-on-Hudson, New York 12504 [EMAIL PROTECTED] voice: 845-758-7475, fax: 845-758-7035
Re: [Dovecot] Errors running imaptest with dovecot-1.1.1
On Tue, 2008-07-01 at 13:22 +0200, Joseba Torre wrote: Then I've created 100 new users imaptest001-imaptest100, and set the password paquitoelchocolatero to all of them. Then I run: imaptest user=imaptest%03d pass=paquitoelchocolatero mbox=dovecot.mbox clients=50 secs=10 logout=0 seed=123 2 errores The output is normal (still haven't began with the benchmark), but the errores file -attached- is filled with lines like this: Error: UIVALIDITY changed: 1214910049 - 1214910037 Error: imaptest071[19]: UID=8 INTERNALDATE changed 1214910065+120 - 1214910042+120: * 1 FETCH (INTERNALDATE ... These are actually all normal. I just haven't bothered to fix imaptest to treat different users' mailboxes as actual separate mailboxes. Since it assumes all the mailboxes are the one and same, it sees a lot of problems because they aren't. The multiuser support was written long before I added these checks and I haven't needed the multiuser testing myself for a long time, so this is broken for now. Feel free to fix it. :) Also have you seen http://imapwiki.org/Benchmarking? imaptest tests best the webmail kind of a performance but not that much of Outlook/Thunderbird performance. signature.asc Description: This is a digitally signed message part
[Dovecot] Users can't delete an email (Totally Random effect)
Hello all... Found a weird one here. I tried to search the web but I'm not having luck so I thought I'd hit the mailing list. We have noticed off and on all school year that every so often a user gets an email that they just can't delete using Thunderbird or Outlook over IMAP (we do not support Pop3 anymore.) Essentially the user clicks the email and takes it to the trash. When they empty the trash the email appears again in their inbox as if it was new! Up until this point I would just tell people to login to Usermin which is still set to access the email natively through the maildir format and delete it that way. What we have found out is that emails which have their info fields repeated twice are emails which can't be deleted. So for example: [EMAIL PROTECTED]:/home/somedude# find ./ -iname '*,*,*' ./Maildir/cur/1208807796.29873_0.gator:2,Sb:2,S ./Maildir/cur/1205162628.14926_0.gator:2,Sb:2,S ./Maildir/cur/1206557108.6542_0.gator:2,Sb:2,STb ./Maildir/cur/1204054624.5835_0.gator:2,Sa:2,S ./Maildir/cur/1208957483.28799_0.gator:2,RSb:2,RSTb ./Maildir/cur/1208803572.18922_0.gator:2,Sb:2,S ./Maildir/cur/1209482166.31816_0.gator:2,Sb:2,S ./Maildir/cur/1212778554.27192_0.gator:2,Sa:2,S ./Maildir/cur/1210613916.23757_0.gator:2,Sb:2,S ./Maildir/cur/1210277191.15311_0.gator:2,Sa:2,S ./Maildir/cur/1204813078.31520_0.gator:2,Sa:2,S ./Maildir/cur/1207318169.27142_0.gator:2,Sb:2,STb ./Maildir/cur/1206732320.12478_0.gator:2,RSb:2,RSTb ./Maildir/cur/1210788980.15319_0.gator:2,RSb:2,S ./Maildir/cur/1205432415.9316_0.gator:2,RSb:2,S ./Maildir/cur/1204135464.22085_0.gator:2,Sb:2,S ./Maildir/cur/1207161276.31798_0.gator:2,Sb:2,S ./Maildir/cur/1203969436.24684_0.gator:2,Sa:2,S ./Maildir/cur/1207753826.6079_0.gator:2,Sa:2,RSa ./Maildir/cur/1207832151.6749_0.gator:2,Sb:2,S ./Maildir/cur/1212082057.25882_0.gator:2,Sa:2,S ./Maildir/cur/1205856514.5523_0.gator:2,Sb:2,S ./Maildir/cur/1207072150.20246_0.gator:2,RSab:2,S ./Maildir/cur/1208800746.30992_0.gator:2,Sb:2,S ./Maildir/cur/1205353851.26747_0.gator:2,Sb:2,S All of these emails will not be deletable by the imap client. They will do the thing I described above. If I remove one of the info fields they can be deleted. We also found if we create a fake email and name it test:2,ae:2,Sae it too will have the nondelete problem. Unfortunately I don't know how or why these emails are created. As far as the vitals go: We are running Dovecot 1.0.14 now, but I have been able to observe this problem through a few of the last versions. The server runs Slamd 64 10.2 (Opteron 64 CPUs) and all of the home directories are on a ReiserFS formatted Volume Anything else I can tell you please let me know and of course any info anybody can tell me about how to make this weirdness go away would be greatly appreciated. Thanks. -- -Jesse C. Smillie Insert inspirational or witty comment here begin:vcard fn:Jesse C. Smillie n:Smillie;Jesse C. org:Gateway School District;Technology Department adr:;;;Monroeville;PA;15146;USA email;internet:[EMAIL PROTECTED] title:Mac Tech / Linux Administrator / Mac Administrator tel;work:412-858-0453 tel;cell:412-861-3423 x-mozilla-html:TRUE version:2.1 end:vcard
[Dovecot] ManageSieve v0.10.3 released for Dovecot 1.1.1
Hello Dovecot users, I have formulated a new release that addresses an important ManageSieve compilation issue that arises when compiling with GCC 4.3 (as used by the new Debian Lenny). Change Log v0.10.3 --- * Removed erroneous inline declarations that caused compiler warnings. GCC 4.3 turns out to fail entirely as reported by Joel Johnson. * Fixed auto-detection of Sieve implementation during ./configure. It now produces a proper error when the directory is invalid. Installation The full installation procedure and other relevant information regarding ManageSieve is available on the Dovecot wiki at: http://wiki.dovecot.org/ManageSieve New release: http://www.rename-it.nl/dovecot/1.1/dovecot-1.1-managesieve-0.10.3.tar.gz http://www.rename-it.nl/dovecot/1.1/dovecot-1.1-managesieve-0.10.3.tar.gz.sig To avoid confusion, I have refreshed the patch as well: http://www.rename-it.nl/dovecot/1.1/dovecot-1.1.1-managesieve-0.10.3.diff.gz http://www.rename-it.nl/dovecot/1.1/dovecot-1.1.1-managesieve-0.10.3.diff.gz.sig My public key (id: 3DFBB4F4) can be found at wwwkeys.pgp.net. Don't hesitate to notify me when there are problems. Regards, -- Stephan Bosch [EMAIL PROTECTED] IRC: Freenode, #dovecot, S[r]us
Re: [Dovecot] ManageSieve v0.10.3 released for Dovecot 1.1.1
Stephan Bosch wrote: Hello Dovecot users, I have formulated a new release that addresses an important ManageSieve compilation issue that arises when compiling with GCC 4.3 (as used by the new Debian Lenny). Sorry for being slightly off-topic - but if you change your code to be compliant with GCC-4.3, would it still compile under older versions? -- Daniel
[Dovecot] FETCH for mailbox got too little data
Using 1.1.1. Got this error message in a tight loop, using both Tbird and Mulberry 3 as client: FETCH for mailbox INBOX UID 32994 got too little data: 1616 vs 1649 I get this repeatedly alternating with a login line. What does this mean? I stopped the server, zipped ~/mail/.imap/INBOX to hide it and let dovecot recreate it, and things seem to be working again. Is there a less destructive way to fix this in the future? Delivery is by procmail.
Re: [Dovecot] FETCH for mailbox got too little data
On Tue, 2008-07-01 at 12:39 -0700, Kenneth Porter wrote: Using 1.1.1. Got this error message in a tight loop, using both Tbird and Mulberry 3 as client: FETCH for mailbox INBOX UID 32994 got too little data: 1616 vs 1649 I get this repeatedly alternating with a login line. What does this mean? I stopped the server, zipped ~/mail/.imap/INBOX to hide it and let dovecot recreate it, and things seem to be working again. Is there a less destructive way to fix this in the future? Delete dovecot.index.cache file. Although I thought v1.1 did this automatically. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Maildir and Invalid data in file
On Wed, 2008-06-25 at 10:08 +0200, Patryk wrote:
I'm using dovecot version 1.0.13 on reiserfs on hardware RAID-0, but I'm
getting the
following error in the logs every time one user tries to access his old mails
in the .Sent
directory:
dovecot: 2008-06-23 15:09:46 Error: IMAP(marek.chajecki): Invalid data in file
/var/mail/Maildir/marek.chajecki/.Sent/dovecot-uidlist
I think I already asked about this, but the files really look like they
contain LF characters in them for some reason.
Try applying the attached patch. Does it start complaining about LFs?
diff -r 52f1d54d37cf src/lib-storage/index/maildir/maildir-uidlist.c
--- a/src/lib-storage/index/maildir/maildir-uidlist.c Sat Jun 21 16:23:40 2008 +0300
+++ b/src/lib-storage/index/maildir/maildir-uidlist.c Tue Jul 01 23:01:01 2008 +0300
@@ -914,9 +914,18 @@
{
struct maildir_uidlist *uidlist = ctx-uidlist;
struct maildir_uidlist_rec *rec, *old_rec;
+ const char *p;
if (ctx-failed)
return -1;
+
+ for (p = filename; *p != '\0'; p++) {
+ if (*p == 13 || *p == 10) {
+ i_warning(Maildir %s: Ignoring a file with LF: %s,
+ uidlist-mbox-path, filename);
+ return 1;
+ }
+ }
if (ctx-partial)
return maildir_uidlist_sync_next_partial(ctx, filename, flags);
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] 1.1 namespaces and message corruption
On Fri, 2008-06-27 at 14:48 -0500, Kyle Wheeler wrote: Hello, I've been trying out the new dovecot's namespace support, and I'm having some issues moving messages between namespaces. Specifically, when I move some messages from a Maildir-based namespace to an mbox-based namespace, the message gets corrupted: its contents are removed, and an entirely empty message is added to the destination mailbox. This is 100% repeatable (some messages just *cannot* be copied intact). zlib plugin is somehow broken. If it's loaded then non-hardlink copying from a maildir results in zero byte output. I'll look at it later - it's not obvious why it's broken. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Poor pop3 over nfs performance
On Mon, 2008-06-30 at 17:05 +0100, Mark Zealey wrote: Hi, About a week ago I upgraded our reasonably heavily loaded mail servers from a pretty recent courier version to dovecot-1.1rc10. rc11 had this fix which may be relevant: - dovecot-uidlist is now recreated if it results in file shrinking over 25%. IMAP performance on dovecot is amazing, however POP3 performance is worse than courier :-( I have uploaded some munin graphs taken today to http://linweb.atlas.pipex.net/dovecot/; the dovecot server is handling about 2000 pop logins/sec and 300 imap sessions (but these are negligible in terms of nfs ops). The courier server is handling a similar number of pop logins/sec but no imap (slightly less traffic overall but a similar number of logins). As you can see, dovecot seems to issue an awful lot more read requests than courier. Dovecot's POP3 performance isn't that great, but it shouldn't be (much) worse than Courier's since they both use a nearly identical dovecot-uidlist/courierpop3dsizes files. The big spike at 10am is where I tried setting the :INDEX=MEMORY flag on dovecot as I assumed that's what courier is doing. With v1.1 INDEX=MEMORY shouldn't matter that much anymore, since it should cache the virtual message size to dovecot-uidlist. 1) Do you have ,W=size in maildir filenames? Apparently not? 2) Do you have W=size added to dovecot-uidlist? 3) Are your POP3 users download + delete or do they leave mail on the server? The servers are both centos 5.0 (perhaps 5.1 actually, but with the latest centosplus kernel which fixes the nfs lookup bug in the standard kernels); and are not running any other nfs programs. The NFS server is a high performance NAS unit - no issues there. We're only using Maildirs; relevant config options are: mmap_disable: yes dotlock_use_excl: no You should be able to use dotlock_use_excl=yes. mail_nfs_storage: yes mail_nfs_index: yes lock_method: dotlock dotlock is the slowest locking method. Did you try how well fcntl would have worked? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] FETCH for mailbox got too little data
--On Tuesday, July 01, 2008 10:51 PM +0300 Timo Sirainen [EMAIL PROTECTED] wrote: Delete dovecot.index.cache file. Although I thought v1.1 did this automatically. Is this file obsolete? Should I remove it for all folders, or just ones that exhibit a problem? (I see many of them in the folder hierarchy.)
Re: [Dovecot] courier IMAP to dovecot migration: folders not showing up
I guess you didn't configure INBOX. namespace prefix to Dovecot, but your client configuration still has it. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Users can't delete an email (Totally Random effect)
On Tue, 2008-07-01 at 15:07 -0400, Jesse C. Smillie wrote: Hello all... Found a weird one here. I tried to search the web but I'm not having luck so I thought I'd hit the mailing list. We have noticed off and on all school year that every so often a user gets an email that they just can't delete using Thunderbird or Outlook over IMAP (we do not support Pop3 anymore.) Essentially the user clicks the email and takes it to the trash. When they empty the trash the email appears again in their inbox as if it was new! Up until this point I would just tell people to login to Usermin which is still set to access the email natively through the maildir format and delete it that way. What we have found out is that emails which have their info fields repeated twice are emails which can't be deleted. So for example: [EMAIL PROTECTED]:/home/somedude# find ./ -iname '*,*,*' ./Maildir/cur/1208807796.29873_0.gator:2,Sb:2,S http://hg.dovecot.org/dovecot-1.0/rev/39bb56f31185 fixes this. Unfortunately I don't know how or why these emails are created. Maybe Usermin creates them? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] FETCH for mailbox got too little data
On Tue, 2008-07-01 at 13:25 -0700, Kenneth Porter wrote: --On Tuesday, July 01, 2008 10:51 PM +0300 Timo Sirainen [EMAIL PROTECTED] wrote: Delete dovecot.index.cache file. Although I thought v1.1 did this automatically. Is this file obsolete? Should I remove it for all folders, or just ones that exhibit a problem? (I see many of them in the folder hierarchy.) It contains cached data which speeds up Dovecot's replies to clients. So delete them only if you see problems for a specific mailbox. They're recreated the next time user opens the mailbox. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Users can't delete an email (Totally Random effect)
On Tue, 2008-07-01 at 16:40 -0400, Jesse C. Smillie wrote: Will definitely look into the usermin connection. Not to be totally stupid, but I clicked the link you listed. Does that mean next 1.0 release there will a fix to at least work out the whole can't delete thing? Well, I don't know if there will be any v1.0 releases anymore, but if there are it's going to have it. But you can yourself use it to patch the latest sources (clicking on the raw link you'll get a usable patch). signature.asc Description: This is a digitally signed message part
[Dovecot] select NULL as password... failing after upgrade to dovecot-1.1
Hi,
I've upgraded mail server to dovecot-1.1, on solaris-10 with mysql user
database.
I used sql query
SELECT NULL as password, login as user,
concat('/mail/var/dovecot/',login) AS userdb_home, 501 AS userdb_uid,
501 AS userdb_gid FROM users WHERE login='%n' AND
password=old_password('%w') with dovecot-1.0.15 and it worked perfectly.
But since upgrade the server can not authenticate any users, complaining
in info_log: Empty password returned without no_password.
How to set up such things in dovecot-1.1? Is it possible?
--
Sergey Ivanov.
Re: [Dovecot] select NULL as password... failing after upgrade to dovecot-1.1
On Jul 2, 2008, at 12:26 AM, Sergey Ivanov wrote:
Hi,
I've upgraded mail server to dovecot-1.1, on solaris-10 with mysql
user database.
I used sql query
SELECT NULL as password, login as user, concat('/mail/var/
dovecot/',login) AS userdb_home, 501 AS userdb_uid, 501 AS
userdb_gid FROM users WHERE login='%n' AND
password=old_password('%w') with dovecot-1.0.15 and it worked
perfectly.
But since upgrade the server can not authenticate any users,
complaining in info_log: Empty password returned without
no_password.
How to set up such things in dovecot-1.1? Is it possible?
Like it says, return no_password field also. For example:
select 'Y' as no_password, ...
PGP.sig
Description: This is a digitally signed message part
Re: [Dovecot] select NULL as password... failing after upgrade to dovecot-1.1
Timo Sirainen wrote:
On Jul 2, 2008, at 12:26 AM, Sergey Ivanov wrote:
Hi,
I've upgraded mail server to dovecot-1.1, on solaris-10 with mysql
user database.
I used sql query
SELECT NULL as password, login as user,
concat('/mail/var/dovecot/',login) AS userdb_home, 501 AS userdb_uid,
501 AS userdb_gid FROM users WHERE login='%n' AND
password=old_password('%w') with dovecot-1.0.15 and it worked
perfectly.
But since upgrade the server can not authenticate any users,
complaining in info_log: Empty password returned without no_password.
How to set up such things in dovecot-1.1? Is it possible?
Like it says, return no_password field also. For example:
select 'Y' as no_password, ...
Thank you, Timo, it worked but without underscore, that is, select 'Y'
as nopassword
But after that I have another problem:
---
dovecot: Jul 01 17:38:50 Error: IMAP(seriv): Corrupted transaction log
file /mail/var/dovecot/seriv/.Trash/dovecot.index.log: hdr.size too
large (67108864)
dovecot: Jul 01 17:38:50 Warning: IMAP(seriv): fscking index file
/mail/var/dovecot/seriv/.Trash/dovecot.index
dovecot: Jul 01 17:38:52 Error: child 29586 (imap) killed with signal 11
...
---
(imap child killed many many times).
I stopped dovecot, deleted dovecot.index files, and this problem was
gone. But tags also were gone. Is there a way to upgrade preserving tags
and other flags?
--
WBR,
Sergey Ivanov.
Re: [Dovecot] FETCH for mailbox got too little data
--On Tuesday, July 01, 2008 11:36 PM +0300 Timo Sirainen [EMAIL PROTECTED] wrote: It contains cached data which speeds up Dovecot's replies to clients. So delete them only if you see problems for a specific mailbox. They're recreated the next time user opens the mailbox. After the error message is logged, the code in imap_fetch_send() invokes this: mail_set_cache_corrupted(ctx-mail, ctx-cur_size_field); What uses that? Is that supposed to ultimately prevent the retry from using the cache file? It seems like that mechanism isn't working, as the client was getting into a loop.
Re: [Dovecot] ManageSieve v0.10.3 released for Dovecot 1.1.1
Daniel L. Miller schreef: Stephan Bosch wrote: Hello Dovecot users, I have formulated a new release that addresses an important ManageSieve compilation issue that arises when compiling with GCC 4.3 (as used by the new Debian Lenny). Sorry for being slightly off-topic - but if you change your code to be compliant with GCC-4.3, would it still compile under older versions? Yes, this problem only resulted from using the concept of inline functions in a way that is not appropriate (but that was handled gracefully in older versions of GCC). Starting with GCC 4.2, this resulted in a series of warnings which I fixed for the new Sieve implementation, but I forgot to fix those for managesieve. Obviously, GCC 4.3 is more strict in this regard, making compilation fail entirely. So, fixing this problem does not affect older versions of GCC. Regards, -- Stephan Bosch [EMAIL PROTECTED]
Re: [Dovecot] Server power loss and Dovecot is already running with PID xxx
On Jul 1, 2008, at 12:51 AM, Timo Sirainen wrote: Is this already a known problem? Should the start-up logic be made more robust (e.g. check whether a process corresponding to the PID actually exists)? It already checks if the PID exists, but it doesn't check what that process is (and I don't think there is a portable way to do it anyway). I don't think it's too much to ask to delete the master.pid if in rare situations it fails to start due to a PID conflict. This is a pet peeve of mine for many services started at boot time. Since the ordering of service startup is usually fairly static, a *LOT* of times process IDs are nearly identical on boot. Depending on which way they go, if they drift towards earlier, you'll have the PID in use. This drove me NUTS with Sun's LDAP server. Many recent OSes are now using memory-based filesystems for /var/run, or otherwise clear out /var/run at boot time. But if a process stores its PID somewhere else, you're SOL (much like Sun One Directory Server does). The problem with having to remove a master.pid file on boot is that you might have a BUNCH of clients or customers that are using your system, and you're either asleep at 3am when the server kicked over, or in another state. It's not a problem if you have staff watching machines reboot. ;-) Sorry, had to kibitz. Sean PS I often times add a 'rm $PID' line in the init.d script, and let a server die because it couldn't bind to the port. That doesn't work with everything, though.
