Re: [Dovecot] dsync mbox-mdbox II: highest_modseq changed
Hi, On Thu, 2010-11-18 at 17:34 +, Timo Sirainen wrote: On Thu, 2010-11-18 at 18:57 +0200, Axel Thimm wrote: dsync(athimm): Info: old/speicher: highest_modseq changed: 1 != 10 dsync(athimm): Info: root/root-heretic: highest_modseq changed: 1 != 10 dsync(athimm): Info: lists/ccrma.stanford.edu/planetccrma: highest_modseq changed: 11 != 14 These don't really matter. It just couldn't sync the modseqs correctly. I should try to fix those somehow some day, but I think the problem here is that mbox code can't handle this correctly. It should have increased the modseqs to 10, 10, 14 but apparently it didn't. Shouldn't it be the other way? mbox was the source, so its modseq should had been considered authoritative, or not? One would expect that after applying the (same) changes to mdbox that the modseq should converge to be the same. I'm just trying to understand whether the bug may be in the mdbox part of the code. On another note I now switched to mdbox with bzip compressed storage and everything seems nice and smooth. The server has a much lower load when I connect and even the client I'm using (evolution) which would previously crash due to timeouts is now working much better (though still crashing, but that's not really related to dovecot). The storage requirements have more than halved (15GB vs 34GB) and are much easier to rsync/backup. I love mdbox. :) -- http://thimm.gr/ - http://ATrpms.net/ signature.asc Description: This is a digitally signed message part
[Dovecot] Workaround for evolution?
Hi, evolution has a bug when it comes to closing and IDLE' connection: https://bugzilla.gnome.org/show_bug.cgi?id=628515 evolution does not send a DONE command, and dovecot properly answers with an error. evolution ignores this and seems to wait on another response. Timo, do you think there could be a setting for tolerating missing DONEs? Thanks! -- http://thimm.gr/ - http://ATrpms.net/ signature.asc Description: This is a digitally signed message part
[Dovecot] dsync mbox-mdbox II: highest_modseq changed
Hi again, after replacing CRLF in 4 mboxes dsync was able to sync all of the 30+GB mailstore to mdbox. Now the (repeated) calling of dsync yields info messages of the kind dsync(athimm): Info: old/speicher: highest_modseq changed: 1 != 10 dsync(athimm): Info: root/root-heretic: highest_modseq changed: 1 != 10 dsync(athimm): Info: lists/ccrma.stanford.edu/planetccrma: highest_modseq changed: 11 != 14 I actually have 987 such messages for a total of 1115 mboxes. I checked a couple of them to see whether this is a CRLF issue and found no CRLF, so it's probably something different. As long as the mboxes were still being delivered to or read from I thought it was normal, but I'd like to see a silent dsync which would give me more confidence in the migration process. So I kept from delivering to the mbox store as well as reading from it and performed multiple dsyncs. The output of dsync became stable, e.g. the highest_modseq changed messages were exactly the same. Before nuking all indexes from the mbox storage and the mdbox itself and then repeating the whole process (which does take a long time), I wanted to know whether I should debug something. Thanks! -- http://thimm.gr/ - http://ATrpms.net/ signature.asc Description: This is a digitally signed message part
Re: [Dovecot] dsync mbox-mdbox: Unexpectedly lost From-line and other issues from a big conversion.
On Mon, 2010-11-15 at 18:32 +, Timo Sirainen wrote: On 15.11.2010, at 18.15, Axel Thimm wrote: dsync2.log.old1:dsync(user): Error: Next message unexpectedly lost from mbox file /home/user/mail/lists/mplayerhq.hu/ffmpeg-devel at 58706201 (cached) dsync2.log.old1:dsync(user): Error: Next message unexpectedly lost from mbox file /home/user/mail/lists/gnupg.org/gnupg-users at 6507197 (cached) Looks like public mailing list archives. Could you put the mbox file(s) somewhere I can download them? Maybe I can easily reproduce the problem. I sent you the URL in PM. I checked the files and the mentioned offsets are one line off the next from_ line. It looks like a content-length mismatch. They also seem to mix CR+LF and simple LF endings within the same mail. For example an otherwise CR+LF encoded mail would have a few headers w/o CR at the bottom inserted (by dovecot?). Maybe the content-length computation was therefore a few lines off. I can probably salvage these mboxes by grepping out the content-length header, but I wonder why the content-length header are off. -- http://thimm.gr/ - http://ATrpms.net/ signature.asc Description: This is a digitally signed message part
[Dovecot] dsync mbox-mdbox: Unexpectedly lost From-line and other issues from a big conversion.
Hi, I'm trying to convert a 33GB mail store from mbox to compressed mdbox (largest mbox is 2.7GB). The source store is live, e.g. there are mails delivered into it and mails are being read. Actually it is my own mail. :) Although my test runs were very successful I have run into trouble with the first run on the whole store. After fighting a bit around with errors like Error: Trying to open a non-listed mailbox with guid=f59c5b31b8f3df4c7018e7dd553b I did several reruns in case these errors would be fixed on the next iteration, but my mdbox storage wasn't growing anymore. I decided to restart after removing all old index files from the source store in case I had some corruption somewhere. Since on mbox/maildir index files are completely recreatable this would just slow down thing at the worst. Indeed many of the errors went away, and I managed to convert about 10-20%, but then I hit another array of errors that would persist even after restarting: $ grep -v Info: dsync2.log.old* dsync2.log.old1:dsync(user): Error: Next message unexpectedly lost from mbox file /home/user/mail/lists/mplayerhq.hu/ffmpeg-devel at 58706201 (cached) dsync2.log.old1:dsync(user): Error: read(msg input) failed: Invalid argument dsync2.log.old1:dsync(user): Error: Next message unexpectedly lost from mbox file /home/user/mail/lists/gnupg.org/gnupg-users at 6507197 (cached) dsync2.log.old1:dsync(user): Error: Unexpectedly lost From-line from mbox file /home/user/mail/lists/gnupg.org/gnupg-users at 6486645 dsync2.log.old2:dsync(user): Error: mdbox /home/user/mdbox/mailboxes/lists/mplayerhq.hu/ffmpeg-devel/dbox-Mails: map uid lost for uid 26483 dsync2.log.old2:dsync(user): Error: msg guid lookup failed: Internal error occurred. Refer to server log for more information. [2010-11-15 02:36:21] dsync2.log.old2:dsync(user): Warning: mdbox /home/user/mdbox/storage: rebuilding indexes dsync2.log.old2:dsync(user): Error: Corrupted dbox file /home/user/mdbox/storage/m.1725 (around offset=697710): msg header has bad magic value dsync2.log.old2:dsync(user): Warning: dbox: Copy of the broken file saved to /home/user/mdbox/storage/m.1725.broken dsync2.log.old2:dsync(user): Warning: Transaction log file /home/user/mdbox/storage/dovecot.map.index.log was locked for 295 seconds dsync2.log.old2:dsync(user): Error: Next message unexpectedly lost from mbox file /home/user/mail/lists/mplayerhq.hu/ffmpeg-devel at 58706201 (cached) dsync2.log.old2:dsync(user): Error: read(msg input) failed: Invalid argument dsync2.log.old2:dsync(user): Error: Next message unexpectedly lost from mbox file /home/user/mail/lists/gnupg.org/gnupg-users at 6507197 (cached) dsync2.log.old2:dsync(user): Error: Unexpectedly lost From-line from mbox file /home/user/mail/lists/gnupg.org/gnupg-users at 6486645 dsync2.log.old2:dsync(user): Error: Unexpectedly lost From-line from mbox file /home/user/mail/lists/gnupg.org/gnupg-users at 6507197 dsync2.log.old2:dsync(user): Warning: Mailbox changes caused a desync. You may want to run dsync again. dsync2.log.old3:dsync(user): Error: mdbox /home/user/mdbox/mailboxes/lists/mplayerhq.hu/ffmpeg-devel/dbox-Mails: map uid lost for uid 26484 dsync2.log.old3:dsync(user): Error: msg guid lookup failed: Internal error occurred. Refer to server log for more information. [2010-11-15 09:49:26] dsync2.log.old3:dsync(user): Warning: mdbox /home/user/mdbox/storage: rebuilding indexes dsync2.log.old3:dsync(user): Error: Corrupted dbox file /home/user/mdbox/storage/m.1725 (around offset=758233): msg header has bad magic value dsync2.log.old3:dsync(user): Error: link(/home/user/mdbox/storage/m.1725, /home/user/mdbox/storage/m.1725.broken) failed: File exists dsync2.log.old3:dsync(user): Warning: Transaction log file /home/user/mdbox/storage/dovecot.map.index.log was locked for 271 seconds dsync2.log.old3:dsync(user): Warning: Transaction log file /var/cache/dovecot/indexes/user/lists/lists.fedoraproject.org/.imap/users/dovecot.index.log was locked for 180 seconds dsync2.log.old3:dsync(user): Error: Next message unexpectedly lost from mbox file /home/user/mail/lists/mplayerhq.hu/ffmpeg-devel at 58706201 (cached) dsync2.log.old3:dsync(user): Error: read(msg input) failed: Invalid argument dsync2.log.old3:dsync(user): Error: Next message unexpectedly lost from mbox file /home/user/mail/lists/gnupg.org/gnupg-users at 6507197 (cached) dsync2.log.old3:dsync(user): Error: Unexpectedly lost From-line from mbox file /home/user/mail/lists/gnupg.org/gnupg-users at 6486645 dsync2.log.old3:dsync(user): Error: Unexpectedly lost From-line from mbox file /home/user/mail/lists/gnupg.org/gnupg-users at 6507197 dsync2.log.old3:dsync(user): Warning: Mailbox changes caused a desync. You may want to run dsync again. dsync2.log.old4:dsync(user): Warning: Transaction log file
Re: [Dovecot] Released Pigeonhole v0.2.1 for Dovecot v2.0.4
On Thu, 2010-10-28 at 10:24 +0200, Juan C. Blanco wrote:
On 27/10/2010 20:16, Axel Thimm wrote:
On Mon, 2010-10-04 at 19:05 +0200, Juan C. Blanco wrote:
I've dounloaded the archive for pigeonhole, once decompressed:
If I do:
./configure --with-dovecot=../dovecot-2.0.5
make
All seems to work fine
But if I do (like the atrpms package spec):
autoreconf -ifv
./configure --with-dovecot=../dovecot-2.0.5
make
I get the error:
I checked the pigeonhole specfiles at ATrpms, but could not find any
such call, the %build part has been
%build
## crude hack ...
#./autogen.sh
%configure --with-dovecot=%{_libdir}/dovecot \
--with-managesieve=yes \
--enable-header-install=yes \
INSTALL_DATA=install -c -p -m644
make
for quite some time now.
Thans, I've seen so, but I have a question does not will be necessary to
do it?, the configure was generated by a version of autoconf newer than
the one in CentOS and dows not it may cause problems to use it as is.
It doesn't matter, autotools, the collection of autoconf, automake,
libtool and gettext are only needed when preparing the sources for
shipping, e.g. they are (normally) not needed for builds. Normally means
unless you change any configure.ac, Makefile.am, *.m4 files that these
tools need as an input for generating the build system files.
So you don't need to run autoreconf. But if you do need to run it (which
I also had to yesterday while chasing for a bug), you sometimes need to
nuke away some files, especially if your autotools are older that the
authors', so try
rm -f m4/lt* m4/libtool.m4 build-aux/ltmain.sh
autoreconf -fiv
./configure ...
And that should work on CentOS5. But as said, you don't need it. I added
the two lines above in the latest dovecot-pigeonhole rpm (commented) to
allow future users to easily enable rebuilding of the autotools bit.
Also note that there are fresh rpms for CentOS at ATrpms. :)
--
http://thimm.gr/ - http://ATrpms.net/
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] rpath in pigeonhole (was: dovecot-2.0-pigeonhole-0.2.1 installation in wrong lib dir?)
Hi, On Thu, 2010-10-28 at 09:28 +0200, wolfgang.frie...@desy.de wrote: On Wed, 27 Oct 2010, Axel Thimm wrote: Still managesieve-login manages to be built w/o rpath. But this is in another specfile altogether, which doesn't even use --disable-rpath. So the issue is somewhere else. I'll do some more testing and report back. Best regards to all people in Zeuthen that can still remember me. :) Hi Axel, sorry, erst lesen dann posten, meine Mail ist doch nicht verloren gegangen... Ich werde die Grüße ausrichten Viele Grüße aus Zeuthen thanks :) I found the bug, it is removing the *.la files from dovecot which messes up with dovecot-pigeonhole. There are now new rpms at ATrpms that don't remove the *.la files, so dovecot-pigeonhole's libtool knows where dovecto libs live and can intelligently apply proper -rpath arguments. If you ask why the libtool libs have been removed in the first place, then the short answer is conformity to upstream packaging. The long answer is that some ages ago there was heated discussion at Fedora about using or not *.la libs for library dependency or using pkgconfig, *-config files and the like. Unfortunately autotools took a blow and the package guidelines forbid the use of libtool libs. This was inherited by RHEL and package lint tools etc., so we all started to conform. E.g. in a Fedora/RHEL world one would probably start patching -rpath arguments into dovecot-config, which would be non-portable, thus a patch that cannot be applied upstream, and which has to be carried into the package. Anyway lifing the strict *.la removal is easier and technically the sane thing to do. (FWIW I've been a pro-libtool proponent) Anyway, please check out the latest packages, you can test the binaries directly (which would give me also a great feedback, not many people are using managesieve and thus there were no bug reports other than yours :), or you can review the source rpm and rpmbuild --rebuild them. -- http://thimm.gr/ - http://ATrpms.net/ signature.asc Description: This is a digitally signed message part
Re: [Dovecot] dovecot Digest, Vol 90, Issue 102
On Mon, 2010-10-25 at 12:24 -0700, Roderick A. Anderson wrote: Alan Brown wrote: ATrpms has builds too, but they're usually out of date. Yeah way of of date. 1.0.7 I think is what I saw. Hm, ATrpms is usually shipping packages within a few days after a release as well as packages of beta releases. What makes you think ATrpms is at 1.0.7? FWIW ATrpms currently carries the following dovecot versions: 1.0.15-1_74 1.1.20-1_98 1.2.15-1_113 2.0.6-0_121 -- http://thimm.gr/ - http://ATrpms.net/ signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Released Pigeonhole v0.2.1 for Dovecot v2.0.4
Hi Juan,
sorry for the late reply I just picked this up mentioning ATrpms:
On Mon, 2010-10-04 at 19:05 +0200, Juan C. Blanco wrote:
Hello Stephan I have some problems to build pigeonhole 0.2.1 over dovect
2.0.5, I've had no problems with previous versions; the system is CentOS
5.5.
FWIW CentOS is supported at ATrpms and there are packages for 0.2.1
there for CentOS, if you need them.
I think that is autotools related, but not sure.
I've dounloaded the archive for pigeonhole, once decompressed:
If I do:
./configure --with-dovecot=../dovecot-2.0.5
make
All seems to work fine
But if I do (like the atrpms package spec):
autoreconf -ifv
./configure --with-dovecot=../dovecot-2.0.5
make
I get the error:
I checked the pigeonhole specfiles at ATrpms, but could not find any
such call, the %build part has been
%build
## crude hack ...
#./autogen.sh
%configure --with-dovecot=%{_libdir}/dovecot \
--with-managesieve=yes \
--enable-header-install=yes \
INSTALL_DATA=install -c -p -m644
make
for quite some time now.
--
http://thimm.gr/ - http://ATrpms.net/
signature.asc
Description: This is a digitally signed message part
[Dovecot] rpath in pigeonhole (was: dovecot-2.0-pigeonhole-0.2.1 installation in wrong lib dir?)
On Wed, 2010-10-06 at 21:49 +0200, wolfgang.frie...@desy.de wrote: On Wed, 2010-10-06 at 17:47 +0200, wolfgang.frie...@desy.de wrote: Therefore the executable will fail to run: ldd /usr/libexec/dovecot/managesieve-login libdovecot-login.so.0 = not found libdovecot.so.0 = not found To me this looks like a bug in the generated Makefile. Could it be that the missing -R is related to --disable-static and --disable-rpath options to configure which I took over from the ATrpms dovecot spec file? Then it would rather be my ignorance of the dependencies between these options, libtool, dovecot and pigeonhole. Sorry for picking this up three weeks later, I didn't notice the issue from the subject. --disable-rpath is supposed to remove rpath calls. But in dovecot's build --disable-rpath seems to not have any effect, there are still -rpath /usr/lib64/dovecot args in the build log (which are needed). Looking at it a bit deeper --disable-rpath seems to only apply if you use the macros from lib-link.m4 (as shipped with gettext for example), so it looks like it's a no-ops for dovecot. Still managesieve-login manages to be built w/o rpath. But this is in another specfile altogether, which doesn't even use --disable-rpath. So the issue is somewhere else. I'll do some more testing and report back. Best regards to all people in Zeuthen that can still remember me. :) -- http://thimm.gr/ - http://ATrpms.net/ signature.asc Description: This is a digitally signed message part
[Dovecot] Version checks and API/ABI/sonames
Hi, pigeonhole/sieve check against dovecot's version comparing to what they have been built against. This means that whenever there is a minor version of dovecot released pigeonhole/sieve need to be rebuilt and then redistributed to users even if there is no need for it (I'm thinking of packaged versions of dovecot and dovecot-pigeonhole). Could the checks become ABI-version aware, so that rebuilds and redistribution are kept to a minimum? Maybe Timo is already keeping API/ABI stability between minor updates, so the version checks should be against the first two version components only. Thanks! -- http://thimm.gr/ - http://ATrpms.net/ signature.asc Description: This is a digitally signed message part
Re: [Dovecot] 2.0rc3: Panic: [...] mailbox_list_is_valid_pattern (was: Crash while accessing mdbox folders)
On Mon, Aug 02, 2010 at 04:01:24PM +0100, Timo Sirainen wrote:
On Thu, 2010-07-29 at 13:56 +0300, Axel Thimm wrote:
Jul 28 19:42:48 lda(athimm): Panic: file mailbox-list-fs.c: line 150
(fs_list_get_path): assertion failed:
(mailbox_list_is_valid_pattern(_list, name))
..
I found what the issue was, a bogus line in my sieve script tried to use
a match variable that hadn't been set (e.g. I matched only two globs,
but I used ${3}).
Is it the same as if you just did fileinto ? I can't reproduce this,
the best I get is:
Aug 02 15:59:25 lda(2189 tss): Error: sieve: msgid=b...@blah: subject=blah:
failed to store into mailbox '': Unknown namespace
Aug 02 15:59:25 lda(2189 tss): Error: sieve: execution of script
/home/tss/.dovecot.sieve failed, but implicit keep was successful
or if I have a prefix= namespace, then it just quietly goes to INBOX.
Here are my rules for mailing lists catchall:
if header :matches List-ID **.* {
fileinto :create ${folder}/${3}/${2};
addflag DeliveredTo $${dflag};
} elsif header :matches List-ID ** {
fileinto :create ${folder}/${2};
addflag DeliveredTo $${dflag};
} elsif header :matches List-ID *.* {
fileinto :create ${folder}/${2}/${1};
addflag DeliveredTo $${dflag};
} elsif header :matches List-ID * {
fileinto :create ${folder}/${1};
addflag DeliveredTo $${dflag};
} elsif header :matches List-Owner mailto:*-ow...@* {
fileinto :create ${folder}/${2}/${1};
addflag DeliveredTo $${dflag};
} elsif header :matches List-post mailto:*...@* {
fileinto :create ${folder}/${2}/${1};
addflag DeliveredTo $${dflag};
} elsif header :matches List-owner mailto:*-requ...@* {
fileinto :create ${folder}/${2}/${1};
addflag DeliveredTo $${dflag};
}
Due to copy and paste I had some rules like
} elsif header :matches List-Owner mailto:*-ow...@* {
fileinto :create ${folder}/${3}/${2};
addflag DeliveredTo $${dflag};
} [...]
The bad rules only triggered on very few mailing lists (those that
don't use proper List-*: headers), so I only noticed a couple of days
later. IIRC two of the lists were bugzilla and scientific-linux.
E.g. the fileinto was probably given some argument of lists//somedomain.org
Does this information help?
Re: [Dovecot] How to disable /Noselect Flag
Hi, On Tue, Aug 03, 2010 at 11:53:32AM +0100, Nabil TAZI wrote: can you help me to disable the /Noselect flag from folder so imap client can select the folder and his sub-folders to store mails inside If this is an mbox backend then I think you are not supposed to, as selectable im imap speach means it could carry messages. There are other flags that prevent clients from accessing subfolders like haschildren. What imap client and what dovecot backend are you using?
Re: [Dovecot] 2.0rc3: Panic: [...] mailbox_list_is_valid_pattern (was: Crash while accessing mdbox folders)
On Wed, 2010-07-28 at 22:08 +0300, Axel Thimm wrote:
I know this has been fixed on July 11th, and I'm not using acl or mdbox
(yet), but I see similar errors on 2.0rc3 on plain mboxes:
Jul 28 19:42:48 lda(athimm): Panic: file mailbox-list-fs.c: line 150
(fs_list_get_path): assertion failed:
(mailbox_list_is_valid_pattern(_list, name))
Jul 28 19:42:48 lda(athimm): Error: Raw
backtrace: /usr/lib64/dovecot/libdovecot.so.0() [0x3c1e43770a]
- /usr/lib64/dovecot/libdovecot.so.0(default_fatal_handler+0x37)
[0x3c1e4377e7] - /usr/lib64/dovecot/libdovecot.so.0(i_error+0)
[0x3c1e437b03] - /usr/lib64/dovecot/libdovecot-storage.so.0()
[0x3c1e8608c7] - /usr/lib64/dovecot/libdovecot-storage.so.0()
[0x3c1e88b7d7]
-
/usr/lib64/dovecot/libdovecot-storage.so.0(index_storage_mailbox_alloc+0x13c)
[0x3c1e8708ac] - /usr/lib64/dovecot/libdovecot-storage.so.0() [0x3c1e88b387]
- /usr/lib64/dovecot/libdovecot-storage.so.0(mailbox_alloc+0x5d)
[0x3c1e82e88d] -
/usr/lib64/dovecot/libdovecot-lda.so.0(mail_deliver_save_open+0xd2)
[0x3c1ec05292] - /usr/lib64/dovecot/libdovecot-sieve.so.0() [0x3c1f032dd0]
- /usr/lib64/dovecot/libdovecot-sieve.so.0(sieve_result_execute+0x95)
[0x3c1f02aca5] -
/usr/lib64/dovecot/libdovecot-sieve.so.0(sieve_execute+0x7d) [0x3c1f03999d]
- /usr/lib64/dovecot/lib90_sieve_plugin.so(+0x2a8e) [0x7faff7568a8e] -
/usr/lib64/dovecot/libdovecot-lda.so.0(mail_deliver+0x45) [0x3c1ec05a25] -
/usr/libexec/dovecot/dovecot-lda(main+0x432) [0x4028e2] -
/lib64/libc.so.6(__libc_start_main+0xfd) [0x3306a1eb1d] -
/usr/libexec/dovecot/dovecot-lda() [0x402289]
I found what the issue was, a bogus line in my sieve script tried to use
a match variable that hadn't been set (e.g. I matched only two globs,
but I used ${3}).
So it's a cockpit issue, but maybe the error message and error recovery
(the mails are lost, not even temped) could be managed differently?
Thanks!
--
http://ATrpms.net/
signature.asc
Description: This is a digitally signed message part
[Dovecot] dovecot lda sieve: resubmit folder for resieving
Hi, I'm currently restructuring my mail archives and migrated from a decade and a half old procmail supported solution to sieve. While doing so I often found that I'd like to filter a bunch of messages (with bunch in the area of 1-10K) with my shiny new sieve script. I found in the wiki a way to do that: http://wiki.dovecot.org/HowTo/RefilterMail And it works well, it picks the mails via IMAP and resubmits them to dovecot-lda. But unfortunately the IMAP flags including \Sent, \Flagged etc are lost in the process. I started checking for other solutions beside getmail that might extract the imap flags as well, but I wouldn't know how to pass them to dovecot-lda. Would it make sense to suggest to have dovecot offer this kind of reprocessing itself? That way nothing would get lost in any transition. -- http://ATrpms.net/ signature.asc Description: This is a digitally signed message part
Re: [Dovecot] dovecot lda sieve: resubmit folder for resieving
On Wed, 2010-07-28 at 11:29 +0200, Patrick Ben Koetter wrote: * Axel Thimm axel.th...@atrpms.net: I'm currently restructuring my mail archives and migrated from a decade and a half old procmail supported solution to sieve. While doing so I often found that I'd like to filter a bunch of messages (with bunch in the area of 1-10K) with my shiny new sieve script. I found in the wiki a way to do that: http://wiki.dovecot.org/HowTo/RefilterMail And it works well, it picks the mails via IMAP and resubmits them to dovecot-lda. But unfortunately the IMAP flags including \Sent, \Flagged etc are lost in the process. I started checking for other solutions beside getmail that might extract the imap flags as well, but I wouldn't know how to pass them to dovecot-lda. Would it help to use sieve capabilities to add flags? First getmail/fetchmail etc. would have to add some custom headers like X-Sieve-Please-Add-These-Flags: \Seen But before that can happen getmail/fetchmail need to be able to retrieve the IMAP flags and add them to a header, finally sieve would need to be able to remove this header to restore the mail back to its original form. If dovecot/pigeonhole could manage the resubmission internally, then you also have the benefit, that it wouldn't need any extraction/reinsertion in formats like dbox at all (unless sieve allows changing headers/body). -- http://ATrpms.net/ signature.asc Description: This is a digitally signed message part
Re: [Dovecot] 2.0rc3: Panic: [...] mailbox_list_is_valid_pattern (was: Crash while accessing mdbox folders)
Hi, On Sun, 2010-07-11 at 09:46 +0200, Matthias Rieber wrote: I've converted some accounts with dsync mirror maildir:~/Maildir. It seemed to work, but when I access the folders via IMAP I get the following error: Jul 11 09:41:59 shrike dovecot: imap(matze): Debug: acl vfile: file /home/matze/mdbox/mailboxes/Telefon/dbox-Mails/dovecot-acl not found Jul 11 09:41:59 shrike dovecot: imap(matze): Panic: file mailbox-list-fs.c: line 150 (fs_list_get_path): assertion failed: (mailbox_list_is_valid_pattern(_list, name)) Jul 11 09:41:59 shrike dovecot: imap(matze): Error: Raw backtrace: /usr/local/lib/dovecot/libdovecot.so.0 [0x2b344bcd2da2] - /usr/local/lib/dovecot/libdovecot.so.0 [0x2b344bcd2e0a] - /usr/local/lib/dovecot/libdovecot.so.0(i_error+0) [0x2 b344bcd31b3] - /usr/local/lib/dovecot/libdovecot-storage.so.0 [0x2b344ba2eb8d] - /usr/local/lib/dovecot/lib01_acl_plugin.so [0x2b344c89c203] - /usr/local/lib/dovecot/lib01_acl_plugin.so(acl_mailbox_list_have_right+0x71) [0x2b344c8a0291] - /usr/local/lib/dovecot/lib01_acl_plugin.so [0x2b344c8a067c] - /usr/local/lib/dovecot/libdovecot-storage.so.0(mailbox_list_iter_next+0xa) [0x2b344b9fefaa] - /usr/local/lib/dovecot/lib01_acl_plugin.so [0x2b344c89feba] - /usr/local/lib /dovecot/lib01_acl_plugin.so [0x2b344c8a0782] - /usr/local/lib/dovecot/libdovecot-storage.so.0(mailbox_list_iter_next+0xa) [0x2b344b9fefaa] - /usr/local/lib/dovecot/lib01_acl_plugin.so [0x2b344c89feba] - /usr/local/lib/dovecot/lib01_acl _plugin.so [0x2b344c8a0782] - /usr/local/lib/dovecot/libdovecot-stor Jul 11 09:41:59 shrike dovecot: master: Error: service(imap): child 3174 killed with signal 6 (core dumped) I know this has been fixed on July 11th, and I'm not using acl or mdbox (yet), but I see similar errors on 2.0rc3 on plain mboxes: Jul 28 19:42:48 lda(athimm): Panic: file mailbox-list-fs.c: line 150 (fs_list_get_path): assertion failed: (mailbox_list_is_valid_pattern(_list, name)) Jul 28 19:42:48 lda(athimm): Error: Raw backtrace: /usr/lib64/dovecot/libdovecot.so.0() [0x3c1e43770a] - /usr/lib64/dovecot/libdovecot.so.0(default_fatal_handler+0x37) [0x3c1e4377e7] - /usr/lib64/dovecot/libdovecot.so.0(i_error+0) [0x3c1e437b03] - /usr/lib64/dovecot/libdovecot-storage.so.0() [0x3c1e8608c7] - /usr/lib64/dovecot/libdovecot-storage.so.0() [0x3c1e88b7d7] - /usr/lib64/dovecot/libdovecot-storage.so.0(index_storage_mailbox_alloc+0x13c) [0x3c1e8708ac] - /usr/lib64/dovecot/libdovecot-storage.so.0() [0x3c1e88b387] - /usr/lib64/dovecot/libdovecot-storage.so.0(mailbox_alloc+0x5d) [0x3c1e82e88d] - /usr/lib64/dovecot/libdovecot-lda.so.0(mail_deliver_save_open+0xd2) [0x3c1ec05292] - /usr/lib64/dovecot/libdovecot-sieve.so.0() [0x3c1f032dd0] - /usr/lib64/dovecot/libdovecot-sieve.so.0(sieve_result_execute+0x95) [0x3c1f02aca5] - /usr/lib64/dovecot/libdovecot-sieve.so.0(sieve_execute+0x7d) [0x3c1f03999d] - /usr/lib64/dovecot/lib90_sieve_plugin.so(+0x2a8e) [0x7faff7568a8e] - /usr/lib64/dovecot/libdovecot-lda.so.0(mail_deliver+0x45) [0x3c1ec05a25] - /usr/libexec/dovecot/dovecot-lda(main+0x432) [0x4028e2] - /lib64/libc.so.6(__libc_start_main+0xfd) [0x3306a1eb1d] - /usr/libexec/dovecot/dovecot-lda() [0x402289] -- http://ATrpms.net/ signature.asc Description: This is a digitally signed message part
[Dovecot] beta5 builds under RHEL
Hi, beta4 built under RHEL4, RHEL5 and RHEL6 (the latter being the public beta). beta5 now builds only for RHEL5, the other two fail with: strnum.c: In function `str_to_llong': strnum.c:139: error: `LLONG_MIN' undeclared (first use in this function) strnum.c:139: error: (Each undeclared identifier is reported only once strnum.c:139: error: for each function it appears in.) Thanks! -- Axel.Thimm at ATrpms.net pgpgURLdHC3es.pgp Description: PGP signature
Re: [Dovecot] beta5 builds under RHEL
On Sun, May 30, 2010 at 09:42:38AM +0200, Pascal Volk wrote: On 05/30/2010 09:05 AM Axel Thimm wrote: beta4 built under RHEL4, RHEL5 and RHEL6 (the latter being the public beta). beta5 now builds only for RHEL5, the other two fail with: strnum.c: In function `str_to_llong': strnum.c:139: error: `LLONG_MIN' undeclared (first use in this function) strnum.c:139: error: (Each undeclared identifier is reported only once strnum.c:139: error: for each function it appears in.) LLONG_MIN is defined in /usr/include/limits.h (at least on my systems). It's provided by the package libc6-dev (on Debian GNU/Linux). src/lib/strnum.c - includes lib.h src/lib/lib.h- includes limits.h Defines your limits.h LLONG_MIN? If not, which libc/version is RHEL 6 using? LLONG_MIN/LLONG_MAX and some other defines are there, but protected by # ifdef __USE_ISOC99 Maybe dovecot's buildsystem should check for and use -std=c99? But then I wonder why it does build for RHEL5 and all recent Fedoras? I grepped the logs and found no explicit -std switch in any of the successful builds. Thanks! -- Axel.Thimm at ATrpms.net pgphnfyWmt80e.pgp Description: PGP signature
Re: [Dovecot] beta5 builds under RHEL
On Sun, May 30, 2010 at 10:41:12AM +0200, Pascal Volk wrote: On 05/30/2010 09:54 AM Axel Thimm wrote: LLONG_MIN/LLONG_MAX and some other defines are there, but protected by # ifdef __USE_ISOC99 Maybe dovecot's buildsystem should check for and use -std=c99? But then I wonder why it does build for RHEL5 and all recent Fedoras? I grepped the logs and found no explicit -std switch in any of the successful builds. Wow, now I'm wondering too: limits.h:102 # ifdef __USE_ISOC99 define LLONG_MAX, LLONG_MIN, ULLONG_MAX limits.h:111 # endif /* ISO C99 */ limits.h:131 #if defined __USE_ISOC99 defined __GNUC__ ifndef LLONG_MIN, LLONG_MAX, ULLONG_MAX define theme limits.h:141 #endif Dovecot used std=gnu99, when possible configure.in:300 # Use std=gnu99 if we have new enough gcc configure.in:301 old_cflags=$CFLAGS configure.in:302 CFLAGS=-std=gnu99 gcc(1) gnu99 GNU dialect of ISO C99. When ISO C99 is fully implemented in GCC, this will become the default. … Which gcc uses RHEL 6? It works for me with gcc-4.3 and gcc-4.4. The gcc I used are RHEL4 3.4.6fails RHEL5 4.1.2builds F114.4.1builds F124.4.3builds RHEL6 (beta1) 4.4.3fails F134.4.4builds -- Axel.Thimm at ATrpms.net pgpngv2pczMhX.pgp Description: PGP signature
Re: [Dovecot] beta5 builds under RHEL
On Sun, May 30, 2010 at 02:32:49AM -0700, Brandon Davidson wrote: Axel, On 5/30/10 12:05 AM, Axel Thimm axel.th...@atrpms.net wrote: beta4 built under RHEL4, RHEL5 and RHEL6 (the latter being the public beta). beta5 now builds only for RHEL5, the other two fail with: strnum.c: In function `str_to_llong': strnum.c:139: error: `LLONG_MIN' undeclared (first use in this function) strnum.c:139: error: (Each undeclared identifier is reported only once strnum.c:139: error: for each function it appears in.) FWIW, the build fails with the same error within my CentOS 5 Mock build environment. I'm not sure what I've got set up different than you, but I'm using a slightly tweaked version of your spec file and a pretty vanilla Mock 0.6 setup. Sorry, I mixed things up (RHEL6 beta1 is labeled as el5_89 at ATrpms). E.g. the broken builds are RHEL4 and RHEL5, and RHEL6 beta builds. -- Axel.Thimm at ATrpms.net pgpSLQVJURGSm.pgp Description: PGP signature
Re: [Dovecot] beta5 builds under RHEL
On Sun, May 30, 2010 at 12:30:48PM +0300, Axel Thimm wrote: On Sun, May 30, 2010 at 10:41:12AM +0200, Pascal Volk wrote: On 05/30/2010 09:54 AM Axel Thimm wrote: LLONG_MIN/LLONG_MAX and some other defines are there, but protected by # ifdef __USE_ISOC99 Maybe dovecot's buildsystem should check for and use -std=c99? But then I wonder why it does build for RHEL5 and all recent Fedoras? I grepped the logs and found no explicit -std switch in any of the successful builds. Sorry, as stated in a post just moments ago, the broken build is RHEL5, and RHEL6 works. Which gcc uses RHEL 6? It works for me with gcc-4.3 and gcc-4.4. The gcc I used are [...] OK, the proper matrix looks like: RHEL4 3.4.6fails RHEL5 4.1.2fails F114.4.1builds F124.4.3builds RHEL6 (beta1) 4.4.3builds F134.4.4builds Now it is more consistent and looks like a change between 4.1.2 and 4.4.1. Maybe in the older gcc -std=gnu99 didn't set __USE_ISOC99 and thus the missing constants were not defined? -- Axel.Thimm at ATrpms.net pgpn4I7SFRLCS.pgp Description: PGP signature
Re: [Dovecot] beta5 builds under RHEL
Hi, On Sun, May 30, 2010 at 12:12:17PM +0100, Timo Sirainen wrote: On 30.5.2010, at 12.03, Brandon Davidson wrote: If I '%define optflags -std=gnu99' in the spec it builds just fine, so I don't think it's a compiler problem. Maybe a libtool issue? Oh, the spec file overrides CFLAGS and doesn't contain -std=gnu99? The config.log for RHEL5/x86_64 says: CFLAGS='-std=gnu99 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -I/usr/kerberos/include ' -- Axel.Thimm at ATrpms.net pgppdTwRiMoD3.pgp Description: PGP signature
Re: [Dovecot] beta5 builds under RHEL
Hi, On Sun, May 30, 2010 at 12:22:52PM -0700, Brandon Davidson wrote: On 5/30/10 10:22 AM, Axel Thimm axel.th...@atrpms.net wrote: Oh, the spec file overrides CFLAGS and doesn't contain -std=gnu99? The config.log for RHEL5/x86_64 says: CFLAGS='-std=gnu99 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -I/usr/kerberos/include ' It may be a specfile after all. %configure exports CFLAGS before calling ./configure, which should be sufficient to get any needed options into the Makefile, merged with whatever configure auto-detects (including -std=gnu99). Your spec also calls make CFLAGS=$RPM_OPT_FLAGS which overrides everything and omits -std=gnu99 unless specifically included by the packager. No, that's not quite correct. If you check the above you will find that the CFLAGS passed on the make argument list is just the starting value for CFLAGS. The -std=gnu99 is added by configure, there is no need to have it added by the packager. If I remove that and just call 'make' it works fine - my %optflags are merged in with the CFLAGS from configure and the build completes without error. How are your %optflags (which is the same as $RPM_OPT_FLAGS) merged into the build if it is not passed to make? And it would yield the same CFLAGS as above (merged default optflags with what configure adds to it). -- Axel.Thimm at ATrpms.net pgpeZbu7mbE7c.pgp Description: PGP signature
Re: [Dovecot] beta5 builds under RHEL
Hi, On Sun, May 30, 2010 at 08:02:03PM -0700, Brandon Davidson wrote: On 5/30/10 2:49 PM, Axel Thimm axel.th...@atrpms.net wrote: How are your %optflags (which is the same as $RPM_OPT_FLAGS) merged into the build [...] They're exported by the %configure macro, and configure writes the combined CFLAGS, CXXFLAGS, and FFLAGS into the Makefile... so it's not necessary (and possibly detrimental) to both export them before configuring and pass them explicitly to make, as the command-line CLFAGS option overrides the Makefile CFLAGS declaration that includes -std=gnu99. True, I wasn't wearing my brain in the last post ;) Indeed, both configure and make were getting the same CFLAGS, and while configure was properly altering it, the make invocation was resetting it again. :/ More interesting is the fact that I introduced the bug with the dovecot-2.x specfile, so the 1.x builds were unaffected. I wonder how this did sneak in. My point is, if I don't inclue CFLAGS=... in my call to make in the spec file, it builds fine, and *does* include all the necessary optflags. Give it a try. Doing so and RHEL5/x86_64 already built w/o an issue, I now quite positive that the rest including RHEL4 will be as happy! Thanks for finding the bug! -- Axel.Thimm at ATrpms.net pgp11nYLxDU2q.pgp Description: PGP signature
Re: [Dovecot] pigeonhole: naming and versioning
On Thu, Apr 08, 2010 at 12:09:27PM +0200, Stephan Bosch wrote: Axel Thimm wrote: As a (downstream) packager I have some questions: a) pigeonhole is called a working title - will the final release be called something else like dovecot-sieve again? Well, I was a bit uncertain about the name. People who don't know what a pigeonhole is or what the verb means (especially the Dutch), sometimes have `interesting' associations with that name. I am quite confident though that this name is the definitive one. I'll adjust the website accordingly. :) b) The versioning seems to go from 0.1.15 to 0.1.13. From a packager's POV it would be better to allow a natural version upgrade path. Perhaps the version in hg is just not updated? The reason for these questions/clarifications are that Angel and I are packaging dovecot 2.x betas and matching sieve plugins for allowing more people to a broader testing before the projects go gold. We'd like to have proper naming and versioning in place already for the beta packages. The Pigeonhole project is not released for v2.0 yet, so there is no version for v2.0. Current plans are to call name the packages dovecot-2.0-pigeonhole-0.2.0. However, this versioning scheme is not ideal, so ideas are welcome. How about using a version scheme starting with 2.0? If there is a pigeonhole for each 2.0.x release, then dovecot-2.0.x.tar.bz2 dovecot-pigeonhole-2.0.x.tar.bz2 could be the released pairs. -- Axel.Thimm at ATrpms.net pgpm5GS9pMlOg.pgp Description: PGP signature
[Dovecot] pigeonhole: naming and versioning
Hi Stephan, many thanks for all the work you do on the new sieve parts to dovecot. As a (downstream) packager I have some questions: a) pigeonhole is called a working title - will the final release be called something else like dovecot-sieve again? b) The versioning seems to go from 0.1.15 to 0.1.13. From a packager's POV it would be better to allow a natural version upgrade path. Perhaps the version in hg is just not updated? The reason for these questions/clarifications are that Angel and I are packaging dovecot 2.x betas and matching sieve plugins for allowing more people to a broader testing before the projects go gold. We'd like to have proper naming and versioning in place already for the beta packages. Thanks! -- Axel.Thimm at ATrpms.net pgpqB7XG6rRST.pgp Description: PGP signature
[Dovecot] OT: best linux imap client for dovecot
Hi, I'm a long term dovecot user, packager and believer, but on the other side of the wire I've been a mutt user for longer than I can think. Which modern email client under Linux is working best with dovecot? I just did a grep on User-Agent:/X-Mailer: on my dovecot archive (which goes back to 2004) and found that the top ten are: 28% Thunderbird 25% Evolution 9% Apple Mail 9% Mutt 5% Mozilla 3% KMail 2% Outlook 2% SquirrelMail 1% Alpine 1% Mulberry ... So it looks like most Linux people here like to use Thunderbird and Evolution. This is not a my-email-client-is-better-than-your-email-client thread, I just want to know which client(s) make proper use of imap features for fast searches/copies/deletions etc. Thanks! -- Axel.Thimm at ATrpms.net pgpYOsYdKv7jJ.pgp Description: PGP signature
Re: [Dovecot] compiling issue 1.2.6 - Solaris
On Tue, Oct 06, 2009 at 09:22:12AM -0400, Timo Sirainen wrote: On Oct 6, 2009, at 9:00 AM, Bruce Bodger wrote: On Oct 6, 2009, at 3:55 AM, Jernej Porenta wrote: I am expiriencing compiling issues on Solaris 8 and Solaris 10 boxes with dovecot 1.2.6. On Solaris 8 the compiler is gcc 64bit 3.2.2, on Solaris 10 gcc 3.4.3. Same type of problem here on OS X 10.5.8 Server. Command line to configure: ./configure --with-ssldir=/System/ Library/OpenSSL --with-ssl=openssl .. Undefined symbols: _SSL_get_current_compression, referenced from: _ssl_proxy_get_security_string in liblogin-common.a(ssl-proxy- openssl.o) _SSL_COMP_get_name, referenced from: _ssl_proxy_get_security_string in liblogin-common.a(ssl-proxy- openssl.o) What OpenSSL version do you have? I thought those compression functions were new enough that everyone would have them by now.. Just to add another data point - it also failed on RHEL4 (openssl 0.9.7a), but your fix in hg already took care of it, thanks! -- Axel.Thimm at ATrpms.net pgpjpoOMvthI0.pgp Description: PGP signature
Re: [Dovecot] OT: IMAP folder aliases
On Fri, Sep 25, 2009 at 07:55:41PM +0300, Timo Sirainen wrote: On Sep 25, 2009, at 7:49 PM, Eric Shubert wrote: Timo Sirainen wrote: On Sep 25, 2009, at 4:14 PM, Patrick Ben Koetter wrote: Has anyone seen an approach or a solution that solves the problem from a users point of view? A server side alias list that maps to a server standard? Symlinks maybe? Or something similar done internally. The main problem would anyway be LIST command, should it show all of them or somehow try to figure out which one to show? Do the clients identify which program they are? No. And one of the first commands they typically do is LIST. So there are no good ways to solve this. Although I haven't really seen much problems myself. Linux clients allow changing what mailboxes they use, so I just configure them to use the same as Apple Mail.. Given than you seem to bless Apple Mail folder structures it makes it a good candidate to try to push as a standard for others to copy. Maybe there could be example setups/configs shipped with dovecot that maps other naming conventions to Apple's? In that way dovecot would start to inforce the use of a standard which in the long term could become a real standard. If Apple's structure are not the best to go with, then we could use some other naming convention, I just trust that Timo's choice is not a bad one. ;) -- Axel.Thimm at ATrpms.net pgpzQKx7cBwOE.pgp Description: PGP signature
Re: [Dovecot] OT: IMAP folder aliases
On Sat, Sep 26, 2009 at 11:40:21AM +0300, Axel Thimm wrote: On Fri, Sep 25, 2009 at 07:55:41PM +0300, Timo Sirainen wrote: On Sep 25, 2009, at 7:49 PM, Eric Shubert wrote: Timo Sirainen wrote: On Sep 25, 2009, at 4:14 PM, Patrick Ben Koetter wrote: Has anyone seen an approach or a solution that solves the problem from a users point of view? A server side alias list that maps to a server standard? Symlinks maybe? Or something similar done internally. The main problem would anyway be LIST command, should it show all of them or somehow try to figure out which one to show? Do the clients identify which program they are? No. And one of the first commands they typically do is LIST. So there are no good ways to solve this. Although I haven't really seen much problems myself. Linux clients allow changing what mailboxes they use, so I just configure them to use the same as Apple Mail.. Given than you seem to bless Apple Mail folder structures it makes it a good candidate to try to push as a standard for others to copy. Maybe there could be example setups/configs shipped with dovecot that maps other naming conventions to Apple's? In that way dovecot would start to inforce the use of a standard which in the long term could become a real standard. If Apple's structure are not the best to go with, then we could use some other naming convention, I just trust that Timo's choice is not a bad one. ;) I forgot to ask: How do Apple Mail's structures look like? -- Axel.Thimm at ATrpms.net pgpZ9h5YFhk3E.pgp Description: PGP signature
Re: [Dovecot] OT: IMAP folder aliases
Hi, On Sat, Sep 26, 2009 at 12:33:21PM +0200, Robert Schetterer wrote: Axel Thimm schrieb: Given than you seem to bless Apple Mail folder structures it makes it a good candidate to try to push as a standard for others to copy. Maybe there could be example setups/configs shipped with dovecot that maps other naming conventions to Apple's? In that way dovecot would start to inforce the use of a standard which in the long term could become a real standard. If Apple's structure are not the best to go with, then we could use some other naming convention, I just trust that Timo's choice is not a bad one. ;) sorry apple mail , has a long history of bugs with imap ( special it acted not very good with courier an other namespaces ) and there are no version for linux and windows, so i personally dont like it Well, I wasn't advocating for using the client or any software part of Apple Mail, just the folder structure it uses in case it is universally useful and acceptable. In any case any standard be it derived from Apple Mail, something else, or maybe a new dovecot standard would be better than the current zoo of setups. And having dovecot implement that standard in default config files with mappings for the most common imap clients will certainly make it a widely used standard in the long term. -- Axel.Thimm at ATrpms.net pgprbOXGBxyJG.pgp Description: PGP signature
Re: [Dovecot] 1.2.3 - fchown failed messages
Hi,
On Tue, Aug 04, 2009 at 08:00:42PM -0400, Timo Sirainen wrote:
On Tue, 2009-08-04 at 19:53 -0400, Rob Mangiafico wrote:
What permissions does /var/spool/mail/john have? I guess mail group has
read permissions? Just removing that should fix the error.
-rw-rw 1 john mail 5676767 Aug 4 19:50 /var/spool/mail/john
Those are the default permissions that sendmail uses I believe. Not sure
if removing mail group r/w would have any other impact for
sendmail/procmail? Thanks for taking the time to help.
It depends on your setup, but usually mail group shouldn't need read or
write access to users' mails. Seems like a security risk to me in any
case.
I think that's the standard setup on Red Hat/CentOS/Fedora boxes. User
mboxes are by default owned by user:mail with 0660, while the
spooldir is owned root:mail with 0775
# useradd abc123
# ls -ltrAd /var/spool/mail{,/abc123}
-rw-rw 1 abc123 mail0 2009-08-06 19:44 /var/spool/mail/abc123
drwxrwxr-x. 2 root mail 4096 2009-08-06 19:44 /var/spool/mail
--
Axel.Thimm at ATrpms.net
pgp1qMkb6SKQz.pgp
Description: PGP signature
Re: [Dovecot] problems with dotlock
On Mon, Mar 02, 2009 at 01:25:43PM -0800, Mark Hedges wrote: On Fri, 27 Feb 2009, Timo Sirainen wrote: Ah, this explains everything. Fixed both your problem and the segfault: f831d12187d1 Yes, this patch fixed the problem when applied to pristine 1.1.11 source. Will there be an update of the RPM at http://atrpms.net/dist/el5/dovecot/? dovecot has a healthy release cycle, so any patches are picked directly through upgrading to the next dovecot release. It's hard enough for automating deployment of new servers that I have to use a downloaded RPM instead of using yum, since I doubt CentOS's two-year-old version of 1.0.7 will ever be updated. Compiling from source is a pain but I'll use it for now. Actually the packages at ATrpms are in a yum repo, and even if you don't want to point yum to it for any reason (maybe you don't trust the rest of the content), you can create your own local repo and place the downloaded rpm there. This will automate the deployment of new servers again, you will only need to touch the setup for rpm upgrades. -- Axel.Thimm at ATrpms.net pgp92X645D2l6.pgp Description: PGP signature
Re: [Dovecot] dovecot imap auth fails to reconnect pgsql backend
On Fri, Sep 26, 2008 at 09:52:58PM +0800, Frank Wang wrote: You don't need to rebuild ATrpms' packages for symbol support, just install the debuginfo package as well. I've done that and posted the gdb backtrack already. Is there any other info needed? Some symbol tables were missing. It suggests that some parts of the rpm had not been built with -g. In that case you would need to build from source and check what flags are being used, e.g. to verify -g is part of them. -- Axel.Thimm at ATrpms.net pgpZJMNR341xd.pgp Description: PGP signature
Re: [Dovecot] dovecot imap auth fails to reconnect pgsql backend
Hi, On Wed, Sep 24, 2008 at 08:07:48PM +0800, Frank Wang wrote: * Frank Wang [EMAIL PROTECTED]: Another possibility would be to attach gdb to the running dovecot-auth process: And to build a binary with symbols (-g option, no stripping) I used rpmbuild -ba to build the dovecot-1.1.3-0_80.i386.rpm from dovecot-1.1.3-0_80.src.rpm from atrpms.net. There is also a dovecot-debuginfo-1.1.3-0_80.i386.rpm in the built i386 directory. Is it the same to also install it? You don't need to rebuild ATrpms' packages for symbol support, just install the debuginfo package as well. -- Axel.Thimm at ATrpms.net pgpzFxiXIAANU.pgp Description: PGP signature
Re: [Dovecot] Experience moving mailboxes from Dovecot 0.99.14 to Dovecot 1.07 = Improvement possible
Hi, On Wed, Aug 06, 2008 at 10:55:08AM -0500, Eric Rostetter wrote: Quoting Charles Marcus [EMAIL PROTECTED]: rpms for centos available on atrpms.net Sadly not for Centos 3.x, only for Centos 4/5... :( Anyone know about Dovecot 1.1.x rpms for Centos/RHEL 3.x? You could try to rebuild from ATrpms' src.rpm, but to spare some trouble this is what I had with 1.1.rc4 4 months ago: checking for auth_userokay... no checking for krb5-config... YES configure: error: Can't build with GSSAPI support: v1.2 library not supported Maybe one could patch the specfile/package up to support RHEL3, and if you want to you could maintain this at ATrpms. -- Axel.Thimm at ATrpms.net pgpYJlsQIeRAS.pgp Description: PGP signature
Re: [Dovecot] lib90_cmusieve_plugin.so: undefined symbol: message_decoder_init
On Wed, Jul 30, 2008 at 01:01:22PM +0300, Uldis Pakuls wrote: Thomas Harold wrote: Uldis Pakuls wrote: # yum list | grep dovecot dovecot.x86_64 1:1.1.1-2_76.el5 installed dovecot-sieve.x86_64 1.1.5-8.el5 installed dovecot.x86_64 1:1.1.2-2_77.el5 atrpms dovecot-devel.x86_64 1:1.1.2-2_77.el5 atrpms Looks like you mixed up binaries from different versions of dovecot. I recommend completely remove dovecot, (manually rechecking after rpm remove). and reinstall. Uldis So what versions should we be using? We only had one version of dovecot and one version of dovecot-sieve. Look at your list above, you have dovecot 1.1.1-2_76.el5 *and* dovecot 1.1.2-2_77.el5, this looks quite wrong. lib90_cmusieve_plugin.so: undefined symbol: message_decoder_init - means you have old version of sieve plugin. since 2007-07-20 (see chagelog) plugins use message_decoder_init. previous version used message_decoder_init_ucase. so plugin binaries you have is something form v1.1alpha1... (broken RPMS?) - it is not sieve v1.1.5... I don't think the rpms are broken. Thomas, do as Uldis recommended, remove all traces of dovecot from you system including self-compiled ones that may be under /usr/local. Then reinstall dovecot and dovecot-sieve from ATrpms. Also use rpm -V on packages that are suspect. If you do that on dovecot right now, you will find many inconsitencies as one version was installed over the other. Final note: If you don't want to trust yum onto ATrpms or any other repo and prefer to download/install manually, then never use rpm -i, always use rpm -U (unless you are installing a kernel, that it). The only way two different versions of dovecot being installed on your system (of the same arch also), is if you manually used the -i switch to rpm, or if the yum/smart/apt transaction was killed halfway trough (power loss?). In both cases the only way to recover is to reinstall the package in question. -- Axel.Thimm at ATrpms.net pgp1kRrW6THUD.pgp Description: PGP signature
Re: [Dovecot] Where to find 1.1 RPM for CentOS 4?
Hi, On Sat, Apr 26, 2008 at 10:01:30AM -0400, Charles Marcus wrote: On 4/25/2008 6:15 PM, Patrick wrote: I'm trying to find an rpm for the 1.1 version, since it appears to work better with NFS. Does anyone have a link to the i386 version? atrpms.net has them, but the ones for Centos4 and below are supposedly more problematic than the newer ones... There are no 1.1 rpms yet at ATrpms. If there is interest, we can put some up, but I'd rather wait until Timo starts releasing betas instead of using a CVS snapshot. Centos4 is really starting to show its age, you should really consider upgrading... -- Axel.Thimm at ATrpms.net pgp12Ms2IrRza.pgp Description: PGP signature
Re: [Dovecot] Where to find 1.1 RPM for CentOS 4?
On Wed, Apr 30, 2008 at 06:30:22AM -0400, Charles Marcus wrote: On 4/30/2008 4:23 AM, Axel Thimm wrote: There are no 1.1 rpms yet at ATrpms. Oops, my bad... If there is interest, we can put some up, but I'd rather wait until Timo starts releasing betas instead of using a CVS snapshot. Betas? The current one is rc4... well past beta... Yes, sorry, I mixed up 2.x with 1.1, you're correct, nothing stops us from offering 1.1rc rpms I guess. Anyone interested in helping with the packaging please ping in PM or on atrpms-devel (latter is preferred). -- Axel.Thimm at ATrpms.net pgps70EaCE1mz.pgp Description: PGP signature
Re: [Dovecot] Dovecot pgsqlauthentication database reconnection/failover problem
On Sun, Feb 17, 2008 at 12:03:53AM +0800, Frank Wang wrote: On Sat, 2008-02-16 at 21:46 +0800, Frank Wang wrote: You can find newer Dovecot RPMs for CentOS 5 from atrpms.net. Thanks for the quick reply. I've tested the dovecot-1.0.10-0_66.el5 from atrpms.net. The reconnection problem hasn't occur during the test so far, good! I'll need sometime to test the stability though, as it's marked test in the repo. Everything that replaces a package in RHEL5/CentOS5 is in the testing repo and will never become stable. E.g. just replace the testing label with replaces vendor packages in this case. Still you should give it a good test anyways. -- Axel.Thimm at ATrpms.net pgpOfzXr0rLxk.pgp Description: PGP signature
Re: [Dovecot] New server error
On Thu, Jan 24, 2008 at 07:12:20PM +, Anne Wilson wrote: On Thursday 24 January 2008 19:00:23 Timo Sirainen wrote: On Thu, 2008-01-24 at 18:47 +, Anne Wilson wrote: On Thursday 24 January 2008 18:23:49 Asheesh Laroia wrote: On Thu, 24 Jan 2008, Anne Wilson wrote: I'm setting up a replacement mail server on a CentOS 5.1 box. The dovecot version is 1.0.rc15. 'dovecot -n' returns Can you try upgrading to a more recent Dovecot? 1.0.10 is the current stable release. I'm new to CentOS and still finding my way around. It isn't being offered as an upgrade, but perhaps an FC6 package might work. I'll see what I can find out. Packages in http://atrpms.net/dist/el5/dovecot/ work for CentOS 5. Hmm - I have some packages from rpmforge. IIRC I had problems in FC6 with atrpms conflicting with other repos. I wonder whether it is safe to use rpmforge and atrpms at the same time? I do remember Axel saying that he was working to try to improve the situation. Usually there is little trouble combining them and we're actually working on merging them as rpmrepo.org. -- Axel.Thimm at ATrpms.net pgplsZubFHisz.pgp Description: PGP signature
Re: [Dovecot] dovecot mysql support
On Sun, Nov 18, 2007 at 05:15:24PM -0800, jan gestre wrote: I'm using CentOS 4.5, is the dovecot default rpm comes with mysql support? Do I need to rebuild it? The packages at ATrpms already come with mysql support. Did you try them? -- Axel.Thimm at ATrpms.net pgpLziCD8DpAc.pgp Description: PGP signature
Re: [Dovecot] dovecot mysql support
On Mon, Nov 19, 2007 at 03:21:08PM -0500, Benjamin R. Haskell wrote: On Mon, 19 Nov 2007, Axel Thimm wrote: On Sun, Nov 18, 2007 at 05:15:24PM -0800, jan gestre wrote: I'm using CentOS 4.5, is the dovecot default rpm comes with mysql support? Do I need to rebuild it? The packages at ATrpms already come with mysql support. Did you try them? Do they also have 'inotify' support? I seem to recall trouble with the ATrpms version of dovecot. The particular CentOS 4.5 box I was using still had a 2.4 kernel, since it'd been recently upgraded from RHEL3. (We didn't want to upgrade the kernel on the remote box since it was working fine for our purposes). No, on RHEL4 (and therefore CentOS4 as well) inotify has been disabled. Although I didn't document the reason good enough, so maybe it is worth while checking if a rebuild would be OK (simply rebuilding the package will enable inotify). Would you like to test it and report back? As for a 2.4 kernel on RHEL4 clones: The kernel will not provide the neccessary inotify functions, but I hope dovecot will just notice that and not fail on it (e.g. just disable inotify support). But I haven't tested that combo. -- Axel.Thimm at ATrpms.net pgpubV0ZnzvEg.pgp Description: PGP signature
Re: [Dovecot] Looking for RPM for 1.0.3 for CentOS with imap, ldap, and ssl
On Thu, Aug 02, 2007 at 05:52:55PM -0700, Big Pizzle wrote: Hi, I don't know how to compile Dovecot from src rpm;s - in fact I tried and failed miserably. The only other src rpm I have ever built was postfix, and I ran into a whole bunch of errors trying to build an rpm from the src rpm at ATRpm. There are instructions on how to rebuild the src.rpm at http://wiki.dovecot.org/PrebuiltBinaries Anywho, I was wondering if one of you wonderful Dovecot members would be willing to create an RPM for CentOS 4.5 that includes ldap and ssl. But that's extacly how the ATrpms packages are already built, why not just use them? Or, if someone knows of a URL I can go to and follow a Dovecot-related src rpm build tutorial, that would be of great help too. See above. Heck - I'll even settle for a 1.0.2. Since Dovecot doesn't support 0.99 I want to make sure I have the most recent package. Thanks in advance. Patrick -- Axel.Thimm at ATrpms.net pgpXhqprPLpF1.pgp Description: PGP signature
Re: [Dovecot] MD5 mis-match
On Thu, Aug 02, 2007 at 04:26:34PM -0700, Scott Silva wrote: Big Pizzle spake the following on 8/2/2007 4:19 PM: Hi all, I'm almost finished building our new load balanced email server that are attached to an NFS mountpoint. There are currently two e-mail servers connected to the NFS share. Both email servers are running CentOS 4.5 with Postfix 2.4.3, Dovecot 0.99, and authenticating via LDAP. Dovecot is using Maildir format. I've been trying to do some benchmarks using Postal and Rabid, and whenever I run rabid, I'm getting errors like this: MD5 mis-match, calculated:a628289996ce19910ebbd4eef2ebc3fc, expected 9406a7cf56afb5a1308eb5377e141719! However, when I tail the /var/log/maillog, I don't see errors - I just see the pop3-login. Just wondering if that is okay. I've also been trying to find an RPM for Dovecot 1.0.3, with no avail. Anyone know where I can get one? Thanks in advance. Patrick There is one on ATRpms for 1.0.2, but Axel hasn't yet built 1.0.3. Maybe he hasn't seen the announcement yet. I am considering taking his 1.0.2 src rpm and the source for 1.0.3 and trying to build my own. There are now, actually even a couple of hours before you typed this mail ;) -- Axel.Thimm at ATrpms.net pgpKp1dtbyZwI.pgp Description: PGP signature
Re: [Dovecot] Copyright notices in code
On Fri, Jun 29, 2007 at 05:14:39PM +0300, Timo Sirainen wrote: I thought about committing this change to all .c files: Removed all Copyright Timo Sirainen comments. They weren't always correct and the year numbers were rarely updated when something was changed. Copyright is owned by the creator by default in practically all countries, there's no need to advertise it everywhere. Can anyone think of reasons why this wouldn't be a good idea? The FSF highly recommends putting the whole lot of it in each file. It doesn't hurt and is the safest bet. There are templates to use, that look like what this code does (one line) copyright/dates/author (one to few lines) license text (three paragraphs) -- Axel.Thimm at ATrpms.net pgpxho9OhNSfo.pgp Description: PGP signature
Re: [Dovecot] v1.0.1 released
On Fri, Jun 15, 2007 at 07:55:32PM +0300, Timo Sirainen wrote: http://dovecot.org/releases/dovecot-1.0.1.tar.gz http://dovecot.org/releases/dovecot-1.0.1.tar.gz.sig Lots of small fixes. Packages for RHEL3,4,5 and FC5,6 and F7 are updated to 1.0.1: http://atrpms.net/name/dovecot/ * deliver: If Return-Path doesn't contain user and domain, don't try to bounce the mail (this is how it was supposed to work earlier too) * deliver: %variables in mail setting coming from userdb aren't expanded anymore (again how it should have worked). The expansion could have caused problems if paths contained any '%' characters. + Print Dovecot version number with dovecot -n and -a + deliver: Added -e parameter to write rejection error to stderr and exit with EX_NOPERM instead of sending the rejection by executing sendmail. + dovecot --log-error logs now a warning, an error and a fatal - Trying to start Dovecot while it's already running doesn't anymore wipe out login_dir and break the running Dovecot. - maildir: Fixed UID larger than next_uid errors which happened sometimes when dovecot-uidlist file didn't exist but index files did (usually because mailbox didn't have any messages when it was selected for the first time) - maildir: We violated maildir spec a bit by not having keyword characters sorted in the filename. - maildir: If we don't have write access to cur/ directory, treat the mailbox as read-only. This fixes some internal error problems with trying to use read-only maildirs. - maildir: Deleting a symlinked maildir failed with internal error. - mbox: pop3_uidl_format=%m wasn't working right - mbox: If non-filesystem quota was enabled, we could have failed with Unexpectedly lost From-line errors while saving new messages - mysql auth: %c didn't work. Patch by Andrey Panin - APPEND / SEARCH: If internaldate was outside valid value for time_t, we returned BAD error for APPEND and SEARCH never matched. With 64bit systems this shouldn't have happened. With 32bit systems the valid range is usually for years 1902..2037. - COPY: We sent Hang in there.. too early sometimes and checked it too often (didn't break anything, but was slower than needed). - deliver: Postfix's sendmail binary wasn't working with mail_debug=yes - Don't corrupt ssl-parameters.dat files when running multiple Dovecot instances. - Cache compression caused dovecot.index.cache to be completely deleted with big endian CPUs if 64bit file offsets were used (default) - Fixed (index_mail_parse_header): assertion failed crash -- Axel.Thimm at ATrpms.net pgpT6JfpZ3HtI.pgp Description: PGP signature
Re: [Dovecot] 1.0.1 release candidate 3
On Wed, Jun 13, 2007 at 04:18:06PM -0700, Scott Silva wrote: Mark Nienberg spake the following on 6/13/2007 4:04 PM: Axel Thimm wrote: Are people interested in seeing 1.0.1rcX packaged? Not the RC, but I'm on the edge of my seat to see if 1.0.1 final is available on ATrpms before end of life for Fedora Core 5. Mark That gives it a little more than 2 weeks! ;-) Indeed. Even if ATrpms does ship 1.0.1 a day before FC5 goes EOL what use would that be, you'd have to upgrade the FC5 system to something newer anyway, unless you intend to use FC5 only internally w/o fear for external network attacks. Which in combination with dovecot is not that usual ;) -- Axel.Thimm at ATrpms.net pgp0fVdz1f2zW.pgp Description: PGP signature
Re: [Dovecot] dovecot.spec
On Fri, Apr 20, 2007 at 02:23:17PM -0500, J.Palacios wrote: Yes, but they are all RC.. i need to update v.0.99 to v1.0.0 Did you really look close enough? The very first package lists is 1.0.0 gold. Thanks, JC -Mensaje original- De: Axel Thimm [mailto:[EMAIL PROTECTED] En nombre de Axel Thimm Enviado el: Viernes, 20 de Abril de 2007 01:39 p.m. Para: J.Palacios CC: dovecot@dovecot.org Asunto: Re: dovecot.spec On Fri, Apr 20, 2007 at 12:43:54PM -0500, J.Palacios wrote: Hi List, Plis, where can i find an updated version (for recently dovecot v1.0.0) of dovecot.spec, needed to build an rpm for RH 4? Have you checked the wiki? There are specfiles, src.rpm and binary packages for RHEL4 at http://atrpms.net/dist/el4/dovecot/ -- Axel.Thimm at ATrpms.net pgppd1GArKsYI.pgp Description: PGP signature
Re: [Dovecot] v1.0.0 released
On Fri, Apr 13, 2007 at 03:04:23PM +0300, Timo Sirainen wrote: It took almost 5 years, but it's finally ready. I'm not expecting to release v1.0.1 anytime soon, unless someone's been sitting on a major bug just waiting for v1.0 to be released. :) Happy zeroth birthday :) -- Axel.Thimm at ATrpms.net pgpCwLs3JkZq5.pgp Description: PGP signature
Re: [Dovecot] Version numbering
On Wed, Mar 28, 2007 at 01:39:55PM -0500, Eric Rostetter wrote: I go to atrpms or dag wieers or elsewhere, and it might list both devel and production ones, but it doesn't say that, it just lists version numbers. How am I to know, unless I'm smart enough to go to the original web site and check? I might just assume the highest number one is the one I should run, not knowing it is a devel version. At ATrpms packages in the testing repo are presented in glowing yellow and such in the bleeding in alerting red ;) -- Axel.Thimm at ATrpms.net pgp1Hqu7ynBNG.pgp Description: PGP signature
Re: [Dovecot] Rpm builders: Dovecot spec file
On Mon, Mar 26, 2007 at 11:03:01AM +0200, Egbert Jan wrote: Maybe best asked to Axel... I'm re-building my server from scratch (the old one was MDK 10.1 - Mandriva 2006.0 with Postfix/Courier) and I want to install the latest versions postfix/mysql/postfixadmin/dovecot/squirrelmail. I've been building Dovecot (and postfix) from tarballs/srpm in the past so I know more or less how it all fits together. But I wonder if 'old' patches still need to be included/applied in the building of the latest rc's. I still see references to those patches in the spec file. Unfortunately the latest 'official' rpm for Mandriva (I'm running 2007.0) is rc7 and I never succeeded getting in contact with the Mandriva maintainer to ask the same question. Check out cooker, they seem to be at rc26: http://archives.mandrivalinux.com/changelog/2007-03/msg01539.php In the Axel's AT rpm I still see some patches included but others than in the Mandriva rc7 spec file. Are those patches not already applied to the latest sources by Timo? The patches are too distribution specific like setting cert paths, choosing locking mechanisms and so on. I would pick the latest Mandriva package (cooker) and replace the source tarball. If the patches don't apply, check to see whether they are still neccessary and need readjustment or can be removed. -- Axel.Thimm at ATrpms.net pgpzncZDMLPTE.pgp Description: PGP signature
Re: [Dovecot] --with-vpopmail compile errors
Hi, On Thu, Mar 22, 2007 at 12:23:04PM -0400, Oliver Schulze L. wrote: I'm building dovecot.src.rpm with vpopmail support and I get this error: - dovecot rpm from: http://dl.atrpms.net/all/dovecot-1.0-3_50.rc27.at.src.rpm - rpmbuild command: rpmbuild --rebuild --without inotify --with pam_stack --with forcequota2 --with vpopmail --target=i686 dovecot-1.0-3_50.rc27.at.src.rpm there is no --with vpopmail switch in the src.rpm you used. -- Axel.Thimm at ATrpms.net pgpa1vFPixMZk.pgp Description: PGP signature
Re: [Dovecot] One user having reproducible IMAP issues
On Sun, Mar 18, 2007 at 06:17:24PM -0700, Alex Boster wrote: Thanks -- we figured it out, but that is good to see. Yes, it was 0.99 but has been upgraded. We are filtering out the problematic headers and removed them from the broken mbox files. Everything is working fine now. I'm on rc26, but will go to rc27 when there is a CentOS 4 / RHEL 4 source RPM. Are there are config file or other gotchas in going from rc26 to rc27? It is available for quite some time, but the web display doesn't update as often as the repo. Either point yum to the repo, or pick it up at dl.atrpms.net. The web creation takes longer than simply updating the repo, and the manual web downloading is less than 0.1% at ATrpms, which is why it is just recreated every now and then and may be out of date. AB On Mar 18, 2007, at 6:15 PM, John Robinson wrote: On 16/03/2007 19:06, Alex Boster wrote: Does anyone have a quick recipe for how to do the filtering? We are on CentOS 4 using a near default setup... Does that mean dovecot 0.99? If so you ought to build or download something more recent (ready-made latest is available from atrpms.net) The filtering recipe is `man procmail`, `man formail`, then add something like the following (which I haven't tested) to /etc/ procmailrc :0 fh | formail -I X-UID: -- Axel.Thimm at ATrpms.net pgpN7fwY03DX3.pgp Description: PGP signature
