similar to: HG e3640ccaa76d crashes upon IMAP SEARCH

On 12 Jan 2015, at 04:15, Thomas Leuxner <tlx at leuxner.net> wrote: > $ doveconf -n | head > # 2.2.15 (e3640ccaa76d): /etc/dovecot/dovecot.conf > b search charset utf-8 body "Sleeve" > imap(tlx at leuxner.net): Panic: file message-decoder.c: line 346 (message_decode_body): assertion failed: (ctx->translation_size <= sizeof(ctx->translation_buf)) Hopefully

Hi, I've setup FTS using lucene and it should be working, the lucene index is updated when mail arrives. I also managed to reindex my INBOX: doveadm index -u foo -q INBOX However, when I try to index an Archives folder: doveadm index -u foo -q Archives, the index-work crashed with this log message: dovecot: indexer-worker(foo): Panic: file message-decoder.c: line 363

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I have seen the following assertion fails on my own mail server (indexer-worker): Panic: file charset-iconv.c: line 132 (charset_to_utf8): assertion failed: (*src_size - pos <= CHARSET_MAX_PENDING_BUF_SIZE) However, when charset_to_utf8_try returns FALSE (e.g. iconv() got EINVAL or EILSEQ), the for loop in charset_to_utf8 may end earlier,

On 16 May 2015, at 09:39, Xin Li <delphij at delphij.net> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi, > > On 5/15/15 10:58, Xin Li wrote: >> Hi, >> >> I have seen the following assertion fails on my own mail server >> (indexer-worker): >> >> Panic: file charset-iconv.c: line 132 (charset_to_utf8):

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

I'm using Evolution and Dovecot (on the localhost) and receiving these errors trying to move a message into the IMAP folder: C00095 APPEND INBOX (\Answered \Seen NotJunk "Junk" "NotJunk" "receipt-handled") {1022} C00095 BAD Error in IMAP command APPEND: Flags list contains non-atoms. Is this a Dovecot or Evolution bug? Thanks, Richard $ dovecot -n # 1.1.11:

Having relocated my virtual folders to a new namespace - I'm having some subscription challenges.? I'm able to reach them via telnet without issue - and some clients have better luck than others.? Some folders have no problems at all - some seem different. In trying to identify what might be the issue - at the moment the only thing I'm seeing is the ones that are completely

The VMI ROM detection and code patching mechanism is illustrated in setup.c. There ROM is a binary block published by the hypervisor, and and there are certainly implications of this. ROMs certainly have a history of being proprietary, very differently licensed pieces of software, and mostly under non-free licenses. Before jumping to the conclusion that this is a bad thing, let us consider more

The VMI ROM detection and code patching mechanism is illustrated in setup.c. There ROM is a binary block published by the hypervisor, and and there are certainly implications of this. ROMs certainly have a history of being proprietary, very differently licensed pieces of software, and mostly under non-free licenses. Before jumping to the conclusion that this is a bad thing, let us consider more

Running 1.0alpha5 (though I've been having this problem for the past couple of versions), and using mbox for the mailboxes. After I've read my mail using Apple's Mail.app (or Thunderbird) and take it offline, when I try to open the INBOX (or any mailbox) with pine, I get the following message (in pine): [Discarding bogus continuation in msg 1: $Forwarded NonJunk] Quitting

Oct 21 10:04:05 alchemy dovecot: imap-login: Login: user=<paulproteus>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, TLS Oct 21 10:05:44 alchemy dovecot: IMAP(paulproteus): file message-decoder.c: line 289 (message_decode_body): assertion failed: (pos < input->size) Oct 21 10:05:44 alchemy dovecot: IMAP(paulproteus): Raw backtrace: imap [0x80c8e10] -> imap [0x80c8d1c] ->

Dear all, back in January I posted about migration from courier and in particular on the script courier-dovecot-migrate.pl. That script had a bug on BSD (or should I say not-Linux?) type systems*. On FreeBSD (6.1) and MacOSX (10.5) it appended a lot of binary garbage at the end of dovecot-keywords files. On a couple of systems I had not actually run the script with the -- convert option,

# HG changeset patch # User Sebastian Wiedenroth <sebastian.wiedenroth at skylime.net> # Date 1437050484 -7200 # Thu Jul 16 14:41:24 2015 +0200 # Node ID 7ef3a533b097e8e6590e754dc56ad308ab29233b # Parent e3640ccaa76d77a9658126d1f8f306480dad8af7 Fix hang in safe_sendfile on SmartOS The call to sendfile on SmartOS can fail with EOPNOTSUPP. This is a valid error code and documented in

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, On 5/15/15 10:58, Xin Li wrote: > Hi, > > I have seen the following assertion fails on my own mail server > (indexer-worker): > > Panic: file charset-iconv.c: line 132 (charset_to_utf8): assertion > failed: (*src_size - pos <= CHARSET_MAX_PENDING_BUF_SIZE) I've managed to narrow down the issue to one mail, and

I've been seeing this same error as well now: Fatal: master: service(indexer-worker): child 20979 killed with signal 6 (core not dumped - set service indexer-worker { drop_priv_before_exec=yes }) Panic: file charset-iconv.c: line 132 (charset_to_utf8): assertion failed: (*src_size - pos <= CHARSET_MAX_PENDING_BUF_SIZE) It's only shown up on one particular user, and after tracking down

# ls -lsd /path/to/virtual/.*{Junk,Drafts,Sent,Trash} 8 drwx------ 5 89 89 512 Aug 19 06:46 .Drafts 8 drwx------ 5 89 89 512 Aug 19 06:42 .INBOX.Drafts 8 drwx------ 5 89 89 512 Aug 20 11:44 .INBOX.Junk 8 drwx------ 5 89 89 512 Aug 19 06:42 .INBOX.Sent 8 drwx------ 5 89 89 512 Aug 19 19:41 .INBOX.Trash 8 drwx------ 5 89 89 512 Aug 19 06:55 .Junk 8 drwx------ 5 89 89 512 Aug 19

Dear Peter, My inbox is MDA_external Storage: 17GB of 24GB Subject / From / To is fast but FTS(Full Text Search) for body is horrible. I suppose this is where we need Apache Solr. Do you think my mail storage format is bad? Do I need to change for better performance? Please advise Kevin On Thu, Jan 29, 2015 at 12:25 PM, Peter Hodur <petehodur at gmail.com> wrote: > > * Kevin

Hi all, my Dovecot 1.1.20 does not store flags (I mean, Thunderbird Labels like ToDo, Important and so on..) When logging in via telnet, I get: . examine INBOX * FLAGS (\Answered \Flagged \Deleted \Seen \Draft NonJunk $MDNSent Junk $Forwarded NotJunk receipt-handled $Label7 $label1 $label2 $label3 $label4 $label5 expired_2w expired_2m delete rimandata forwarded) * OK [PERMANENTFLAGS ()]

I run thunderbird (both 3.x and 5.x) against dovecot 2.x and frequently see delays "loading message". I admit to having a very large mailbox and running multiple imap clients. I've turned on thunderbird debugging, and at least one pattern I see in the log during the delays (maybe a minute long) is the failed protocol message above. These are no the only delays, but are the ones

Hi all, With some help of this list, I've managed to set up some mailboxes keeping \Seen flags as private. Thanks Timo for updating the documentation about that. But now, I've got another question: is it possible to keep those flags as private and have shared keywords ("Junk", "NotJunk", etc.)? I suppose that flags and keywords are stored in the index file, so I