similar to: dovecot-1.1.rc3 segmentation fault in fetch_bodystructure

Hi, I have a lot of errors like this in my log: Fatal: master: service(imap): child 26049 killed with signal 11 (core dumped) Dovecot 2.2.18 build from sources ./configure --prefix=/opt/dovecot2 --with-mysql --with-sqlite --with-solr --with-ssl --disable-rpath --disable-static. Debian Wheezy 3.2.63-2 x86_64. Filesystem is ZFS. All the core files are similar: $ gdb

Hi, I have a lot of errors like this in my log: Fatal: master: service(imap): child 26049 killed with signal 11 (core dumped) Dovecot 2.2.18 build from sources ./configure --prefix=/opt/dovecot2 --with-mysql --with-sqlite --with-solr --with-ssl --disable-rpath --disable-static. Debian Wheezy 3.2.63-2 x86_64. Filesystem is ZFS. All the core files are similar: $ gdb

Hi, Today's core dump from 1.0alpha1 came from a syslog message of: IMAP(user): pool_data_stack_realloc(): stack frame changed gdb info on the resulting core dump attached. Question: how many people are building/using dovecot 1.0alpha1 with gcc 4.0.1 versus gcc 3.4.x? I am wondering if these issues come from the compiler instead of dovecot itself? Jeff Earickson Colby College

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

This is 1.0.13, the processes crashed a few seconds apart from each other: GNU gdb 6.7.1-debian Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show

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

On Mon, Mar 13, 2023 at 11:01:35AM +0200, Timo Sirainen wrote: > On 12. Mar 2023, at 20.17, Patrick Mansfield <patmans at yahoo.com> wrote: > > > > Mar 12 10:32:27 goffin dovecot[8269]: imap(patman)<8452><r+ynYLf2PrDAqAEE>: Panic: file istream-header-filter.c: line 663 (i_stream_header_filter_snapshot_free): assertion failed:

Hi, dovecot's message parser enters an endless loop when fed with certain multipart messages with stray CR characters. parse_next_body_to_boundary() assumes the '\r' might be the beginning of a boundary line, reducing the block size by one: src/lib-mail/message-parser.c: 404 /* no linefeeds in this block. we can just skip it. */ 405 ret = 0; 406

Hi, I'm running 2.2.36 (as provided by openSUSE in their server:mail repository) and at least at one of my systems LMTP is crashing regularly on certain messages (apparently a lot of them). Sometimes (but not always a backtrace is posted to the logs: 2018-07-11T07:34:56.741848+02:00 saruman dovecot: lmtp(14690): Fatal: master: service(lmtp): child 14690 killed with signal 11 (core dumps

Hi, I will try to create a coredump later but now I see version 2.3.2.1 also crashing in LMTP :-( 2018-07-12T10:09:57.336062+02:00 saruman dovecot: lmtp(an007498)<11814><zrPDEdUMR1smLgAAQ/KzDw>: Fatal: master: service(lmtp): child 11814 killed with signal 6 (core dumps disabled - https://dovecot.org/bugreport.html#coredumps) 2018-07-12T10:09:57.382925+02:00 saruman dovecot:

Hi - I'm hitting a crash in dovecot, I get this logged followed by a terse stack trace and systemd-coredump details not included here - full gdb stack trace and more details are further down: Mar 12 10:32:26 goffin dovecot[8269]: imap-login: Login: user=<patman>, method=PLAIN, rip=192.168.1.4, lip=192.168.1.1, mpid=8477, TLS, session=<5RvGYLf2RrDAqAEE> Mar 12 10:32:26 goffin

Hi, dovecot crashes with the following trace when accessing some Maildirs: dovecot: 2007-05-16 13:30:09 Error: IMAP(6126360): file index-mail-headers.c: line 260 (index_mail_parse_header): assertion failed: (part != NULL) dovecot: 2007-05-16 13:30:09 Error: IMAP(6126360): Raw backtrace: imap [6126360] [0x80b6d6b] -> imap [6126360] [0x80b6769] -> imap [6126360] [0x808abda]

I've attached two backtraces, one from a segfault and another from an assertion error in imap. I've seen a couple of the same assertion and this is the only segfault. It looks like they could be related. They both have to do with indexing anyway... The code is from CVS as of May 30. The segfault happened while imap was doing searches for my pine filters. I've also noticed that in

Hi, I compressed a folder with the following script: ... for i in *.*.*; do file $i | grep bzip2 >/dev/null 2>&1 if [ $? -ne 0 ]; then echo "Compress: $i" cat "$i" | bzip2 -9 > ../tmp/$i if [ $? -eq 0 ]; then mv ../tmp/$i $i fi else

Ok, I have narrowed my IMP/Dovecot attachment problem down to what I think is a bug in Dovecot. The test that follow are performed on 0.99.11. When you download an attachment in IMP it uses the php function imap_fetchbody() which contacts the IMAP server and retrieves just the mime chunk you are looking for. It does this by first fetching some information about the email, and then grabs the

Hi there I'm using dovecot-1.1b2/b3 with deliver. All information is stored in an SQL database and no errors related to this issue are written to the logs (actually I get no errors at all). I've run into at problem; FETCH BODYSTRUCTURE is broken after upgrading to dovecot 1.1b2 (same issue with 1.1b3). BODUSTRUCTURE only returns information from the first section (with incorrect

Hi there, Quoting RFC 3501 sec. 7.4.2 ?FETCH Response? (data item BODYSTRUCTURE): ?A body type of type MESSAGE and subtype RFC822 contains, immediately after the basic fields, the envelope structure, body structure, and size in text lines of the encapsulated message.? According the ABNF (RFC 3501 sec. 9) the envelope structure is that of the ENVELOPE FETCH data item, and the

This causes the body structure to be incorrect. The RFC says it's fine o have empty header field values. --- This just adds a failing test, inspired from an e-mail spotted in the wild. Ideas welcome to fix it. src/lib-imap/test-imap-bodystructure.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/src/lib-imap/test-imap-bodystructure.c

Hi, I've changed a program that fetches mail via IMAP from an Exchange Server to use our Dovecot machine. But now I'm experiencing strange problems with seem to be caused by a wrong BODYSTRUCTURE answer that causes wrong charset handling. When fetchting the BODYSTRUCTURE I see this: Dovecot: 88 UID fetch 32 (BODYSTRUCTURE) * 1 FETCH (UID 32 BODYSTRUCTURE ("text"

Hello, I have the following issue: When using command? FETCH 2 (BODY.PEEK[HEADER] UID INTERNALDATE FLAGS BODYSTRUCTURE) on 2 different emails, we get 2 different response structure. First response structure contains the BODYSTRUCTURE in a single line, while in the second response, the BODYSTRUCTURE is divided into multiple lines with "{61}" character at the end of each line.