Another possibility is to use LDAP authentication on the z-push apache server. This would prevent z-push from interacting with the zimbra webmail for all unauthenticated sessions. You can add fail2ban, or similar method to greylist/blacklist ip addresses that are repeatedly getting bad logons - you can see the discussion here - https://forum.kopano.io/topic/682/z-push-behind-basic-authentication/10
Hello @powercommy ,
we had some server troubles over the weekend with the system hosting the atlassian stack for z-hub.io. The system is now back online. You can find our contribution guidelines at https://wiki.z-hub.io/display/ZP/Development+guidelines
Running into an out-of-memory error is definitely a good indication why there is nothing shown in Outlook.
We’ve just implemented a ticket that works better for Outlook and prevents these errors, unfortunately it’s not yet merged (into Z-Push 2.4).
There are two immediate solution:
increase the php memory limit in your php.ini to 256 or 512 MB (restart apache afterwards)
reduce the amount of SYNC_MAX_ITEMS in your z-push config file. 100 should be a good starting point.
@Manfred : Desktop Clients worked fine
Maybe I had some typo error or I don’t know what went wrong in the past. I changed the IMAP_OPTIONS back to /ssl and it works.
Emails are also synced to the client now, the only thing I am struggling with is carddav and caldav with owncloud. But I need to invent first, so I can mark this thread as solved.
After digging around the code some the obvious (and “most-correct”) way to do this is to enhance the IMAP php library so that when it is sent an “open” it checks for the capability and, if present and the environment variable with the remote IP is set (which it will be if it was called an upstream “thing” that sets it, such as a web server) it then sends that stanza down after the password is accepted.
This would cause the IMAP php module to log it to Dovecot (or any other compatible IMAP server) for all users of it, not just Z-push, and it requires no code changes in the Z-push codebase itself. I run FreeBSD and haven’t dug into the php development community at all, so while I can certainly grab the FreeBSD port and do it in there that doesn’t help anyone except possibly FreeBSD users if I sent the patch back into their system, and it’s subject to rot there over time. The “right” approach to go after this is in the php upstream of course; I’ll stick a note in my “list of things to look at”, but I can’t commit to a when I’ll get to it.
Looks like I spoke too soon about this one. On one Debian Stretch server running PHP-FPM, I was able to get Z-Push working with the IMAP/combined backend. On the original server, running mod_php, it still doesn’t work. I’ve tried switching to just the IMAP backend and leaving IMAP_DEFAULTFROM blank, and it still fails with ‘Unable to verify account information’. A GET request to the ActiveSync URL in browser works. Nothing appears in /var/log/z-push.log, /var/log/z-push-error.log, /var/log/auth.log, /var/log/syslog or /var/log/mail.*.
Curious. The device in question is an iPhone SE running iOS 11, which I would expect to follow the specs for sending mail. It’s also got another Z-Push account set up on it, linked to a Zarafa 7.2.6 install, which as you say does correctly set the Message-ID.
This appears to be wrong:
02/09/2017 15:42:01  [DEBUG] [test] Util::MakeUTCDate(): Input '20170902T160000', timezone '(GMT-06:00) Central Time (US and Canada', output '2017-09-02 16:00:00', offset '-21600'
What I think we want there is the original timezone specification that PHP understands, which is “America/Chicago”; if I place a “$tz = timezone_open(“America/Chicago”);” just before the conversion then the correct DST offset is picked up. It looks like the PHP code is seeing the “GMT-06:00” and stops there (which makes sense as that’s not a PHP-known timezone string.)
I’ll trace back through the code to figure out where the mistake is and generate a patch on Jira.