similar to: fetch bodystructure filename problem rfc2231

Hello, I'm currently testing dovecot/imap (Version 0.99.13). I found this in the log: imap(xxxxx): [ID 265587 mail.crit] file imap-bodystructure.c: line 278 (part_parse_headers): assertion failed: (part->physical_pos >= input->v_offset - start_offset) dovecot: [ID 684838 mail.error] child 7376 (imap) killed with signal 6 The user tried to setup a new folder (with Thunderbird)

Fyi... Sam Varshavik (courier-imap developer) claims (on the courier-imap list, see attached) dovecot is incorrectly parsing messages with missing/invalid "MIME-Version:" header... I have no clue if he is correct... if so, maybe this has already been fixed? -------------- next part -------------- An embedded message was scrubbed... From: Sam Varshavchik <mrsam at courier-mta.com>

Hi! I've found a bug in Content-Type parsing. It's old instance of dovecot 1.1. Maybe fixed in newer versions. I have a mail with header: Content-Type: multipart/signed; boundary="------------080705010808010608030700"; protocol="application/x-pkcs7-signature";micalg="SHA1" and it works, but when the boundary is in different order Content-Type:

On Fri, Dec 08, 2017 at 18:47:37 +0900, TACHIBANA Masashi wrote: > Hi, > > I tried to see a mail that have a strange From header in bellow URL: > > https://www.mailsploit.com/index > > Then, I got BODYSTRUCTURE response contain next: > > ((NIL NIL "service" "paypal.com")) > > Are this problem already founded by anyone? > So already

On 3. Mar 2020, at 20.38, Simon Ser <contact at emersion.fr> wrote: > > This causes the body structure to be incorrect. The RFC says it's fine o > have empty header field values. The problem isn't empty header field. It's that the mail is missing Mime-Version header. If that doesn't exist, then the Content-* headers can be ignored. But because there are so many

Hello, we are developing a web page, for a ticket system, to show the email messages ordered by the biggest attachments size present in an IMAP folder, with a pagination of 100 messages per page. Each raw represents a message with "DATE, FROM, SUBJECT, the preview (the first 500 chars of the text/html of the messsage) and the list of the attachments (name + size) it contains. The

Hi, I tried to see a mail that have a strange From header in bellow URL: https://www.mailsploit.com/index Then, I got BODYSTRUCTURE response contain next: ((NIL NIL "service" "paypal.com")) Are this problem already founded by anyone? So already fixed? -- TACHIBANA Masashi QUALITIA CO., LTD. mailto:tachibana at qualitia.co.jp

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

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

First let me thank you for my initial newby question about poping from a pop3 server and delivering into my Dovecot maildir folders. Now I'm getting an assertion in imap-bodystructure.c and one of my imap folders is now inaccessable. I think the two are related. Whenever I select the folder from my email client (kmail) I get two log entries in the dovecot log of the format:

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"

I'm running Dovecot on a Debian system which recently has been failing on an assert(). I have a spam mailbox that if I try and open (from any client), the imap process dies and this is written to the error logs: Dec 21 18:57:11 theronge imap(mronge): file imap-bodystructure.c: line 278 (part_parse_headers): assertion failed: (part->physical_pos >= input->v_offset -

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, Compiling on FreeBSD 10.1 gives linker errors when linking test-message-snippet. The underlying problem is that libiconv appears on the actual linker line after libcharset.a, which leads to unresolved libiconv symbols. This build process worked fine with 2.2.15. The patch below to src/lib-charset/Makefile.in resolves the problem for me and seems broadly correct. libcharset.a does depend on

Hi, I've noticed a possible minor issue with long encoded filenames for attachments where these filenames are split across multiple lines. My understanding of character encoding and MIME is not as good as it should be, so I may easily have got this all mixed up, in which case sorry for the noise... Although I understand the preferred method for handling filenames split across multiple

cheers, jerry --------------------------------------------------------------------- www.valinux.com VA Linux Systems gcarter_at_valinux.com www.samba.org SAMBA Team jerry_at_samba.org www.plainjoe.org jerry_at_plainjoe.org --"I never saved anything for the swim back." Ethan Hawk in Gattaca-- Return-Path: