similar to: A message, when moved by multiple clients with same account and same filters, can be duplicated by filters on destination imap folder.

Hi, I'm collecting users feedback of latest dovecot 1.1.rc3 development release. Some users are complaining that their sent mails sometimes don't get written to imap Sent-mail folder. It seems that all these users were using multiple istances of imap processes to read their mail (thunderbird+horde-imp, evolution+horde-imp or multiple thunderbird istances). No error message is written in

Sorry, this time I've no core file, (I forgot to set ulimit -c unlimited before starting dovecot) Regards, Diego. --- dovecot: Dec 09 08:26:52 Panic: IMAP(user): file mbox-sync-rewrite.c: line 590 (mbox_sync_rewrite): assertion failed: (mails[idx].from_offset == start_offset) dovecot: Dec 09 08:26:52 Error: IMAP(user): Raw backtrace: /usr/libexec/dovecot/imap [0x80f739e] ->

Yes, again, some sent emails don't get copied to sent folder. This time I get the following error: Error: IMAP(username): UIDs broken with partial sync in mbox file /maildir/username/Sent This happened at least with thunderbird and with evolution. Dovecot is running on vith fcntl locking on Centos5, sendmail should use fcntl, too. Filesystem is ext3 on drbd partition. After a grep vith

Hi, although I've done S3 dispatching for more than a decade now, I think I managed to overlook/avoid the following pitfall when using NextMethod(): If you explicitly pass argument '...' to NextMethod(), you will effectively pass those argument twice to the "next" method! EXAMPLE: foo0 <- function(...) UseMethod("foo0"); foo1 <- function(...)

Dovecot 1.1.7 is running so smoothly that I gave up checking its log files daily. :) I've just had a look, and among the usual "IMAP(username): FETCH for mailbox Sent UID xx got too little data: xx vs xx" messages (that means that unfortunately sometimes some messages are still written truncated) I saw this assertion failure: file mbox-sync.c: line 1305

I'm trying to use the rsync algorithm for incremental backups. After a quick look at rsync I saw the batch mode operations, and I thought that maybe I can modify them for incremental backups. What is needed is to add an option to save the checksums of all the files of the level 0 backup and a second option to use the level n checksum to calculate the delta batch files for the level n+1

mbox messages gets header corruption caused by an extra linefeed after Content-Length Users sees their mails in Sent mbox folder without the from and to fields, without attachments and with the date of 1/1/1970 Diego. --- Here is an anonymized header: >From xxxxxxxx at xxxxxx.xxxxxx.xxxxx.xx.xx Tue Jun 03 09:14:33 2008 Message-ID: <xxxxxxxx.xxxxxxx at xxxxxx.xxxxx.xx.xx> X-UID: 3913

And got this regression with dovecot-1.1.rc7 with each pop3 connection, hg version of 2 days ago was working fine. Now I'm back again to hg before "Message sort index handling rewrite". Regards, Diego. --- Panic: POP3(username): file index-mail.c: line 1007: unreached (gdb) bt #0 0x00b91402 in __kernel_vsyscall () #1 0x00725ba0 in raise () from /lib/libc.so.6 #2 0x007274b1 in

Hello, I'm using dovecot as a mail relay so that I can back up my providers IMAP mail locally. I'm impressed how easy this was to set up, but I'm having a quirk that I would like help with, if possible. There are many weak links in my set-up chain, if you will, but I think I've narrowed the problem. I'll describe my set-up anyway. I'm running dovecot 1.1.4 on ubuntu

I was wondering if it could be useful to use such tools to keep track of users bugs. I find somehow harder to search the mailing list if a bug is known, if it's being worked on, if it needs more feedback, in witch release it has been eventually solved, and so on. Any thoughts? Regards, Diego.

On Wed, Oct 8, 2008 at 7:36 PM, mouss <mouss at netoyen.net> wrote: > > an alternative is > > content_filter = > smtpd_sender_restrictions = > check_sender_access hash:/etc/postfix/sender_ok > check_sender_access pcre:/etc/postfix/filter > > == dsn_ok > <> OK > > == filter > /./ FILTER filter:[1.2.3.4]:10024 > > where

To some users happens this assertion failure while deleting a message. dovecot: Mar 10 08:40:44 Panic: IMAP(user): file index-sync.c: line 39 (index_mailbox_set_recent_uid): assertion failed: (seq_range_exists (&ibox->recent_flags, uid)) dovecot: Mar 10 08:40:44 Error: IMAP(user): Raw backtrace: [see bleow] dovecot: Mar 10 08:40:44 Error: child 17683 (imap) killed with signal 6 And the

I'm talking about mbox Sent folder, where some mailers append through imap server a copy of each message they send. Sometimes, just three header lines got appended instead of the whole mail message, such as: >From xxxxxxxx at xxxxxx.xxxxxx.xxxxx.xx.xx Fri May 23 12:30:14 2008 X-UID: 2852 Status: RO This happened in the past (dovecot-1.1-beta/rc with Evolution and with Thunderbird), and

I've tried to stress test dovecot 1.1.4 with imaptest for days without any assertion failure or crash. Just some "got too little data" messages. So far it's the most stable 1.1.x version. Today a user got this imap segfault with vanilla 1.1.4 (I don't know if it's something you have already fixed in current tree). The user didn't complain of anything, I've just

I've been trying to get Dovecot 1.0a3 running on OpenBSD 3.7, with little luck. I'm getting the following: Oct 16 17:00:50 mailtest dovecot: pop3(testuser):open(/var/mail/.temp.mail.mailtest.com.7078.43c0f93e9fecb54a) failed: Permission denied Oct 16 17:00:50 mailtest dovecot: pop3(testuser): file_lock_dotlock() failed with mbox file /var/mail/testuser: Permission denied Oct 16

Hi, I think that the wu-ftp style chroot /./ should be a configurable option. In our servers we have some home directories in /chroot-web/./username (where web users can upload their web sites in a chrooted environment) and all imap mail in /mail-disk/username. We are planning a dovecot migration from our modified version of uw-imap and we noticed that the chroot in /chroot-web/ can't be

I've tried turning on mbox_very_dirty_syncs for myself (and a few other brave souls running 1.0-alpha3 rather than 1.0-stable) again to see what perfomance gain it gives (see thread http://www.dovecot.org/list/dovecot/2005-July/007956.html). Now we aren't running UW-IMAP at all, how safe is mbox_very_dirty_syncs assuming the only other process writing to mailboxes is our MTA (exim) which

We are pleased to release v2.3.13. Please find it from locations below: https://dovecot.org/releases/2.3/dovecot-2.3.13.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.13.tar.gz.sig Binary packages in https://repo.dovecot.org/ Docker images in https://hub.docker.com/r/dovecot/dovecot Aki Tuomi Open-Xchange oy --- * CVE-2020-24386: Specially crafted command can cause IMAP hibernate to

We are pleased to release v2.3.13. Please find it from locations below: https://dovecot.org/releases/2.3/dovecot-2.3.13.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.13.tar.gz.sig Binary packages in https://repo.dovecot.org/ Docker images in https://hub.docker.com/r/dovecot/dovecot Aki Tuomi Open-Xchange oy --- * CVE-2020-24386: Specially crafted command can cause IMAP hibernate to

Hi At line 1118 of src//lib-index/mail-index-map.c, inside the function mail_index_map_move_to_memory, there is: mail_index_map_copy_header(map, map); Valgrind is stating that "Source and destination overlap in memcpy". I'm wondering if this code is just coping the same memory over itself, or if it is doing something useful. Regards, Diego Liziero. --- 1104 void