similar to: dovecot bug (maybe)

Hi, We have a weird bug happening in our dovecot installation. When I send html emails from many clients and compress them, there are no problem. They are opened and correctly formated. When I send an email from Squirrelmail and compress it, dovecot exits with no errors (there are no coredumps or seg fault - dovecot just exits). But the weird is, it just happens when squirrelmail opens an email

Hi, Certain IMAP folder problems started popping up with Squirrelmail with the 1.1beta10 version of Dovecot (and possibly earlier versions). Looked into it and I am seeing odd behavior with the LIST command. Here is how to reproduce problem, unless I'm missing something obvious: a001 login dean <password> a001 OK Logged in. a002 list "" * * LIST (\NoInferiors \UnMarked)

The imap process crashes when SquirrelMail wants to move a message to another folder. I have run imap in gdb and talked to it the same way SquirrelMail does and got a backtrace. I am using Dovecot beta3. I am using it in combination with XMail, which has maildir databases. My system is Gentoo Linux on x86. The same version of Dovecot works great for me on amd64 with exactly the same config. Here

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

I'm using dovecot 1.0.rc7 and Squirrelmain 1.4.8 using IMAP on a Debian 3.1 Testing system, and I'm having a problem. When Squirrelmail (or other IMAP clients) submits an LSUB "" "*%", dovecot responds with: Request: A004 LSUB "" "*%" Response: * LSUB () "/" "INBOX.Sent" * LSUB () "/" "INBOX.Trash" *

Hi, I am getting IMAP FETCH FLAGS in response to SORT and SEARCH commands for my INBOX. See the following transcript between dovecot (marked with S:) and an imap client (marked with C:) for an example SEARCH command. C: A004 UID SEARCH CHARSET ISO-8859-1 ALL TEXT {4} C: test S: + OK S: * SEARCH 5 13 20 21 22 23 24 30 37 39 56 64 77 82 93 94 96 103 109 110 118 135 136 158 160 165 171 174

Hi, I have a problem with the filename of attachments in some clients. # dovecot 1.2.(5|7) * 3 FETCH (BODYSTRUCTURE (("text" "plain" ("charset" "us-ascii") NIL NIL "7bit" 13 1 NIL NIL NIL NIL)("text" "plain" ("charset" "UTF-8" "name" "ISO-8859-1''testanh%E4ng.txt") NIL NIL

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 all, if I give the following command in test32: A004 UID SEARCH CHARSET ISO-8859-1 ALL TEXT {4} Test The response is: * SEARCH A004 OK Search completed. If I say: A004 UID SEARCH CHARSET ISO-8859-1 ALL FROM {4} Test The response is: * SEARCH 217 350 A004 OK Search completed. The RFC says that 'TEXT' is supposed to result in a list of messages where the search string is in

I'm using SpamAssassin to tag spam and prefix the spam score to the subject line. To make the scores sort properly in the client's message list, I pad the score with spaces to right-align it. It looks like dovecot-0.99.10.9-1.FC3.2 is frustrating this by stripping the excess spaces from the subject before reporting it in FETCH responses. Here's an actual subject line: Subject:

I need some help troubleshooting this problem. It only shows up with IMAP connections. I initially thought it was related to SquirrelMail (because it gives me an 'EXPUNGE' error), but after attempting to send IMAP commands directly to the server as shown below, I'm thinking there is something else going on. The system configuration is PostFix as the MTA delivering to procmail in

Hi, I'm using dovecot-0.99.10.4_1 on Freebsd. CPU architecture is i386. When ever I try to move messages og delete dem i get an internal error. Below I've tried to show what dovecot says. Mail gets stored using mbox format. After giving the internal error you kan try to expunge the mail again and it works without error. Any suggestions or ideas as to what could be wrong? is it a bug?

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, 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

Aloha Timo. I found a few odd things while playing with dovecot. At least one of them bugs me, but it might be a result of my own patches - I haven't testet it with mbox or maildir, yet. The details :) 1. * OK dovecot ready. A = (<return> Connection closed by foreign host. 2. * OK dovecot ready. A001 LOGIN xxxxxx xxxxxx A001 OK Logged in. A002 COPY 1 INBOX Connection closed by

Hi, all. Thanks Timo for answering my previous post. It's starting fine now :) I must be doing something wrong again but I can't connect from any imap client. If I telnet to the server I get: $ telnet carpa 11143 Trying 143.107.209.25... Connected to carpa.ciagri.usp.br. Escape character is '^]'. * OK dovecot ready. a001 login marcelo ##### a001 OK Logged in. a002 select INBOX

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"

http://togami.com/~warren/archive/2003/evolution-1.4.4-crash.mbox I suspect that dovecot-0.99.10 is misserving this message in some way that is confusing some IMAP clients. This behavior causes evolution-1.4.4 to segfault, and squirrelmail-1.4.1 to be unable to read the message. The same message served by uw-imapd works works fine in both evolution and squirrelmail.

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.

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: