I'm trying to retrofit SOGo into an existing mail environment. I started
testing by setting up a fresh Cyrus IMAP server on CentOS 7, pointed auth
to the local AD environment, everything worked pretty smooth, including EAS.

I changed the SOGo machine and pointed it to the production Cyrus IMAP
server on a CentOS 6 box (Cyrus-IMAP vers. 2.3.16) and everything still
works pretty well, except EAS it seems. I can connect to EAS successfully
setting up an account in Outlook. Additionally I can download the folder
list, but no mail items come in. What debugging I could do found me these
things:

>From the SOGo LOG (with EAS debugging enabled):

     [ERROR] <0x0x7fbfd4ca9d50[NGImap4Connection]> Error fetching 425 uids
for url: imaps://first.last%40************.net@mail.
************.net/Other%20Users%2F************%2FDeleted%20Items%2FIllinois%20Street%2FArtwork/

I see this type of error for each folder to be downloaded, this is just 1
example of a great many alike. When this error is occurring on the SOGo
server this is what I see on the Cyrus IMAP server:

     Jul 16 10:46:48 mailserver imaps[20921]: open: user
first^last@************.net
opened Other Users/************/Deleted Items/Illinois Street/Artwork
     Jul 16 10:46:48 mailserver imaps[20921]: open: user
first^last@************.net
opened Other Users/************/Deleted Items/Illinois Street/Artwork
     Jul 16 10:46:48 mailserver imaps[20921]: open: user
first^last@************.net
opened Other Users/************/Deleted Items/Illinois Street/Artwork
     Jul 16 10:46:48 mailserver imaps[20921]: SQUAT returned 425 messages

Mind you to add to the confusion - SOGo works fine and can pull down all
the messages without any problems into the web UI. It's only EAS that is
failing to download messages.

Knowing full well I'm supposed to have a more current version of Cyrus IMAP
I did try to proxy through a local dovecot instance at version 2.2.10.
Doing this yielded no change whatsoever. The EAS mail symptoms remained
identical (including reactions of the log files), and SOGo's Web UI
continued to work perfectly fine.

Another peculiarity is that Calendar items can sync from Outlook back into
SOGo using EAS, but Outlook is not syncing new items, nor updates in from
SOGo. If I delete a calendar item created in Outlook from within the SOGo
Web UI, Outlook *DOES* seem to identify that calendar item's removal. This
is only pertinent to deleting the item though, updating parameters of the
appointment from within the SOGo Web UI does not cause them to be reflected
in Outlook with EAS.

Contacts on the other hand seem to work just fine, in both directions from
either interface.

All components (except for the test IMAP server which I had no trouble
with) have valid 3rd party certificates installed and working properly.

This is not urgent as SOGo to me is still in somewhat of a pilot phase,
however EAS is the main impetus for me to implement SOGo so helping to make
that component function properly would be greatly appreciated.

-JR
-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Reply via email to