Re: [Dovecot] backing up emails
Hi, this is the output of dovecot -n, backing up /home directory in the hard disk enough ? Thanks, Angelo # 1.1.4: /etc/dovecot/dovecot.conf log_timestamp: %Y-%m-%d %H:%M:%S protocols: imap imaps pop3 pop3s login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login mail_privileged_group: mail mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 auth default: passdb: driver: pam userdb: driver: passwd On Jun 27, 2010, at 11:13 AM, Henrique Fernandes wrote: > It depens where dovecot are storing the email! > > Do you know where is it ? > > > post the output of > > # dovecot -n > > []'sf.rique > > > On Sat, Jun 26, 2010 at 8:35 PM, Angelo Chen wrote: > hi, > > i have a ubuntu server running Dovecot imap, how to backup everybody's email? > rsync /home is enough? Thanks, > > Angelo >
Re: [Dovecot] Thunderbird problem
Charles Marcus put forth on 6/27/2010 11:37 AM: > I think what matters is that the number of connections that TB is > expecting to be able to use be *less* than the max supported by the IMAP > server. I do know that as soon as I changed the MAX number of > connections per IP in Courier to 5, all of our problems went away. When you get a chance fire up top and take a look at the CPU time used by each of the 5 imap processes associated with a given TB user. Four will be at zero or maybe one or 2 seconds. You'll see the vast majority of the CPU time is on the fifth imap process. This is exactly why I limit TB to one connection. My mildly educated guess is that the other 4 connections are being used strictly for IDLE processing, if at all. For me the additional 4 unused or rarely used connections isn't worth the additional overhead, even though said overhead isn't terribly high. Having 250 imap processes running on the system for 50 logged in users is something I just can't stand, given that 50 imap processes have no trouble servicing those same 50 users. Hopefully NOTIFY fixes all of this, and hopefully TB and Dovecot will support it before too long. As is, I'm more than happy with single connections and polling, and one imap process per user. The big downside to my setup? Users might have to wait up to 60 seconds for a new email notification. However, they don't know they waited 60 seconds, so what does it really matter? As far as they know it just now arrived. -- Stan
Re: [Dovecot] Thunderbird problem
Eduardo M KALINOWSKI put forth on 6/27/2010 6:22 AM: > On 06/27/2010 06:04 AM, Stan Hoeppner wrote: >> Regardless, my point is valid and stands: there is no (good) reason >> for the >> protocol to require multiple socket connections when everything can be >> accomplished more efficiently (in terms of resources consumed) over a single >> socket. I'm sure many people more qualified than me have pointed this out >> WRT >> the IMAP protocol over the years. >> > > Tomas is right. It's only possible to monitor one folder via IDLE per > IMAP connection. It's stupid and inefficient, but that's how IMAP IDLE > was designed. > > Fortunately, there's the NOTIFY extension to overcome that limitation. > But it's not supported in all clients (nor in all servers, I'd guess). Thankfully none of this is actually _required_ to get timely new mail notification. Polling isn't efficient either but at least it only requires one socket connection. -- Stan
[Dovecot] Compile error sieve plugin for dovecot2
Hello, I'm trying to compile the sieve plugin for dovecot2 Dovecot2-beta6 is allready running and working. i did a hg clone http://hg.renamie-it.nl/dovecot-2.0-pigeonhole and ran the autogen.sh script as mentioned in the INSTALL file configure options: /configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc --with-dovecot=/usr/lib/dovecot/ --with-managesieve=no compiling gives an error after a while: /bin/bash ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/include/dovecot -DMODULEDIR=\""/usr/lib/dovecot"\" -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -MT sieve-actions.lo -MD -MP -MF .deps/sieve-actions.Tpo -c -o sieve-actions.lo sieve-actions.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/include/dovecot -DMODULEDIR=\"/usr/lib/dovecot\" -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -MT sieve-actions.lo -MD -MP -MF deps/sieve-actions.Tpo -c sieve-actions.c -fPIC -DPIC -o .libs/sieve-actions.o sieve-actions.c: In function 'act_store_mailbox_open': sieve-actions.c:338: error: storage size of 'save_ctx' isn't known sieve-actions.c:355: warning: implicit declaration of function 'mail_deliver_save_open' sieve-actions.c:338: warning: unused variable 'save_ctx' make[4]: *** [sieve-actions.lo] Fehler 1 make[4]: Leaving directory `/usr/src/dovecot/dovecot-2.0-pigeonhole/src/lib-sieve' make[3]: *** [all-recursive] Fehler 1 make[3]: Leaving directory `/usr/src/dovecot/dovecot-2.0-pigeonhole/src/lib-sieve' make[2]: *** [all-recursive] Fehler 1 make[2]: Leaving directory `/usr/src/dovecot/dovecot-2.0-pigeonhole/src' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/usr/src/dovecot/dovecot-2.0-pigeonhole' make: *** [all] Fehler 2 am i missing something? further information can be provided. dovecot2 was configured with prefix/sysconfdir/localstatedir as above it doesnt make any differences if i change --with-dovecot to the local sources directory thanks in advance Christian Kivalo
Re: [Dovecot] Thunderbird problem
On 2010-06-25 11:02 PM, Stan Hoeppner wrote: > This is a pet peeve of mine. Recent TB revs default to opening 5 > IMAP connections. It's default has been 5 connections since for as long as I can remember that option being there, and we've been using TB exclusively in our office since about version 0.9... > Some time ago I did more than cursory testing and found that TBird > only uses 1 of the 5. The other 4 just sit there idle, adding > clutter to the process list and eating a small amount of RAM. I don't think this is accurate... I say this because I recall a problem a long time ago where I had to decide between lowering the number of TB connections, or raising the max per IP for the Courier IMAP server we were using at the time - I chose the latter (change it in one place rather than many dozens)... http://kb.mozillazine.org/IMAP:_advanced_account_configuration > Anyway, since testing I force all my user TBird configs to a single > IMAP connection. No problems. Whether or not this will work depends on the environment... I think what matters is that the number of connections that TB is expecting to be able to use be *less* than the max supported by the IMAP server. I do know that as soon as I changed the MAX number of connections per IP in Courier to 5, all of our problems went away. -- Best regards, Charles
Re: [Dovecot] Thunderbird problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Jun 27, 2010 at 04:04:39AM -0500, Stan Hoeppner wrote: > to...@tuxteam.de put forth on 6/26/2010 11:52 PM: > > > The references are spot-on. The IDLE command is just designed to notify > > changes to the *selected* mailbox [...] > None of this is laid out in RFC2177. Maybe not explicitly. But have you looked at 2177? The way it works is thus: (1) client says SELECT (2) server says OK (among other things) (3) client says IDLE (4) server says + (meaning: I'm waiting for more) (5) now connection is quiescent until: (6) either server says EXISTS (or EXPUNGE) (7) client ends IDLE with DONE Note that at step 7 in this example scenario, server has *no way to say to which mailbox this EXISTS refers to*. It mus refer to the selected mailbox and just to that. That means that the way IDLE is specified, only notofications referring to one mailbox can be received. > None of the relevant things we're discussing are in RFC2177 anyway. See above: RFC2177 tells us: "one connection per mailbox", and... > They're > in RFC3501, which is rather lengthy. ...RFC3501 tries to fix exactly that. > Regardless, my point is valid and stands: there is no (good) reason for the > protocol to require multiple socket connections when everything can be > accomplished more efficiently (in terms of resources consumed) over a single > socket. Well, that's the point of IMAP NOTIFY in RC3501. If this extension is implemented, one socket will suffice to receive notifications concerning several mailboxes. As long as we don't have that, clients will work around the limitations of NOTIFY by opening several connections. That's what Patrick was saying upthread: "Or even better: IMAP NOTIFY [2] gets implemented in dovecot and in Thunderbird, and one TCP connection suffices for an arbitrary amount of "push" folders :)" > I'm sure many people more qualified than me have pointed this out WRT > the IMAP protocol over the years. I don't exactly know what you mean by "this". Before the IDLE extension, there was no (portable) way to get notifications via IMAP at all: clients had to poll. After the IDLE extension, there's just one mailbox per connection (no way to argue around that: the protocol is just designed this way) the client gets nudged. As this was seen as a limitation, now there's IMAP NOTIFY, which just does what you ordered. Now to convince client and server implementors to use it :-) Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMJ1mMBcgs9XrR2kYRAs0JAJ0b7vmolytQgw8xAk/lLO+HZ5SqdgCcCh0D wjqLKE/nWpTzfvcjpIh/OLM= =p4Jd -END PGP SIGNATURE-
[Dovecot] dovecot 2.0.beta6 dies when I try to delete a folder with thunderbird
When I try to delete a folder with Thunderbird 3.1 I get the following
log entry and the folder is not deleted. Filesystem is ZFS.
Jun 27 15:32:36 azati dovecot: [ID 583609 mail.error] master: Error:
service(imap): child 18215 killed with signal 11 (core not dumped -
set drop_priv_before_exec=yes)
Jun 27 15:32:36 azati dovecot: [ID 583609 mail.error] master: Error:
service(imap): child 18213 killed with signal 11 (core not dumped -
set drop_priv_before_exec=yes)
# 2.0.beta6: /etc/opt/dovecot/dovecot/dovecot.conf
# OS: SunOS 5.10 i86pc zfs
first_valid_uid = 100
mail_location = mdbox:/l/dovecot/%u/dbox
namespace {
inbox = yes
location =
prefix =
separator = /
type = private
}
passdb {
driver = pam
}
protocols = imap
service imap-login {
inet_listener imap {
port = 0
}
}
service imap {
vsz_limit = 1073741824
}
ssl = required
ssl_cert =
Re: [Dovecot] Thunderbird problem
On 06/27/2010 06:04 AM, Stan Hoeppner wrote: > Regardless, my point is valid and stands: there is no (good) reason > for the > protocol to require multiple socket connections when everything can be > accomplished more efficiently (in terms of resources consumed) over a single > socket. I'm sure many people more qualified than me have pointed this out WRT > the IMAP protocol over the years. > Tomas is right. It's only possible to monitor one folder via IDLE per IMAP connection. It's stupid and inefficient, but that's how IMAP IDLE was designed. Fortunately, there's the NOTIFY extension to overcome that limitation. But it's not supported in all clients (nor in all servers, I'd guess). -- A visit to a strange place will bring fresh work. Eduardo M KALINOWSKI edua...@kalinowski.com.br
Re: [Dovecot] Thunderbird problem
to...@tuxteam.de put forth on 6/26/2010 11:52 PM: > The references are spot-on. The IDLE command is just designed to notify > changes to the *selected* mailbox. And a client can have just one > selected mailbox (per-connection, that is). That's simply a limitation > of the protocol. Clients may work around this by opening several > connections and selecting one mailbox per connection. None of this is laid out in RFC2177. > And refusing to read 130 lines of RFC (the first one, describing IDLE is > really that short) to just say "meh, I don't believe you" doesn't sound > really appropriate. None of the relevant things we're discussing are in RFC2177 anyway. They're in RFC3501, which is rather lengthy. Regardless, my point is valid and stands: there is no (good) reason for the protocol to require multiple socket connections when everything can be accomplished more efficiently (in terms of resources consumed) over a single socket. I'm sure many people more qualified than me have pointed this out WRT the IMAP protocol over the years. -- Stan
