Re: [Dovecot] push mail support
Hello Thomas, Thursday, April 8, 2010, 10:05:06 AM, you wrote: > On Thu, Apr 08, 2010 at 01:35:41AM +0300, Ibrahim Harrani wrote: >> I would like to use push in qmail+dovecot environments. Can someone tell me >> which components >> should I use to enable this feature for mobile devices? > this works fine with mobile clients that support IMAP IDLE. Using it with > K-9 on Android devices and it works like a charm. I second that, IMAP IDLE is the standard way of achieving push email functionality. Your client needs to support it but vast majority does these days. And in fact k9mail on Android works great (really!) for me, too. -- Best regards, Robert Tomanek mailto:dove...@mail.robert.tomanek.org
Re: [Dovecot] Security Hole in 1.0.13?
Hello Lawrence, Sunday, May 18, 2008, 9:19:40 AM, you wrote: > I'll do the rest offlist. Please don't. Finding out it wasn't your Dovecot installation that was compromised is valuable information here (as is the opposite, of course). -- Best regards, Robert Tomanekmailto:[EMAIL PROTECTED]
Re: [Dovecot] Virtual mailboxes
Hello Timo, Friday, March 14, 2008, 11:21:47 AM, you wrote: > Virtual mailbox support can be tested with: > hg clone http://hg.dovecot.org/dovecot-virtualboxes/ Thanks Timo, this is excellent news! I'd love to test it straight away but I can't really touch my mail server setup now -- will definitely do it some time in the future. Speaking of which, this branch will not make it into 1.1, will it? -- Best regards, Robert Tomanekmailto:[EMAIL PROTECTED]
Re: [Dovecot] Sieve doesnt filter
Hello Sven,
Monday, March 10, 2008, 5:17:58 PM, you wrote:
> require "fileinto";
> if address :domain :is "to" "domain.de" {
> if header :matches "X-Spam-Level" "\\*\\*\\*\\*\\*\\*\\*\\*" {
> #discard;
> fileinto "spamdir";
> }
> }
I vaguely remembers having problems with using regular expressions;
how about using ":contains" instead of ":matches"?
For the record, here's a .dovecot.sieve for one of my accounts:
-
require ["fileinto", "imapflags"];
if header :contains "X-Spam-Checked-By" "myhostid" {
if header :contains "X-Spam-Level" "**" {
if header :contains "X-Spam-Level" "" {
setflag "\\Seen";
}
fileinto "Junk";
stop;
}
} elsif allof (
header :contains "Subject" "Undelivered Mail Returned To Sender",
address :is "From" "[EMAIL PROTECTED]"
) {
fileinto "INBOX.Undelivered";
} else {
keep;
}
-
--
Best regards,
Robert Tomanek [EMAIL PROTECTED]
Re: [Dovecot] [OT] Webmail Recommendation
Hello Peter, Thursday, January 10, 2008, 8:17:15 PM, you wrote: > All the suggested ones have just one big FAT problem - they are all > written in that security bug ridden language that the hackers just love > to exploit - PHP. Running a web application available to the whole wide > internet written in PHP is just asking for someone to break into your > systems. That's pretty much off-topic but for anyone interested just in web mail systems and less so in holy wars & stuff: don't worry, it is not that bad. It is not bad at all, actually :) > I _really_ _really_ wish someone would write a nice webmail > system in some other language... Like a Ruby-on-Rails one (I've > found a few, but they aren't actively maintained anymore). Hadn't you mentioned specifically RoR (or any other of the buzzwords/ newcomings) I'd have taken your opinion as a warning (aggresively voiced, but still a warning about security -- a useful thing to have). What you've written, however, is pretty unbalanced. You made it difficult to consider it 'useful' or 'informative'. It is more of misinformation than information. But let's not discuss it here, it's Dovecot list. -- Best regards, Robert Tomanek mailto:[EMAIL PROTECTED]
Re: [Dovecot] Webmail Recommendation
Hello Peter, Wednesday, January 10, 2007, 6:41:46 PM, you wrote: > I want to install webmail. I am using Dovecot with Exim4. > Recommendations requested please. I can confirm RoundCube ( http://www.roundcube.net/ ) is a good recommendation. Don't get discouraged by the early beta version numbers, it is quite usable indeed. The focus is not on multitude of features but rather on general usability and interface sleekness. It looks good and it feels good. See for yourself. It is very easy to install and configure. -- Best regards, Robert Tomanek mailto:[EMAIL PROTECTED]
[Dovecot] Keywords (labels) support via virtual folders
Hi all, while I am rather a beginner when it comes to IMAP, I was thinking whether it would be possible (and feasible) to implement setting and unsetting of IMAP keywords with the means of virtual folders in Dovecot. The background is that the IMAP keywords seem to be a very useful thing to me: I would often like to be able to 'tag' a message so that it is easy to group with other similar messages and easy to find/ browse later. The problem is that not all IMAP clients support this functionality (as far as I am aware, mine which happens to be The Bat! does not); the only way of achieving similar results is using regular folders for grouping messages but this has several disadvantages, the most prominent one being unable to assign more than one 'tag' to a message this way (without copying a message). What I am thinking of is a server-side 'helper' that intends to achieve functionality similar to native client keywords support by the means of providing 'virtual folders' (as opposed to regular folders that we've known for a long time). The server would expose a list of virtual folders (user defined, either server-side by modifying the configuration, or client-side, by using the existing 'create regular folder' folder functionality but using a special name format that would be recognized by the server to be virtual folder related). These virtual folders would, upon moving a message to them, apply a keyword to the message (but the message would not be moved as it would be the case with regular folders). Upon moving a message from a virtual folder, the keyword would be reset. This means that the messages would not normally be moved from their place in existing hard folder structure but they would additionally be flagged with a keyword (or more of them) and be visible in respective virtual folders. The result is: - keywords support for clients that do not natively support it, - leaving existing message folder structure intact, - support for multiple keywords/ labels per message (one virtual folder = one keyword), - browsing flagged messages via respective virtual folders. What do you think of it? While I've been toying with this and similar ideas for a long time, what I propose above is of course heavily influenced by the recent addition of IMAP access to Gmail ([1]). While I still do not have it enabled for my account, I presume this is how the Gmail labels get translated to IMAP client ([2], [3]). [1] https://mail.google.com/support/bin/topic.py?topic=12760 [2] https://mail.google.com/support/bin/answer.py?answer=77657&topic=12762 [3] https://mail.google.com/support/bin/answer.py?answer=78758&topic=12762 -- Best regards, Robert Tomanek mailto:[EMAIL PROTECTED]
Re: [Dovecot] Subaddress Extension in sieve plugin
Hi, Wednesday, September 26, 2007, 15:02:06, you wrote: > With many MTAs it is possible to use a special form of adressing: > subaddresses or "plussed > addresses". > In a sieve filter you can analyse these special detail values, the syntax is > described in > RFC3598 (http://tools.ietf.org/html/rfc3598). > The current deliver with sieve plugin for dovecot seems to support this RFC, > but has the > detail information not available. > I did not analyse the problem very deep, but I believe we should introduce a > new command > line parameter for deliver, so deliver can pass the detail > information to the sieve plugin. While I am no expert on this (I have just started using sieve filters and Dovecot deliver) it definitely looks tempting to me. I'd be glad to see it (or an equivalent implementation) in Dovecot. -- Best regards, Robert Tomanek mailto:[EMAIL PROTECTED]
Re: [Dovecot] IMAP: Disconnected: BUG: Unknown internal error (Dovecot 1.0.3)
Hello Timo, Saturday, September 22, 2007, 16:23:57, you wrote: > On Sun, 2007-09-02 at 20:24 +0200, Robert Tomanek wrote: >> > C: U00331 UID FETCH 18238 (INTERNALDATE FLAGS RFC822.HEADER) >> > S: * BYE BUG: Unknown internal error > This should fix it: http://hg.dovecot.org/dovecot-1.0/rev/a3300666c111 Running a patched version of 1.0.5 since yesterday, so far so good... Thanks! -- Best regards, Robert Tomanek mailto:[EMAIL PROTECTED]
Re: [Dovecot] imap process consuming 100% CPU (Dovecot 1.0.3)
Hi,
Saturday, September 8, 2007, 2:29:45, you wrote:
>> >> 0x0806049d in imap_sync_more (ctx=0x80d9770) at imap-sync.c:104
>> >> 104 if (ctx->seq == 0) {
>>
>> A short follow-up on this, looks like an infinite loop to me, unless
>> some threading magic is supposed to happen here:
> Fixed: http://hg.dovecot.org/dovecot-1.0/rev/8e86137a04fb
Compiled the new version, so far so good...
Thanks!
--
Best regards,
Robert Tomanekmailto:[EMAIL PROTECTED]
Re: [Dovecot] IMAP: Disconnected: BUG: Unknown internal error (Dovecot 1.0.x)
Hi, Monday, September 3, 2007, 23:16:07, you wrote: > One more piece of info that might (?) be interesting -- I have just > run a grep on historical logs and it seems the bug never occured on > previous versions of Dovecot I had been running in the past (first > it was stock Suse 9.3 Dovecot 0.99.14, then a self-compiled > 1.0.rc27). > The only difference (apart from the actual source code, of course) > between 1.0.rc27 and the current 1.0.3 that might play any role are > the configure flags: > - 1.0.rc27: ./configure --with-pam > - 1.0.3 : ./configure --with-ioloop=best --with-ldap --with-sql > --with-mysql --with-pam > This resulted in using epoll() for 1.0.3 and poll() for 1.0.rc27; > both versions are using dnotify. OK, I am now positive this has nothing to do with epoll() vs. poll() (which was unlikely anyway but I wanted to test it just in case). I have just compiled 1.0.5 with poll() -- which means that its config and compilation options are pretty much the same as with the previous versions -- and the bug occurs again, just as it did with 1.0.3/epoll(). Looking at the backtrace and the code, it seems imap_fetch_deinit() is failing. -- Best regards, Robert Tomanekmailto:[EMAIL PROTECTED]
Re: [Dovecot] imap process consuming 100% CPU (Dovecot 1.0.3)
Hello Jackie, Friday, September 7, 2007, 7:47:59 PM, you wrote: >> Jackie, is there a chance you could confirm my doubts by doing what >> I did in and the >> original message? This way we would be sure we are talking about the >> same problem cause here since 'Dovecot hangs' sounds a bit generic. >> I think the stack trace and the variable values should be enough to >> confirm it. > Sorry, don't know about the mid: protocol. Not sure how to get to the > reference you sent. From your email it looks like gdb has the ability > to attach to a running process. We have dbx which I don't believe > can do that. It would be nice to confirm our issues are the same though. > What I'd really like is to find a way to recreate the problem. Sorry for being unclear -- mid is simply a Message-Id (my e-mail client supports directly referencing messages this way; in any case, it's a part of message headers so you can uniquely identify a message this way). In this case, I meant my message sent on 2007-09-03 12:37 where I pasted the debug session and my suspicions about the infinite loop. Recreating the problem would be great, I hope you will be more successful than I am -- no idea so far. Should be easier for you since you probably have more users with real-life e-mail usage scenarios. Let us know if you get any progress here. As for debugging, Brian (see previous e-mail in thread) mentioned attaching to a process is similar with dbx. I've never used dbx but a quick search in Google suggests it is pretty easy to use and similar to gdb. Your mileage may vary, though :) -- Best regards, Robert Tomanek mailto:[EMAIL PROTECTED]
Re: [Dovecot] imap process consuming 100% CPU (Dovecot 1.0.3)
Hello Jackie, Thursday, September 6, 2007, 21:09:48, you wrote: >> I have yet another problem with Dovecot: sometimes (rarely, maybe >> once every few days) one of the imap processes will 'hang', >> consuming all available CPU time. It does not seem to 'finish' in any >> reasonable amount of time (in one instance I waited a few days). > We have also seen this behavior, running Dovecot 1.0 on AIX. > Thanks for your debug work on it Robert. Unfortunately, I am not really moving forward with that as I do not have much insight into the context structure in question. I guess we need to wait until Timo answers my e-mail. On the other hand, nice the hear I am not the only person with this problem :-| Jackie, is there a chance you could confirm my doubts by doing what I did in and the original message? This way we would be sure we are talking about the same problem cause here since 'Dovecot hangs' sounds a bit generic. I think the stack trace and the variable values should be enough to confirm it. -- Best regards, Robert Tomanek mailto:[EMAIL PROTECTED]
Re: [Dovecot] IMAP: Disconnected: BUG: Unknown internal error (Dovecot 1.0.3)
Hi,
Sunday, September 2, 2007, 20:24:04, you wrote:
> I am getting the following error in the server mail logfile:
>> Sep 2 18:39:44 h648123 dovecot: IMAP()(): Disconnected: BUG:
>> Unknown internal error
> I am running Dovecot 1.0.3 (compiled from sources) on Suse 9.3.
I did one more thing: using gdb I attached to all 'imap' processes
and set a breakpoint at the only place in the code where "Unknown
internal error" appears (that is 'index_storage_get_last_error' in
lib-storage/index/index-storage.c) in order to get backtrace for it
(which may or may not help). See for yourselves:
> (gdb) break index-storage.c:452
> Breakpoint 1 at 0x807eec7: file index-storage.c, line 452.
> (gdb) continue
> Continuing.
>
> Breakpoint 1, index_storage_get_last_error (storage=0x80cca90,
> syntax_error_r=0x0, temporary_error_r=0xb8ef)
> at index-storage.c:452
> 452 *temporary_error_r = TRUE;
> (gdb) bt full
> #0 index_storage_get_last_error (storage=0x80cca90, syntax_error_r=0x0,
> temporary_error_r=0xb8ef)
> at index-storage.c:452
> No locals.
> #1 0x08097765 in mail_storage_get_last_error (storage=0x0,
> syntax_error_r=0xb8ee, temporary_error_r=0xb8ef)
> at mail-storage.c:345
> No locals.
> #2 0x080573b1 in cmd_fetch_finish (ctx=) at
> cmd-fetch.c:90
> storage = (struct mail_storage *) 0x80cca90
> error =
> syntax = false
> temporary_error = 8
> cmd = (struct client_command_context *) 0x80ccdbc
> ok_message = 0x80b395b "OK Fetch completed."
> #3 0x08057623 in cmd_fetch (cmd=0x80ccdbc) at cmd-fetch.c:173
> client = (struct client *) 0x80ccd78
> ctx = (struct imap_fetch_context *) 0x80cf010
> args =
> search_arg = (struct mail_search_arg *) 0x80cefd8
> messageset =
> ret =
> #4 0x0805a0de in cmd_uid (cmd=0x80ccdbc) at cmd-uid.c:19
> cmd_name = 0x80cd078 "FETCH"
> #5 0x0805a616 in client_handle_input (cmd=0x80ccdbc) at client.c:335
> client = (struct client *) 0x80ccd78
> #6 0x0805a73a in client_handle_input (cmd=0x80ccdbc) at client.c:389
> client = (struct client *) 0x80ccd78
> #7 0x0805ac4c in _client_input (context=0x80ccd78) at client.c:432
> client = (struct client *) 0x80ccd78
> cmd = (struct client_command_context *) 0x80ccdbc
> ret = 2
> #8 0x080aa441 in io_loop_handler_run (ioloop=0x80cb9b0) at ioloop-epoll.c:203
> ctx = (struct ioloop_handler_context *) 0x80cb9d8
> list = (struct io_list *) 0x80ccf48
> io = (struct io *) 0x80ccf28
> tv = {tv_sec = 0, tv_usec = 927459}
> events_count = 4
> t_id = 2
> msecs =
> ret = 1
> i = 0
> j = 0
> call =
> #9 0x080a9889 in io_loop_run (ioloop=0x80cb9b0) at ioloop.c:329
> No locals.
> #10 0x08062087 in main (argc=1, argv=0xbaf4, envp=0xbafc) at
> main.c:290
> plugin_dir =
Any thoughts here?
One more piece of info that might (?) be interesting -- I have just
run a grep on historical logs and it seems the bug never occured on
previous versions of Dovecot I had been running in the past (first
it was stock Suse 9.3 Dovecot 0.99.14, then a self-compiled
1.0.rc27).
The only difference (apart from the actual source code, of course)
between 1.0.rc27 and the current 1.0.3 that might play any role are
the configure flags:
- 1.0.rc27: ./configure --with-pam
- 1.0.3 : ./configure --with-ioloop=best --with-ldap --with-sql
--with-mysql --with-pam
This resulted in using epoll() for 1.0.3 and poll() for 1.0.rc27;
both versions are using dnotify.
BTW, 'uname -a' returns:
Linux h648123 2.6.11.4-21.9-default #1 Fri Aug 19 11:58:59 UTC 2005 i686
athlon i386 GNU/Linux
--
Best regards,
Robert Tomanek mailto:[EMAIL PROTECTED]
Re: [Dovecot] imap process consuming 100% CPU (Dovecot 1.0.3)
Hi,
Sunday, September 2, 2007, 22:42:37, you wrote:
>> 0x0806049d in imap_sync_more (ctx=0x80d9770) at imap-sync.c:104
>> 104 if (ctx->seq == 0) {
A short follow-up on this, looks like an infinite loop to me, unless
some threading magic is supposed to happen here:
> (gdb) step
> 120 if (ctx->sync_rec.seq1 > ctx->messages_count)
> (gdb)
> 104 if (ctx->seq == 0) {
> (gdb)
> 117 if (ctx->sync_rec.seq2 > ctx->messages_count) {
> (gdb)
> 120 if (ctx->sync_rec.seq1 > ctx->messages_count)
> (gdb)
> 104 if (ctx->seq == 0) {
> (gdb)
> 117 if (ctx->sync_rec.seq2 > ctx->messages_count) {
> (gdb)
> 120 if (ctx->sync_rec.seq1 > ctx->messages_count)
> (gdb) print ctx->seq
> $1 = 8317
> (gdb) print ctx->sync_rec.seq1
> $2 = 8318
> (gdb) print ctx->sync_rec.seq2
> $3 = 8320
> (gdb) print ctx->messages_count
> $4 = 8317
The corresponding code in imap-sync.c is:
103:for (;;) {
104:if (ctx->seq == 0) {
105:/* get next one */
106:ret = mailbox_sync_next(ctx->sync_ctx,
107:&ctx->sync_rec);
108:if (ret <= 0) {
109:if (ret == 0) {
110:/* all finished ok */
111:ret = 1;
112:}
113:break;
114:}
115:}
116:
117: if (ctx->sync_rec.seq2 > ctx->messages_count) {
118:/* don't send change notifications of messages we
119: haven't even announced to client yet */
120:if (ctx->sync_rec.seq1 > ctx->messages_count)
121:continue;
122:ctx->sync_rec.seq2 = ctx->messages_count;
123:}
...
185:}
--
Best regards,
Robert Tomanek mailto:[EMAIL PROTECTED]
[Dovecot] imap process consuming 100% CPU (Dovecot 1.0.3)
Hi,
I have yet another problem with Dovecot: sometimes (rarely, maybe
once every few days) one of the imap processes will 'hang',
consuming all available CPU time. It does not seem to 'finish' in any
reasonable amount of time (in one instance I waited a few days). This
process will not even exit gracefully, it needs to be killed with
'kill -9 '.
It has just happened again. The output from gdb is:
> # gdb attach 29401
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i586-suse-linux"...attach: No such file or
> directory.
>
> Attaching to process 29401
> Reading symbols from /usr/local/libexec/dovecot/imap...done.
> Using host libthread_db library "/lib/tls/libthread_db.so.1".
> Reading symbols from /lib/libdl.so.2...done.
> Loaded symbols for /lib/libdl.so.2
> Reading symbols from /lib/tls/libc.so.6...done.
> Loaded symbols for /lib/tls/libc.so.6
> Reading symbols from /lib/ld-linux.so.2...done.
> Loaded symbols for /lib/ld-linux.so.2
> 0x0806049d in imap_sync_more (ctx=0x80d9770) at imap-sync.c:104
> 104 if (ctx->seq == 0) {
> (gdb) bt full
> #0 0x0806049d in imap_sync_more (ctx=0x80d9770) at imap-sync.c:104
> flags = 1075042320
> keywords =
> str = (string_t *) 0x80c31e0
> ret = 1
> #1 0x08060797 in cmd_sync_continue (cmd=0x80ccdbc) at imap-sync.c:207
> ctx = (struct cmd_sync_context *) 0x80cf000
> ret =
> #2 0x0805ad5a in _client_output (context=0x80ccd78) at client.c:465
> cmd = (struct client_command_context *) 0x80ccdbc
> ret = 0
> #3 0x080af0bd in stream_send_io (context=0x80cceb0) at ostream-file.c:356
> ostream = (struct ostream *) 0x80ccee0
> ret =
> #4 0x080aa441 in io_loop_handler_run (ioloop=0x80cb9b0) at ioloop-epoll.c:203
> ctx = (struct ioloop_handler_context *) 0x80cb9d8
> list = (struct io_list *) 0x80d7780
> io = (struct io *) 0x80dc430
> tv = {tv_sec = 2, tv_usec = 540048}
> events_count = 4
> t_id = 2
> msecs =
> ret = 1
> i = 0
> j = 1
> call =
> #5 0x080a9889 in io_loop_run (ioloop=0x80cb9b0) at ioloop.c:329
> No locals.
> #6 0x08062087 in main (argc=1, argv=0xbaf4, envp=0xbafc) at
> main.c:290
> plugin_dir =
Mail log does not reveal anything immediately interesting.
Thoughts?
Server config ('dovecot -n -c /etc/dovecot/dovecot.conf'):
> # 1.0.3: /etc/dovecot/dovecot.conf
> base_dir: /var/run/dovecot/
> protocols: imap imaps pop3 pop3s
> ssl_ca_file: /etc/ssl/current/cacert.pem
> ssl_cert_file: /etc/ssl/current/server.pem
> ssl_key_file: /etc/ssl/current/private.pem
> disable_plaintext_auth: no
> login_dir: /var/run/dovecot//login
> login_executable(default): /usr/local/libexec/dovecot/imap-login
> login_executable(imap): /usr/local/libexec/dovecot/imap-login
> login_executable(pop3): /usr/local/libexec/dovecot/pop3-login
> first_valid_uid: 50
> mail_debug: yes
> mail_drop_priv_before_exec: yes
> mail_executable(default): /usr/local/libexec/dovecot/imap
> mail_executable(imap): /usr/local/libexec/dovecot/imap
> mail_executable(pop3): /usr/local/libexec/dovecot/pop3
> mail_plugin_dir(default): /usr/local/lib/dovecot/imap
> mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
> mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3
> mail_log_prefix: %Us(%u)(%p):
> pop3_uidl_format(default):
> pop3_uidl_format(imap):
> pop3_uidl_format(pop3): %08Xu%08Xv
> auth default:
> debug_passwords: yes
> passdb:
> driver: passwd-file
> args: /etc/dovecot/passwd
> userdb:
> driver: passwd-file
> args: /etc/dovecot/passwd
> socket:
> type: listen
> client:
> path: /var/spool/postfix/private/auth
> mode: 432
> user: postfix
> group: postfix
--
Best regards,
Robert Tomanek mailto:[EMAIL PROTECTED]
[Dovecot] IMAP: Disconnected: BUG: Unknown internal error (Dovecot 1.0.3)
Hi,
I am getting the following error in the server mail logfile:
> Sep 2 18:39:44 h648123 dovecot: IMAP()(): Disconnected: BUG:
> Unknown internal error
(mail_debug is on, but there is not really much context for this in
the log file, ie. no log events for several minutes, and then it
appears, all of a sudden).
On the client side, it looks like this (with some context in case it
matters; no exact times though, sorry):
> [...]
> S: * 17699 FETCH (UID 18226 FLAGS (\Seen))
> S: * 17700 FETCH (UID 18227 FLAGS (\Seen))
> S: * 17701 FETCH (UID 18228 FLAGS (\Seen))
> S: * 17702 FETCH (UID 18229 FLAGS (\Seen))
> S: * 17703 FETCH (UID 18230 FLAGS (\Seen))
> S: * 17704 FETCH (UID 18231 FLAGS (\Seen))
> S: * 17705 FETCH (UID 18232 FLAGS (\Seen))
> S: * 17706 FETCH (UID 18233 FLAGS (\Seen))
> S: * 17707 FETCH (UID 18234 FLAGS (\Seen))
> S: * 17708 FETCH (UID 18235 FLAGS (\Seen))
> S: * 17711 EXISTS
> S: * 1 RECENT
> S: U00328 OK Fetch completed.
> C: U00329 UID FETCH 18238:* (UID RFC822.SIZE ENVELOPE BODYSTRUCTURE
> INTERNALDATE FLAGS)
> S: * 17711 FETCH (UID 18238 RFC822.SIZE 0 INTERNALDATE "01-01-1970 00:00:00
> +" FLAGS (\Seen \Recent) ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL
> NIL) BODYSTRUCTURE ("text" "plain" NIL NIL NIL "7bit" 0 0 NIL NIL NIL NIL NIL
> NIL NIL))
> S: U00329 OK Fetch completed.
> C: U00330 UID FETCH 18238 (INTERNALDATE FLAGS)
> C: U00331 UID FETCH 18238 (INTERNALDATE FLAGS RFC822.HEADER)
> S: )
> S: !! Empty response received
> S: * BYE BUG: Unknown internal error
> S: !! Socket status 0
>
>
> *** Session finished : 2007-09-02 18:39:50, 18:39:50
It occurs relatively often (several times a day), under no specific
conditions (sometimes it is hours after the session was started,
sometimes it is at the beginning -- really, nothing regular here).
The client connection is simply closed.
I am not getting a core dump for this; I am not sure whether I am
supposed to. I configured Dovecot according to the instructions at
http://www.dovecot.org/bugreport.html and core dumps generally work
on my system, eg. I can force one using 'kill -s SIGSEGV '
(where is a PID of one of the imap processes).
What do I do with it?
I am running Dovecot 1.0.3 (compiled from sources) on Suse 9.3. The
client is The Bat! 3.99.x Professional. Client is allowed to open
several concurrent connections to the IMAP server.
Server config ('dovecot -n -c /etc/dovecot/dovecot.conf'):
> # 1.0.3: /etc/dovecot/dovecot.conf
> base_dir: /var/run/dovecot/
> protocols: imap imaps pop3 pop3s
> ssl_ca_file: /etc/ssl/current/cacert.pem
> ssl_cert_file: /etc/ssl/current/server.pem
> ssl_key_file: /etc/ssl/current/private.pem
> disable_plaintext_auth: no
> login_dir: /var/run/dovecot//login
> login_executable(default): /usr/local/libexec/dovecot/imap-login
> login_executable(imap): /usr/local/libexec/dovecot/imap-login
> login_executable(pop3): /usr/local/libexec/dovecot/pop3-login
> first_valid_uid: 50
> mail_debug: yes
> mail_drop_priv_before_exec: yes
> mail_executable(default): /usr/local/libexec/dovecot/imap
> mail_executable(imap): /usr/local/libexec/dovecot/imap
> mail_executable(pop3): /usr/local/libexec/dovecot/pop3
> mail_plugin_dir(default): /usr/local/lib/dovecot/imap
> mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
> mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3
> mail_log_prefix: %Us(%u)(%p):
> pop3_uidl_format(default):
> pop3_uidl_format(imap):
> pop3_uidl_format(pop3): %08Xu%08Xv
> auth default:
> debug_passwords: yes
> passdb:
> driver: passwd-file
> args: /etc/dovecot/passwd
> userdb:
> driver: passwd-file
> args: /etc/dovecot/passwd
> socket:
> type: listen
> client:
> path: /var/spool/postfix/private/auth
> mode: 432
> user: postfix
> group: postfix
--
Best regards,
Robert Tomanek mailto:[EMAIL PROTECTED]
