September 2020 - dovecot

Re: Btrfs RAID-10 performance
by Robert Nowotny 11 Sep '20

11 Sep '20

"Miloslav" == Miloslav Hůla <miloslav.hula(a)gmail.com> <miloslav.hula(a)gmail.com> writes: Miloslav> Dne 09.09.2020 v 17:52 John Stoffel napsal(a): Miloslav> There is a one PCIe RAID controller in a chasis. AVAGO Miloslav> MegaRAID SAS 9361-8i. And 16x SAS 15k drives conneced to Miloslav> it. Because the controller does not support pass-through for Miloslav> the drives, we use 16x RAID-0 on controller. So, we get Miloslav> /dev/sda ... /dev/sdp (roughly) in OS. And over that we have Miloslav> single btrfs RAID-10, composed of 16 devices, mounted as Miloslav> /data. I will bet that this is one of your bottlenecks as well. Get a secord or third controller and split your disks across them evenly. Miloslav> That's plan for a next step. Miloslav> We run 'rsync' to remote NAS daily. It takes about 6.5 hours to finish, Miloslav> 12'265'387 files last night. That's.... sucky. So basically you're hitting the drives hard with random IOPs and you're probably running out of performance. How much space are you using on the filesystem? Miloslav> It's not so sucky how it seems. rsync runs during the Miloslav> night. And even reading is high, server load stays low. We Miloslav> have problems with writes. Ok. So putting in an SSD pair to cache things should help. And why not use brtfs send to ship off snapshots instead of using rsync? I'm sure that would be an improvement... Miloslav> We run backup to external NAS (NetApp) for a disaster Miloslav> recovery scenario. Moreover NAS is spreaded across multiple Miloslav> locations. Then we create NAS snapshot, tens days Miloslav> backward. All snapshots easily available via NFS mount. And Miloslav> NAS capacity is cheaper. So why not run the backend storage on the Netapp, and just keep the indexes and such local to the system? I've run Netapps for many years and they work really well. And then you'd get automatic backups using schedule snapshots. Keep the index files local on disk/SSDs and put the maildirs out to NFSv3 volume(s) on the Netapp(s). Should do wonders. And you'll stop needing to do rsync at night. Miloslav> It's the option we have in minds. As you wrote, NetApp is very solid. Miloslav> The main reason for local storage is, that IMAP server is completely Miloslav> isolated from network. But maybe one day will use it. It's not completely isolated, it can rsync data to another host that has access to the Netapp. **grin** Miloslav> Unfortunately, to quickly fix the problem and make server Miloslav> usable again, we already added SSD and moved indexes on Miloslav> it. So we have no measurements in old state. That's ok, if it's better, then its better. How is the load now? Looking at the output of 'iostat -x 30' might be a good thing. Miloslav> Situation is better, but I guess, problem still exists. I Miloslav> takes some time to load be growing. We will see. Hmm... how did you setup the new indexes volume? Did you just use btrfs again? Did you mirror your SSDs as well? Do the indexes fill the SSD, or is there 20-30% free space? When an SSD gets fragmented, it's performance can drop quite a bit. Did you put the SSDs onto a seperate controller? Probably not. So now you've just increased the load on the single controller, when you really should be spreading it out more to improve things. Another possible hack would be to move some stuff to a RAM disk, assuming your server is on a UPS/Generator incase of power loss. But that's an unsafe hack. Also, do you have quotas turned on? That's a performance hit for sure. Miloslav> Thank you for the fio tip. Definetly I'll try that. It's a good way to test and measure how the system will react. Unfortunately, you will need to do your testing outside of normal work hours so as to not impact your users too much. Good luck! Please post some numbers if you get them. If you see only a few disks are 75% or more busy, then **maybe** you have a bad disk in the system, and moving off that disk or replacing it might help. Again, hard to know. Rebalancing btrfs might also help, especially now that you've moved the indexes off that volume. Robert: Fio is an acronym for *Flexible IO Tester* and describes a tool for measuring IO performance. With Fio, devices such as hard drives or SSDs can be tested for their speed by executing a *user-defined **workload* and collecting performance data. Therefore it might be difficult to really simulate the load with that, because You need to define the workload Yourself. But, at least, You might use it to get an idea of maximum transfer rates, random I/O etc. *iotop* shows the *current I/O transfer **rates* for the currently running processes / threads. It uses the I/O usage information of the Linux kernel, so it might be a good tool for You. *htop *might also be Your friend. and of course, as someone else pointed out : > Looking at the output of 'iostat -x 30' might be a good thing. my default setup for such diagnosis is to run iotop, htop, ntop to get an idea whats going on and measure ... for the index-SSD (on a different Channel ? NvMe ?) I strongly suggest to compare EXT4 vs BTRFS - some Benchmarks suggest that on fast SSD´s EXT4 is much (factor 4-5) faster then btrfs. You might also try ZSTD transparent compression on the remaining (non-SSD) btrfs disks - this can boost the transfer rate (since the data is compressed) if the Server CPU´s have enough juice. But from my guts feeling, its not the transfer rate - its the random I/O (in that case the situation will get worse with compression), but You really need to measure that. In general I dont understand that (old fashioned) configuration - using a bunch of 2TB or even 4TB TLC SSD in Raid10 is nowadays really affordable. You can keep the old disks for (local) rsync before You rsync from there to the NAS ... Robert

1 0

Bug in sieve script compilation
by Иннокентий Сенновский 10 Sep '20

10 Sep '20

Hi, this is Rumata888 from hackerone. This is the other bug I found in sievec. If you try to compile the following script, it will result in a panic. The reason is: export expects its arguments to be either strings or lists of strings. When we issue an export command with a number immediately followed by an export command with a string argument, on parsing the second command sievec tries to merge the commands by merging the arguments. When it encounters an argument of unexpected type, it panics. Once again, I would advise unlinking invalid commands from ast, so that parsing of following commands was not dependent on previous irregularities.

1 0

dbox alternate storage and archived namespace
by Daniel Miller 10 Sep '20

10 Sep '20

This may (and probably does) come under the heading of "really dumb ideas", but... Before I develop this further I need to ask - is it possible to have a "primary" mail_location using single-dbox with an alternate storage using multi-dbox? This is *not* the same as different storages for different namespaces (already have that). -- Daniel

1 0

Re: zlib errors after upgrading to 2.3.11.3
by Robert Nowotny 09 Sep '20

09 Sep '20

On 8. Sep 2020, at 12.35, Robert Nowotny <rnowotny1966(a)gmail.com> wrote: Dear Aki, I switched to "gz" now, since "zstd" also gave some errors on writing to files. What kind of errors? Probably this? : Panic: file ostream.c: line 287 (o_stream_sendv_int): assertion failed: (!stream->blocking) can be - unfortunately I do not have the log files anymore... Sep 3 08:33:25 lxc-imap dovecot: imap(mpaul)<48684><2/9E5mKuAezAqKjk>: Error: Mailbox Sent: UID=2171: read(zlib(/home/vmail/virtualmailboxes/mpaul/storage/m.119)) failed: read(/home/vmail/virtualmailboxes/mpaul/storage/m.119) failed: Broken pipe (FETCH BODY[]) Also this way you can see if the broken mail is actually xz or zstd or zlib. It would be nice to know if there are any zstd or zlib compressed mails that have problems. We did a lot of stress testing with zstd and also with xz, but haven't been able to reproduce any problems. It's also strange that it says taht the error is "Broken pipe" - that doesn't indicate that the mail is corrupted but that there is something more strange going on. So perhaps you don't actually have any mails written as corrupted, but Dovecot is just somehow having trouble reading the mails. I managed to reproduce this. The files aren't corrupted, it's just that reading is failing. The attached patch should fix the xz code and should make your files readable again. Yes, it works ! I switched now to "zstd" compression and currently re-compressing all user imap folders (one by one) thank You so much ! Robert

2 1

Leaked Events
by bobby 08 Sep '20

08 Sep '20

I am going through my maillog file, and noticed these events: Sep 8 15:56:17 mail dovecot[294462]: lmtp(391257): Warning: Event 0x55db5bc41200 leaked (parent=0x55db5bc3b830): mail-storage-service.c:1325 Sep 8 15:56:17 mail dovecot[294462]: lmtp(391257): Warning: Event 0x55db5bc3b830 leaked (parent=0x55db5bc34450): smtp-server-recipient.c:38 Sep 8 15:56:17 mail dovecot[294462]: lmtp(391257): Warning: Event 0x55db5bc34450 leaked (parent=0x55db5bc34130): connection.c:523 Sep 8 15:56:17 mail dovecot[294462]: lmtp(391257): Warning: Event 0x55db5bc34130 leaked (parent=0x55db5bc20ce0): smtp-server-connection.c:773 Sep 8 15:56:17 mail dovecot[294462]: lmtp(391257): Warning: Event 0x55db5bc20ce0 leaked (parent=(nil)): lmtp-client.c:164 Is this something to be concerned about?

2 1

zlib errors after upgrading to 2.3.11.3
by Robert Nowotny 08 Sep '20

08 Sep '20

Dear Aki, I switched to "gz" now, since "zstd" also gave some errors on writing to files. I dont know if "xz" compression or "zstd" shreddered my MDBOX Files, but I lost 4 days of mail. (a couple of thousand mails). After restoring the backup (what was made after switching to version 2.3.11.3) I still have some broken mdfiles, but not too many. Interestingly always in the "Sent" Mailbox on a number of Users. I just can not go back to 20.08.2020 before I updated to 2.3.11.3 - too many emails would have been lost. So - the current status is 2.3.11.3, with "gz" compression. I force-synced and re-indexed all the mdbox files (250 GB), but still have some broken - please how can I fix those ? You stated : (In theory you could leave the existing mails xz-compressed, but best would be to re-compress everything via dsync so old mails can be read when we eventually remove xz support.) what is the optimal way to do that, expecially not loosing the index (?) for outlook/thunderbird, for third party tools that rely on some index/hash (dunno how exactly that works) ? Sep 3 08:33:25 lxc-imap dovecot: imap(mpaul)<48684><2/9E5mKuAezAqKjk>: Error: Mailbox Sent: UID=2171: read(zlib(/home/vmail/virtualmailboxes/mpaul/storage/m.119)) failed: read(/home/vmail/virtualmailboxes/mpaul/storage/m.119) failed: Broken pipe (FETCH BODY[]) Sep 3 08:35:26 lxc-imap dovecot: imap(mpaul)<48089><YRio1GKuEdHAqKi3>: Error: Mailbox Sent: UID=2171: read(zlib(/home/vmail/virtualmailboxes/mpaul/storage/m.119)) failed: read(/home/vmail/virtualmailboxes/mpaul/storage/m.119) failed: Broken pipe (FETCH BODY[]) Sep 3 08:35:26 lxc-imap dovecot: imap(mpaul)<49228><p/0g9WKuVdHAqKi3>: Error: Mailbox Sent: UID=2171: read(zlib(/home/vmail/virtualmailboxes/mpaul/storage/m.119)) failed: read(/home/vmail/virtualmailboxes/mpaul/storage/m.119) failed: Broken pipe (FETCH BODY[]) Sep 3 08:35:26 lxc-imap dovecot: imap(mpaul)<49229><GMAm9WKuVtHAqKi3>: Error: Mailbox Sent: UID=2171: read(zlib(/home/vmail/virtualmailboxes/mpaul/storage/m.119)) failed: read(/home/vmail/virtualmailboxes/mpaul/storage/m.119) failed: Broken pipe (FETCH BODY[]) Sep 3 08:35:27 lxc-imap dovecot: imap(mpaul)<49230><YYot9WKuV9HAqKi3>: Error: Mailbox Sent: UID=2171: read(zlib(/home/vmail/virtualmailboxes/mpaul/storage/m.119)) failed: read(/home/vmail/virtualmailboxes/mpaul/storage/m.119) failed: Broken pipe (FETCH BODY[]) ... Sep 3 09:04:44 lxc-imap dovecot: imap(cpotzinger)<49040></X+P72KuUNHAqKi3>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:04:51 lxc-imap dovecot: imap(cpotzinger)<54382><eYT1XWOux9HAqKi3>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:04:59 lxc-imap dovecot: imap(cpotzinger)<54396><nKllXmOuyNHAqKi3>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:05:06 lxc-imap dovecot: imap(cpotzinger)<54409><m2TOXmOuydHAqKi3>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:05:12 lxc-imap dovecot: imap(cpotzinger)<54422><IP86X2OuytHAqKi3>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) ... Sep 3 09:08:58 lxc-imap dovecot: imap(cpotzinger)<54867><BtGtbGOu49HAqKi3>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:19:15 lxc-imap dovecot: imap(mpaul)<56030></kHNkWOuAO3AqKjk>: Error: Mailbox Sent: UID=2171: read(zlib(/home/vmail/virtualmailboxes/mpaul/storage/m.119)) failed: read(/home/vmail/virtualmailboxes/mpaul/storage/m.119) failed: Broken pipe (FETCH BODY[]) Sep 3 09:29:41 lxc-imap dovecot: imap(cpotzinger)<57274><c4rCtWOuKuzAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:29:47 lxc-imap dovecot: imap(cpotzinger)<57320><K3Uqt2OuLOzAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:29:54 lxc-imap dovecot: imap(cpotzinger)<57333><e4aMt2OuLezAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:30:01 lxc-imap dovecot: imap(cpotzinger)<57346><JEfzt2OuLuzAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:30:08 lxc-imap dovecot: imap(cpotzinger)<57360><mH1YuGOuMOzAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:30:14 lxc-imap dovecot: imap(cpotzinger)<57382><IzLBuGOuMezAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:30:21 lxc-imap dovecot: imap(cpotzinger)<57397><q10kuWOuM+zAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:30:27 lxc-imap dovecot: imap(cpotzinger)<57410><CSuJuWOuNOzAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:31:22 lxc-imap dovecot: imap(mpaul)<57525><TfoOvWOuWO3AqKjk>: Error: Mailbox Sent: UID=2171: read(zlib(/home/vmail/virtualmailboxes/mpaul/storage/m.119)) failed: read(/home/vmail/virtualmailboxes/mpaul/storage/m.119) failed: Broken pipe (FETCH BODY[]) Sep 3 09:31:49 lxc-imap dovecot: imap(cpotzinger)<57423><Be/ruWOuNuzAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:31:55 lxc-imap dovecot: imap(cpotzinger)<57584><yvXOvmOuQuzAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:32:02 lxc-imap dovecot: imap(cpotzinger)<57597><e/8tv2OuQ+zAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:32:08 lxc-imap dovecot: imap(cpotzinger)<57611><BLSOv2OuROzAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:32:19 lxc-imap dovecot: imap(cpotzinger)<57633><Ky0twGOuR+zAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:32:26 lxc-imap dovecot: imap(cpotzinger)<57646><ljSRwGOuS+zAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:32:33 lxc-imap dovecot: imap(cpotzinger)<57659><rn75wGOuT+zAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:32:39 lxc-imap dovecot: imap(cpotzinger)<57672><GP9jwWOuUuzAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:33:45 lxc-imap dovecot: imap(mpaul)<57795><2CEwxWOubu3AqKjk>: Error: Mailbox Sent: UID=2171: read(zlib(/home/vmail/virtualmailboxes/mpaul/storage/m.119)) failed: read(/home/vmail/virtualmailboxes/mpaul/storage/m.119) failed: Broken pipe (FETCH BODY[]) Sep 3 09:38:29 lxc-imap dovecot: imap(mpaul)<58347><CKyX1mOuie3AqKjk>: Error: Mailbox Sent: UID=2171: read(zlib(/home/vmail/virtualmailboxes/mpaul/storage/m.119)) failed: read(/home/vmail/virtualmailboxes/mpaul/storage/m.119) failed: Broken pipe (FETCH BODY[]) Sep 3 09:38:32 lxc-imap dovecot: imap(mpaul)<58352><osHU1mOuiu3AqKjk>: Error: Mailbox Sent: UID=2171: read(zlib(/home/vmail/virtualmailboxes/mpaul/storage/m.119)) failed: read(/home/vmail/virtualmailboxes/mpaul/storage/m.119) failed: Broken pipe (FETCH BODY[]) Sep 3 09:38:44 lxc-imap dovecot: imap(cpotzinger)<54527><5ZpiYmOuBOfAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:38:51 lxc-imap dovecot: imap(cpotzinger)<58378><kAuN12OumuzAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) Sep 3 09:38:57 lxc-imap dovecot: imap(cpotzinger)<58392><xJLx12Oum+zAqKiU>: Error: Mailbox Sent: UID=29534: read(zlib(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703)) failed: read(/home/vmail/virtualmailboxes/cpotzinger/storage/m.4703) failed: Broken pipe (FETCH BODY[]) ... Am 26.08.2020 um 09:42 schrieb Robert Nowotny: I had 4 broken mdbox files for 4 different users. After deleting them, dovecot re-indexed, now everything is ok again. I can try to update tonight again to 2.3.11.3 and see if some broken files will appear again tomorrow. Am 25.08.2020 um 14:51 schrieb Aki Tuomi: On 25/08/2020 14:35 Robert Nowotny <rnowotny(a)rotek.at> <rnowotny(a)rotek.at> wrote: I get ZLIB Errors after dovecot upgrade from 2.3.10.1 to 2.3.11.3 Aug 21 15:27:34 lxc-imap dovecot: imap(acsida)<63870><jZk...>: Error: Mailbox Sent: UID=40826: read(zlib(/home/vmail/virtualmailboxes/acsida/storage/m.2409)) failed: read(/home/vmail/virtualmailboxes/acsida/storage/m.2409) failed: Broken pipe (FETCH BODY[]).... many of those entries.... after installing2.3.10.1 those files are still broken - but new files are working again. anything I can tweak or do ? Hi! Is it possible your mdbox file is corrupted? Can you share doveconf -n? Aki

2 3

Re: Re: Outlook problems on Apple systems(Mac os)
by hfh＠cndns.com 08 Sep '20

08 Sep '20

Outlook version is 16.40 hfh(a)cndns.com From: Jerry Date: 2020-09-08 13:22 To: Dovecot Mailing List Subject: Re: Outlook problems on Apple systems(Mac os) On Tue, 8 Sep 2020 09:57:59 +0800, hfh(a)cndns.com <hfh(a)cndns.com> stated: >Dovecot is on version 2.2.36. I tested it. Outlook on the Apple system >successfully logged in with the imap protocol, and then sent the LIST >command and outlook did not send any further. Dovecot returns the >results as follows: > >A003 OK LIST completed (0.001 + 0.000 secs). > > >There is no problem with version 2.1.17 using dovecot before. The >information returned by dovecot in version 2.1.17 is as follows: > >A003 OK LIST completed. > > >I suspect that the feedback of the following information causes >Outlook to not recognize it normally: > >(0.001 + 0.000 secs) What version of Outlook? -- Jerry

2 1

Outlook problems on Apple systems(Mac os)
by hfh＠cndns.com 08 Sep '20

08 Sep '20

Dovecot is on version 2.2.36. I tested it. Outlook on the Apple system successfully logged in with the imap protocol, and then sent the LIST command and outlook did not send any further. Dovecot returns the results as follows: A003 OK LIST completed (0.001 + 0.000 secs). There is no problem with version 2.1.17 using dovecot before. The information returned by dovecot in version 2.1.17 is as follows: A003 OK LIST completed. I suspect that the feedback of the following information causes Outlook to not recognize it normally: (0.001 + 0.000 secs) hfh(a)cndns.com

2 1

Search in Mailbox via doveadm REST-API
by rudolf＠padaru.de 07 Sep '20

07 Sep '20

Hey, i need some help with the http-api from doveadm, i try to search a string in the mail-text from all mails in my inbox. My curl-post looks like these: curl -v -X POST -u <user>:<password> -H "Content-Type: application/json" -d '[["search",{"query":["mailbox","INBOX","TEXT","8887"],"user":"<mailUser>"}, "tag1"]]' http://<server>:8080/doveadm/v1 | python -mjson.tool > out.json I receive only empty results, do have anyone an idea? Mit freundlichen Grüßen Yours sincerely <https://padaru.de/> Pascal Rudolf | Geschäftsführer PADARU-IT | Bielebohstraße 10 | 02736 Beiersdorf @: rudolf(a)padaru.de | www: <http://padaru.de/> padaru.de mobil: +49 (0) 17 772 595 32

1 0

LMTP-Process stays in RCPT TO state
by Pascal Christen 07 Sep '20

07 Sep '20

Hi We tried to update our Dovecot Director-Ring to 2.3 (latest version) and had one problem/bug. When we try to deliver an email from Exim to a receiving Dovecot (2.3 latest) via the LMTP-Proxy the LMTP process stays open forever and never closes. So after a few hours, we hit the LMPT-Process limit. The problem only exists if the receiving Dovecot reports "Quota exceeded (mailbox for user is full)" back to the Exim. If this is the case the state on the LMPT process stays at "lmtp: [_IP_ RCPT TO] (lmtp) and never closes. The TCP-Connection to the Exim is then in CLOSE_WAIT state on the Proxy. On the receiving Dovecot we set the "lmtp_rcpt_check_quota=yes" option. For me, it sounds similar to this bug: https://dovecot.org/list/dovecot/2018-January/110697.html but without the SEGFAULT which makes it harder to debug it. May you guys know why it doesn't change the state to IDLE or READY after reporting the quota issue or see something fishy in the commit above. If not I try to get a trace of the hanging process. Greetings Pascal

2 6