similar to: Identify if a message_part is an attachment ?

hello list, testing the 2.18 release i got following core dump. Maybe Timo you can get a look at it. greetings dominik Core Dump: root at hbs-buko:/var/vmail/hbs-buko.info/dominik.breu# gdb /usr/lib/dovecot/imap core GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is

On 16 May 2015, at 11:28, Dominik Breu <dominik at dominikbreu.de> wrote: > > hello list, > > testing the 2.18 release i got following core dump. Maybe Timo you can > get a look at it. That's not v2.2.18 release though, it's the hg version after v2.2.18 release. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 imap_msgpart_contains_body

Hi! I'm currently experiencing a crash of dovecot 2.2.25 on Gentoo, upon opening mailbox. The crash only triggers on opening inbox, other mailboxes seem to work fine. It happens every time, and can be reproduced on request. I also briefly tried 2.2.19, and it behaves the same. The bug seems to be triggered by some mail, as I encountered it previously and fixed by removing some spam. I

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Usingt ./sbin/dovecot --version 2.2.rc2 (7a08461c5559) with Maildir, 2 FETCH 1 BODY.PEEK[ALL] dumps core, bt full is: #0 0x00007fa166e721b5 in raise () from /lib/libc.so.6 No symbol table info available. #1 0x00007fa166e74fc0 in abort () from /lib/libc.so.6 No symbol table info available. #2 0x00007fa16721ac47 in default_fatal_finish

Hi, I would like to report an issue which is 100% reproducible with a specific mail available in the reproducer attached to Red Hat's bugzilla <https://bugzilla.redhat.com/show_bug.cgi?id=1894418> (https://bugzilla.redhat.com/attachment.cgi?id=1726535): -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Return-Path: <XXXXXXXXX at

Hi, imap_msgpart_crlf_seek() returns an error stream in case of problems in message_skip_virtual(). The original input stream is not being unreferenced, preventing destroy callbacks from being executed. Shouldn't we have an i_stream_unref(&input) here: src/lib-imap-storage/imap-msgpart.c: 398 if (message_skip_virtual(input, virtual_skip, &cr_skipped) < 0) { 399

Hi Timo, I've got a crash with dovecot 2.2 dovecot --version 2.2.rc2 (69c26a9e3be5) It's occured when accessing with imap on a large mailbox (around 50k messages) imap(clean-quarantine at spamguard.fr): Panic: Buffer full (4254 > 4248, pool <none>) Error: Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(+0x6089a) [0x7f9d1bcde89a] -> /usr/lib/dovecot/libdovecot.so.0(+0x608de)

> > Is this behavior cured, or do you continue to see it? > No, the behavior isn't cured. We still continue to see it with various clients. I have posted a couple of truss outputs, but so far no resolution. Sorry for the slow response. I've been "fighting other fires". Jackie > Jackie Hunt wrote: > >> On Mon, 2007-09-03 at 12:37 +0200, Robert

Implements more verbose imap logging (when client exits). Similar to existing logging in POP3. Due to the nature of imap and my incomplete understanding (of the dovecot code) the session statistics reported have varying accuracy. Much better than nothing IMO. Cheers, Jens ----------------------------------------------------------------------- 'This mail automatically becomes portable

Hi, I have rewritten the patches I submitted earlier today for the CVS HEAD. Some of the changes were already committed months ago. On 2007/03/15 12:30, Timo Sirainen <tss at iki.fi> wrote: > That's ok, but I'm not sure about bsearch_insert_pos(). It's the way it > is mostly because I wanted to keep bsearch() API. If it can't return > void * then maybe it could be

http://dovecot.org/releases/2.2/dovecot-2.2.8.tar.gz http://dovecot.org/releases/2.2/dovecot-2.2.8.tar.gz.sig + Mail cache lookups work for the mail being saved. This improves performance by avoiding the need to parse the mail multiple times when using some plugins (e.g. mail_log). + Mail cache works for recently cached data also with in-memory indexes. + imapc: Many performance

http://dovecot.org/releases/2.2/dovecot-2.2.8.tar.gz http://dovecot.org/releases/2.2/dovecot-2.2.8.tar.gz.sig + Mail cache lookups work for the mail being saved. This improves performance by avoiding the need to parse the mail multiple times when using some plugins (e.g. mail_log). + Mail cache works for recently cached data also with in-memory indexes. + imapc: Many performance

Hi, I am trying dovecot-1.1 with dovecot-sieve-1.1. First, dovecot -n do not report about deliver settings. They are: --- protocol lda { postmaster_address = postmaster at parkheights.dyndns.org hostname = parkheights.dyndns.org mail_plugins = cmusieve mail_plugin_dir = /usr/lib64/dovecot11/modules/lda sendmail_path = /usr/lib/sendmail auth_socket_path = /var/run/dovecot11/auth-master

Hi again! After sometime using my changes on this plugin I found one major problem. When a message have two attachments with same name or one with content-type equal to "message/*", my solr schema design does not work because as attachment unique identifier I used attachment's name what is not correct. Now I am trying to find a way to know the mime part id of the parts

Hi, Two cores over the weekend, same assert message in syslog: imap(user): file message-body-search.c: line 393 (message_body_search_ctx): assertion failed: (input->v_offset <= part->physical_pos) Setup: Solaris 9, imap usage only, mbox format, dovecot compiled with gcc 4.0.1. gdb sessions of the two core files attached. Let me know if you need further analysis of the cores.

Panic: IMAP(user): file message-parser.c: line 684 (preparsed_parse_next_header_init): assertion failed: (ctx->part- >physical_pos >= ctx->input->v_offset) Linux 2.6.24-19-386 Maildir on ext3 Looks similar to but different from http://dovecot.org/list/dovecot/2008-June/031523.html . #0 0xb7faf410 in __kernel_vsyscall () #1 0xb7e6f085 in raise () from

Hi, My setup: Solaris 9, mbox format, mailboxes NFS mounted from another S9 system, imap. I got the following assert yesterday: Jan 30 19:57:15 emerald dovecot: [ID 107833 mail.error] imap(user): file index-mail-headers.c: line 258 (index_mail_parse_header): assertion failed: (part != NULL) Jan 30 19:57:16 emerald dovecot: [ID 107833 mail.error] imap(user): file index-mail-headers.c: line

Today I updated to current dovecot-1.1 hg tree and I got many of these assertion failures: file istream.c: line 303 (i_stream_read_data): assertion failed: (stream->stream_errno != 0) (gdb) bt full #0 0x00352402 in __kernel_vsyscall () No symbol table info available. #1 0x0043ed20 in raise () from /lib/libc.so.6 No symbol table info available. #2 0x00440631 in abort () from /lib/libc.so.6

Hi, My second case of this assert, gdb analysis of the core dump attached. My setup: Solaris 9, dovecot built with gcc 4.0.2, mbox format, imap usage only. INBOX is NFS mounted from another Solaris 9 system, index files are local. Syslog complaint is: imap(user): file message-body-search.c: line 414 (message_body_search_ctx): assertion failed: (input->v_offset == part->physical_pos +

Hi, Wow, I haven't had an assert/core in dovecot in a long time. Here goes: Setup: Solaris 10, dovecot built with gcc 4.1.1, imap and imaps only. User's home directory lives on a ZFS filesystem, but I don't think that makes a difference. So does every other user here (>3K). Assert: IMAP(mulepri): file message-body-search.c: line 393 (message_body_search_ctx): assertion failed: