Postfix verbose logging shows this:

Mar  8 20:03:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: connection established
Mar  8 20:03:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: master_notify: status 0
Mar  8 20:03:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: name_mask: resource
Mar  8 20:03:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: name_mask: software
Mar  8 20:03:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: connect from localhost[127.0.0.1]
Mar  8 20:03:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: match_list_match: localhost: no match
Mar  8 20:03:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: match_list_match: 127.0.0.1: no match
Mar  8 20:03:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: match_hostname: localhost ~? 127.0.0.0/8
Mar  8 20:03:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: match_hostaddr: 127.0.0.1 ~? 127.0.0.0/8
Mar  8 20:03:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: smtp_stream_setup: maxtime=300 enable_deadline=0
Mar  8 20:03:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: match_hostname: localhost ~? 127.0.0.0/8
Mar  8 20:03:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: match_hostaddr: 127.0.0.1 ~? 127.0.0.0/8
Mar  8 20:03:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: > localhost[127.0.0.1]: 220 mail.server.com ESMTP Postfix
Mar  8 20:03:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: watchdog_pat: 0x559232efc1c0
Mar  8 20:08:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: smtp_get: timeout
Mar  8 20:08:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: > localhost[127.0.0.1]: 421 4.4.2 mail.server.com Error: timeout exceeded
Mar  8 20:08:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: match_hostname: localhost ~? 127.0.0.0/8
Mar  8 20:08:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: match_hostaddr: 127.0.0.1 ~? 127.0.0.0/8
Mar  8 20:08:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: timeout after CONNECT from localhost[127.0.0.1]
Mar  8 20:08:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: disconnect from localhost[127.0.0.1]
Mar  8 20:08:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: master_notify: status 1
Mar  8 20:08:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: connection closed
Mar  8 20:08:17 prod-mail-proxy-1.pao1.server.com postfix/smtpd[22547]: watchdog_stop: 0x559232efc1c0

Patch applied in 239783c3dd576.

Duplicate of T2223

Wouldn't the simple solution to be allow folders to be created as subfolders of INBOX @machniak

refering to all occurances of user_mailbox_rename in https://git.kolab.org/diffusion/P/browse/master/pykolab/auth/ldap/__init__.py

Headers would be possible but then the header: Transfer-Encoding: chunked will be added and fails. (nginx latest doesn't work).
Stated here, http://sabre.io/dav/0bytes/ it should work but it don't.
So, when using fpm either nginx or apaches fastcgi it won't work as expected.
Since my "hacky" workaround works i'll leave it that way.
To be compatible it should be mentioned in the docs.
Task can be closed.

Could we just set content-length header using 4th argument of the client->request() method? I mean use the header for both operation modes, i.e. for file as a stream and as a string. These curl settings look very hackish.

Hi Alexander,
i now solved the problem by reading the C-Source.
f you use http PUT with curl then you have to specify the Content-Length header. Otherwise it is automatically handled by the curl for both GET and POST.
This has to be done by Sabre which it doesn't in the particular version 2.1.6.
So, the Content-Header: will be defined using 0 bytes. That's it. you only have to specify the content-lenght header via setopt and it works.
Since the obsys kolab mirror is down right now, i cannot create a detailed diff. (removed the source files by accident and don't know if git is in sync with the package files).
This explains why there's no error in the logfile visible. I missed the authType in my testscript and so the error appeared ;-)
Sorry for that.
Nevertheless, it works now.

Hi again,
i now scanned the latest php 7 source and the tests are very interesting.
E.g:
curl_setopt_CURLOPT_READFUNCTION.phpt

I didn't read curl sources, but maybe Sabre/HTTP/Client should define CURLOPT_READFUNCTION.

Hi Alexander,
plain jessie php PHP 5.6.30-0+deb8u1 with no modifications.
Also i checked curl C sources. It will read from one file socket and write directly to the remote socket.
So you're right. I can recall have owncloud years before it didn't work either.
Don't know if it was Sabre 2.1.6 back then.
Anyhow, i found this post which is dated from 2013. Nevertheless the options doesn't exist neither in the current CURL version nur in the php module.
Link:
https://github.com/aws/aws-sdk-php/issues/140

I'm telling you Sabre supports file handles (https://github.com/sabre-io/http/blob/master/lib/Client.php#L397). Problem is that for some reason the handle is not seekable, which is a requirement from curl. From what I know rewind is needed in case of connection redirect or interruption, but anyway I don't see why it couldn't rewind.

I din't know what you mean.
You use the SABRE Client DAV library which takes care of the workflow.
The first requests consists of a PUT request which then creates the file (0 bytes).
The 100-Continue header will be EXPECTed.
Then the data will we sent to the server by reusing the connection (keep alive) and otherwise will generate an error ( e.g 499).
It's clear that there's a bug in your code because it's a fact that you cannot assign a file handle as variable.
And obviously you don't catch the exception raised by SABRE.

Sabre (and cURL) supports the body as a resource. So, the bug is somewhere else.

For others who might run into the same issue, the above sql does not work. after fixing the syntax because md had interpreted the backticks, it left me unable to send or receive mail. I had to delete the table and let pykolab recreate it.

My kolab install is rejecting emails from Amazon because of this bug. The logs when such an email arrive show:

Ok it works for me now, i don't know if its because i updated my Iphone to ios 11 or if the problem was fixed anywhere else. Because nobody is taking care of this i am closing this bug now.

I have filed now a bug at the jstz library, because I guess that would be the cleanest solution.
If that ignores Etc timezones coming from the internationalization API from the browser, then it calculates a proper Olson timezone.

It does not depend on Windows Server version.
It does not depend on Firefox version either.

I got more details: the client is Firefox 56 running on Windows Server 2012 R2. The timezone setting for the user in Roundcube is "auto".

I believe the issue has been fixed by https://git.kolab.org/rACb2fdd4828985a07e6f715ecbe789bf4fa5102ec3. It looks that this old commit wasn't packaged yet.

Here is a partial hexdump-diff of the binary:
http://rb.zq1.de/compare.factory-20170617/libkolabxml-compare.out
It makes the differing ASCII portions more visible and recognizable that start after xml:lang="en">.

If there is a patch for Winterfell could you please port this also to Kolab16?
I have a current Kolab16 installation in a Centos7 lxc container on an Ubuntu 16.04 host.
kolab lm is not working and there are no folders created for new users.

Current Winterfell seems to have it fixed:

Winterfell seems to use newest boot now:

OK, this is all me ;-)

Hello,
i reported the problem by the beginning of 2017 using the mailing list.
Since it hasn't been resolved, i disabled guam by changing the cyrus config.
This was with version 0.9.2-1.
Now, today i gave it a try and installed version 0.9.2-3. (Running on debian jessie).
Thunderbird can get the mails in the inbox, but when it starts to index the folders, thunderbird hangs.
On the server i strace the guam process and see, that there are unjoined threads and they never join.
Perhaps a hint, since erlang is based on threads.
As for now, i disabled guam again.

Bumping cyrus-imapd didn't solve the problem, unfortunately - it got built with Perl 5.22 again.

It's just not getting rebuilt automatically. Let's bump something and therefore trigger a rebuild, so that existing installations receive an update too (now possibly preventing an unstable system from being updated to a stable system).

Well, reading through RFC6851 (MOVE command):

Probably a cyrus bug?
https://github.com/cyrusimap/cyrus-imapd/issues/2114

Another example
IMAP log:

`
[23-Aug-2017 11:45:32 +0200]: [EE2A] C: A0017 UID MOVE 59667 "T&APY-r&APY-lt elemek"
[23-Aug-2017 11:45:32 +0200]: [EE2A] S: * OK [COPYUID 1304109194 59667 4484] Completed
[23-Aug-2017 11:45:32 +0200]: [EE2A] S: * 217 EXPUNGE
[23-Aug-2017 11:45:32 +0200]: [EE2A] S: A0017 OK Completed

Assigning to Jeroen. (Are there any others who also take care of the OBS?)

Done.

Looks like some manual interaction is necessary:
https://en.opensuse.org/openSUSE:Build_Service_Tips_and_Tricks#Removing_disabled_but_built_packages_from_a_repository

Thanks to Jeroen for fixing roundcubemail in Winterfell, it is now working fine, my nightly tests succeed again!
Thank you!

The first error is something internal to composer. In my CentOS system I have composer-1.0.0-3.1.el7.kolab_wf and I have /usr/share/php/Psr/Log/LoggerInterface.php file.

I tried with --no-dev, but that did not seem to make a difference.
Then I tried to upgrade to Composer 1.2.4, which is the version used in Debian Stable: https://obs.kolabsys.com/package/show/home:tpokorra:branches:Kolab:Winterfell/composer

Maybe the composer version is too old. Many dependencies require phpunit using version constraint "^4" or similar. I think you can solve this simply by excluding developer dependencies. Use composer with --no-dev argument.

I have now built the roundcube package with the -complete tarball, in https://obs.kolabsys.com/package/show/home:tpokorra:branches:Kolab:Winterfell/roundcubemail

Since Roundcube 1.3 external javascript libraries are not anymore in the git repository. There's a script to download them and install in bin/install-jsdeps.sh (it uses jsdeps.json file in root folder). So, either we use -complete tarball (not /vendor folder there) or fetch js deps in package create stage. Or maybe in post-install script?

A low hanging fruit. Patch in my comment above.

I have changed the acls for anyone to lrs and that did the trick - don't see errors anymore. Wallace messages were dispatched.

ps. there's possible performance optimization in find_user_folders: don't use imap.list_folders('*'), instead depend on imap.get_metadata('*'), which we do anyway. But of course we should ask for the metadata we need, not all of them.