[Tickets #12970] Re: Problems with S/MIME messages when sent to or received from a BlackBerry 10 device using BES
noreply at bugs.horde.org
noreply at bugs.horde.org
Mon Oct 27 01:33:26 UTC 2014
DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.
Ticket URL: https://bugs.horde.org/ticket/12970
------------------------------------------------------------------------------
Ticket | 12970
Updated By | Michael Rubinsky <mrubinsk at horde.org>
Summary | Problems with S/MIME messages when sent to or received
| from a BlackBerry 10 device using BES
Queue | Horde Framework Packages
Version | Git master
Type | Bug
State | Feedback
Priority | 1. Low
Milestone |
Patch |
Owners | Michael Rubinsky
------------------------------------------------------------------------------
Michael Rubinsky <mrubinsk at horde.org> (2014-10-27 01:33) wrote:
> Ok, but what I mean is that MIMESUPPORT is defined when the SYNC >
> OPTIONS is being sent. It only happens when settings things up.
> Afterwards, there is never another SYNC > OPTIONS being sent.
>
> And according to 2.2.3.115.5, these options have to be kept in the
> database and re-used across requests:
> "The server preserves the Options block across requests, using a
> concept referred to as "sticky options". If the Options block is not
> included in a request, the previous Options block is used. "
Correct, and we already do that.
I was misunderstanding what was happening on your end. I thought the
client WAS sending an OPTIONS request, but was just not including the
MIMESUPPORT. We fill in any missing values in
Horde_ActiveSync_SyncCache::validateCollectionsFromCache()
Maybe what is happening is that at some point after the initial sync,
the client IS sending an OPTIONS request either without the
MIMESUPPORT or with it set to 0. This then becomes the cached value of
the OPTIONS to be used when it is omitted.
You can verify that the MIMESUPPORT value is being cached by looking
in the table horde_activesync_cache.
More information about the bugs
mailing list