similar to: 1.0.rc25 released

Timo, I see where at least one other person reported this, but here goes. I went from rc24 to rc25 this morning, and I got an assert and core from my own mailbox withing five minutes: Mar 2 06:52:26 karst dovecot: [ID 107833 mail.error] IMAP(jaearick): file mbox-sync-rewrite.c: line 408: assertion failed: (need_space == (uoff_t)-mails[idx].space) Mar 2 06:52:26 karst dovecot: [ID 107833

I updated to the latest rc25 and started getting these messages(over and over again). This is on a Solaris 10 box and I tried compiling with gcc and sun c. I backed down to rc23 and the messages went away and everything works. Any body have an idea on what could be wrong? thank you dovecot: Mar 04 21:14:33 Error: child 467 (imap) killed with signal 6 dovecot: Mar 04 21:14:33 Error:

Hello, I saw that OpenSSH release 6.7 removed all CBC ciphers by default. Is CBC therefore considered as broken and unsecure (in general or SSH implementation)? I also read a lot of references (see below) but still not clear to me what's the actual "security status" of CBC and why it has been removed in general. http://www.openssh.com/txt/release-6.7 sshd(8): The default set

Hello! Noone has running a sendmail/Mailscanner/procmail/mbox environment? Ciao, Gerhard ---------- Forwarded message ---------- Date: Mon, 24 Apr 2006 20:27:56 +0200 (CEST) From: Gerhard Wiesinger <lists at wiesinger.com> To: dovecot at dovecot.org Subject: [Dovecot] Dovecot LDA with sendmail/Mailscanner Hello! I'm running dovecot in a sendmail/Mailscanner/procmail/mbox

On 15.06.2015 21:31, Christian Weisgerber wrote: > On 2015-06-15, Gerhard Wiesinger <lists at wiesinger.com> wrote: > >> I saw that OpenSSH release 6.7 removed all CBC ciphers by default. Is >> CBC therefore considered as broken and unsecure (in general or SSH >> implementation)? > CBC modes in SSH use the last encrypted block of the previous packet > as the IV

Hi, I had a core dump while using rc25. Here are the backtraces: Mar 5 00:52:31 rouge dovecot: IMAP(XXXXXX): Maildir /home/XXXXXX/Mail/.Sent sync: UID < next_uid (1 < 2, file = 1173024945.P2421Q0M874108.rouge:2,S) Mar 5 00:52:31 rouge dovecot: IMAP(XXXXXX): file client.c: line 401 (_client_input): assertion failed: (!client->handling_input) Mar 5 00:52:31 rouge dovecot: child 29120

Hello! I'm running squirrelmail 1.4.8 (I know this is not the latest version) and know I'm having troubles with: 1.) Folder list view 2.) Save to sent or Drafts folder. Configuration worked well. I think it has to do with the upgrade from dovecot 1.0 to 1.1 and the LIST command. Thunderbird/alpine work well. Commands from rawlog are: A002 LIST "" "~/Mail/Drafts"

On 05 Dec 2015, at 11:32, Gerhard Wiesinger <lists at wiesinger.com> wrote: > > Is it possible to configure the secure session caching mechanism? > e.g. like in nginx: https://bjornjohansen.no/optimizing-https-nginx I remember hearing about various security vulnerabilities in that earlier.. I guess they're fixed now then, unless people find more ways to exploit it. Anyway

Hello! Currently I'm trying to integrate dovecot's deliver program into procmail. So basically I'd write a patch for procmail to deliver not directly into the mbox file but delivering with the dovecot deliver program. Do you think this is a good concept? For testing I use the commands discussed below. Currently I'm having a problem that deliver doesn't recognize the

Hello, I'm trying to move from procmail to dovecot sieve. I found the translation script at http://www.dovecot.org/tools/procmail2sieve.pl It works well except the following use cases: * ^From:.*myemail at mydomain.com.* | formail -I"X-Priority: 2 (high)" -I"X-mydomain-com-seen: yes" | $SENDMAIL -oi \ myemail at mydomain2.com \ myemail at mydomain3.com :0c *

http://dovecot.org/releases/2.1/dovecot-2.1.5.tar.gz http://dovecot.org/releases/2.1/dovecot-2.1.5.tar.gz.sig A few announcements first: I'm now going to start being more strict about not answering Dovecot questions sent to me privately (especially support requests, but also bug reports, feature requests, etc). Often those questions could be answered by other people in the mailing list as

http://dovecot.org/releases/2.1/dovecot-2.1.5.tar.gz http://dovecot.org/releases/2.1/dovecot-2.1.5.tar.gz.sig A few announcements first: I'm now going to start being more strict about not answering Dovecot questions sent to me privately (especially support requests, but also bug reports, feature requests, etc). Often those questions could be answered by other people in the mailing list as

Hello, I'm running dovecot in a classical vmail.vmail setup with pigeonhole and LMTP. Permission worked well in the initial setup but currently (maybe after Fedora 22 update) I'm having the following permission issue: lmtp(root): Error: 7fPZFOL9wFXePQAABcdabc: sieve: binary open: failed to open: open(/etc/dovecot/sieve_after.svbin) failed: Permission denied (euid=9999(vmail)

On 05.08.2015 13:06, Steffen Kaiser wrote: > On Tue, 4 Aug 2015, Gerhard Wiesinger wrote: > >> >> I'm running dovecot in a classical vmail.vmail setup with pigeonhole >> and LMTP. Permission worked well in the initial setup but currently >> (maybe after Fedora 22 update) I'm having the following permission >> issue: >> >> lmtp(root):

I upgraded (NetBSD 2.99 i386) from 1.0rc7 to 1.0rc24 and then tried rc25, and in both cases need to restart Dovecot every day or so (low volume server). It seems to run out of file descriptors. I have now raised the file descriptor limit to 1024, but that is not a long-term solution... ... Mar 5 11:41:38 arioch dovecot: pipe() failed: Too many open files Mar 5 11:42:38 arioch

Hello, Is it possible to configure Dovecot as SASL client for central authentication (also remotely via TCP/TLS)? Following use case: IMAP server (host 1) <=> Windows Domain Controller and /etc/shadow authenticator via pam (host2) Should work as: IMAP server (host 1) <=> SASL Client via TLS <=> Network <=> SASL Server via TLS <=> Local SASL via pam <=>

http://dovecot.org/releases/2.2/rc/dovecot-2.2.20.rc1.tar.gz http://dovecot.org/releases/2.2/rc/dovecot-2.2.20.rc1.tar.gz.sig v2.2.20 probably will be released tomorrow or maybe during weekend. + Added mailbox { autoexpunge=<time> } setting. See http://wiki2.dovecot.org/MailboxSettings for details. + ssl_options: Added support for no_ticket + imap/pop3/managesieve-login: Added

http://dovecot.org/releases/2.2/rc/dovecot-2.2.20.rc1.tar.gz http://dovecot.org/releases/2.2/rc/dovecot-2.2.20.rc1.tar.gz.sig v2.2.20 probably will be released tomorrow or maybe during weekend. + Added mailbox { autoexpunge=<time> } setting. See http://wiki2.dovecot.org/MailboxSettings for details. + ssl_options: Added support for no_ticket + imap/pop3/managesieve-login: Added

Hi Gerhard, This is not exactly true. CTR modes have the length field encrypted. etm MAC modes and AES-GCM have the length field in cleartext. CBC is dangerous because the length field is encrypted with CBC. aes128-ctr + hmac-sha256 doesn't have any known vulnerability and encrypts the packet length, but uses the bad practice of e&m. chacha20-poly1305 encrypts both payload and packet

Hello! As discussed in the previous thread about "Dovecot deliver logging problem and procmail" I have made a small patch for procmail to deliver through dovecot's deliver program (or any other delivery program). So Procmail does not write the mailboxes directly any more. So delivery is done through pipes and an external program which can deliver the files. Since dovecot's