Re: Deleting files in sdbox
On Dec 27, 2014 3:19 AM, Marc Stürmer m...@marc-stuermer.de wrote: You could use the message UID to delete those pesky messages maybe. Of course you could try deleting those messages on your own and run afterwards a doveadm index. This should also do the job. As I said in my OP I could use doveadm-expunge with a search query. But I've done that and it's very slow to rerun constantly with various UIDs. I could maybe write a query with thousands of UIDs if it wouldn't complain. My actual question as stated was what happens if I just rm those files... if Dovecot will be okay with it, figure out that the mailboxes don't match, and fix the index and cache files. If rerunning doveadm-index after manually will make everything happy, this seems like the faster approach. But I just want to make sure I won't damage the sdbox in a permanent sense. Thanks, Jeff
Deleting files in sdbox
Hello, I'm curious as to what happens if I were to manually delete files in an sdbox on the server. A long time ago -- I'm not sure how, as it was several years ago -- something happened and a number of users got a large number of mail messages duplicated. Literally duplicated -- all headers, all body content. I have a script that can find these duplicated messages (by ignoring the first few and last few lines of each message, and using SHAs to compare and find the duplicates). However, I don't see a doveadm style command to manually delete messages, except for doveadm-expunge. In the past I've used that with search queries but my experience is that trying to do many individual operations on individual files with doveadm-expunge can be quite slow. So, if Dovecot is going to just say huh, my indexes/metadata are wrong, lemme rebuild them, I'd rather just rm the messages and let Dovecot do its thing. Again, this is with sdbox storage. Dovecot version is 2.2.9. Thanks! --Jeff
Re: Awfully slow dovecot
On Dec 25, 2014 3:15 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 25.12.2014 um 21:09 schrieb Benny Pedersen: Robert Schetterer skrev den 2014-12-25 19:49: Am 18.12.2014 um 17:56 schrieb Robin Helgelin: We’re using dovecot 1.0.7 that version is total out of date , update to recent version centos is a precompiled problem :=) no it is not do you realy think the RPMS are falling from heaven or is it more likely be able to use rpmbuild as i do on Fedora for packages like dovecot-2.2.15-3.fc20.20141025.rh.x86_64 or postfix-2.11.3-1.fc20.20141020.rh.x86_64? your Gentoo is nice in a small environment on larger setups someone is using binary packages and can setup his own repo with overrides while maintain *testable* setups Just to point out, it is possible to set up a binary Gentoo setup with a single server compiling packages then made available to downstream computers -- I ran such a setup for a few years. Can also have multiple of these in an overlay fashion for testing. Pros and cons vs. normal binary distros, but it can be done. Anyways, regarding the OP's problem, 1.0.7 is only the latest available package from RedHat/CentOS. It's so out of date and so many bugs have been squashed that it makes little sense for anyone to spend much time trying to figure out the problem. Even Red Hat doesn't support it in production anymore. Might be time to break out the compiler.
[Dovecot] Sieve create non-existent folder
Hello, Is there a way to have a Sieve script create a non-existent folder rather than have it deliver messages to INBOX instead? I'm using Dovecot 2.0.8 with Postfix, via LMTP. Thanks!
Re: [Dovecot] Sieve create non-existent folder
On Sat, Dec 18, 2010 at 9:52 AM, Pascal Volk user+dove...@localhost.localdomain.org wrote: On 12/18/2010 03:33 PM Jeff Mitchell wrote: Is there a way to have a Sieve script create a non-existent folder rather than have it deliver messages to INBOX instead? See RFC 5490 section 3.2 - :create Argument to fileinto Command: http://tools.ietf.org/html/rfc5490#section-3.2 Thanks, Pascal. The RFC doesn't mention whether this will subscribe a user to the newly-created mailbox (such as you can do with the -s flag to doveadm mailbox create) -- is that not done, or an implementation detail (and if so, what does Dovecot do?) Thanks, Jeff
[Dovecot] Problem with expunge
I'm running Dovecot 2.0.8. The other day I tested doveadm expunge on a test Inbox with a few messages received over the course of a day, and using savedbefore a few hours, and it seemed to work. However, today I was testing converting some maildirs over to sdbox, and noticed odd behavior: it's deleting all messages in the specified folder instead of just the ones matching the condition I'm using (savedbefore 4w). The command I'm using is doveadm -Dv expunge -A mailbox Trash savedbefore 4w Because of the conversion, all of the ctimes for all of the files are actually the same (basically, a few minutes ago), due to the converstion to sdbox from maildir, so I would expect that either it doesn't delete any of them or looks inside at some header of the mail (half of which was received/placed into Trash before 4w ago and half of which wasn't). I definitely don't expect full-on deletion... Any idea what's going on? Thanks, Jeff
Re: [Dovecot] Problem with expunge
On Dec 17, 2010 7:20 PM, Timo Sirainen t...@iki.fi wrote: On 17.12.2010, at 21.15, Jeff Mitchell wrote: However, today I was testing converting some maildirs over to sdbox, and noticed odd behavior: it's deleting all messages in the specified folder instead of just the ones matching the condition I'm using (savedbefore 4w). Because of the conversion, all of the ctimes for all of the files are actually the same (basically, a few minutes ago), dbox doesn't use ctime, but a saved-date metadata header. I suppose that header got set wrong in the conversion for some reason (maybe to 0 = year 1970?). You did conversion with dsync, right? I can debug this some day later.. Yes, this was using dsync. Thanks, Jeff
[Dovecot] Very long establishment time for secondary connections
Hello, I'm currently on Dovecot 1.1.17 and I have a user that runs into a problem quite a lot. She's using Thunderbird on a Mac. When she sends mail, Thunderbird is set up to save sent mail to her Sent folder. Often (usually when she has not sent another mail for a long while) when she sends mail, Thunderbird sits there saying Copying message to Sent folder for about thirty seconds. My best guess, after looking at dovecot messages in syslog related to her login, is that Thunderbird is using a secondary imap process to do this copying and this connection times out due to inactivity, so that when she sends mail it has to reestablish itself. For some reason this reestablishment seems to take a very long time, even though her initial login/connection when she opens Thunderbird is very fast. I looked for a way to increase the inactivity time in dovecot.conf but didn't see one. I don't know of any other user that has this problem, which makes me suspicious of her client rather than Dovecot. Pretty much everyone is using Thunderbird, although she's the only one using it on a Mac. Is it possible/likely that it takes so long because for some reason Thunderbird on a Mac doesn't notice that the second connection has died and is taking a long time trying to use the first invalid connection before reestablishment? Or is it likely that this is a Dovecot problem and I simply haven't figured out what's going on, yet? All help very much appreciated. Thanks, Jeff
Re: [Dovecot] Released ManageSieve v0.10.7 for Dovecot v1.1.17
On Sun, Jul 12, 2009 at 8:07 PM, Stephan Boschstep...@rename-it.nl wrote: Hello Dovecot users, This release is entirely composed of bug fixes, most of which were found and fixed earlier in the implementation for Dovecot v1.2. Great! Does anyone know if the actual sieve tarball for 1.1.16 works okay with 1.1.17? (There is no 1.1.17-specific version yet.) Thanks, Jeff
Re: [Dovecot] Released ManageSieve v0.10.7 for Dovecot v1.1.17
On Mon, Jul 13, 2009 at 2:50 PM, Stephan Boschstep...@rename-it.nl wrote: What do you mean? The CMUSieve version used for Dovecot v1.1.x is dovecot-sieve-1.1.6. This is a non-specific release that should (and does) work fine with the new 1.1.17 Dovecot release. This page on dovecot.org: http://dovecot.org/releases/sieve/ has tarballs that track the various Dovecot releases. So you can understand why I might wonder if the lack of a 1.1.17 means that 1.1.16 is okay :-) But good to know that it is. Thanks, Jeff
Re: [Dovecot] Released ManageSieve v0.10.7 for Dovecot v1.1.17
On Mon, Jul 13, 2009 at 4:03 PM, Stephan Boschstep...@rename-it.nl wrote: This page on dovecot.org: http://dovecot.org/releases/sieve/ has tarballs that track the various Dovecot releases. So you can understand why I might wonder if the lack of a 1.1.17 means that 1.1.16 is okay :-) Look closer. The version is 1.1.6 and not 1.1.16 :) Hrm. Apparently, I am not fully awake. Sorry for the noise. --Jeff
Re: [Dovecot] Apple patches 1-5
On Mon, Dec 15, 2008 at 12:39 PM, Mike Abbott michael.abb...@apple.com wrote: Patch #5. Required by Apple's lawyers. Patch 5 seems spurious to me, regardless of what Apple's lawyers want. Three of the four patches are working around bugs in Apple's own OS. Most are a few lines. Sending patches upstream are great, but in any project I've been a part of, these are not conditions under which someone gets to claim copyright, especially on something as elusive as portions. --Jeff
Re: [Dovecot] v1.1 plans - sieve?
Jorge Salamero Sanz wrote: On Wednesday 18 April 2007 00:13, Timo Sirainen wrote: I don't think so. I want to distribute it with Sieve plugin, and that pretty much requires changes that come only in v2.0. so what's the suggested setup for server-side mail filtering right now ? If you're a Horde fan, another way besides pysieved is to use the Dovecot sieve plugin and Horde's Ingo application. It takes a bit of work, but you can set it up so that when users create/modify filters within Horde, it writes out the appropriate Sieve file that the Dovecot plugin can parse. It makes for an easy GUI for filter rules that pretty much any user can figure out. Gentoo makes this easier since the sieve use flag causes the patch to be downloaded and compiled into Dovecot for you, so you only have to worry about the configuration, not getting and applying the patch. --Jeff
