[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]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://bugs.horde.org/ticket/12970
------------------------------------------------------------------------------
  Ticket             | 12970
  Updated By         | software-horde at interfasys.ch
  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
------------------------------------------------------------------------------


software-horde at interfasys.ch (2014-10-26 18:16) wrote:

> There is no such thing as "being defined" in EAS. The only time we  
> look at previously sent values for a collection's OPTIONS is when  
> the client issues a PARTIAL SYNC. Then we load the ENTIRE previously  
> requested collection data. If a SYNC request sends an OPTIONS  
> structure, it MUST contain the MIMESUPPORT field, or it defaults to 0.

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. "


Regarding the patch, it's half working.

For the encrypted message, same as before in the logs, but the device  
now knows it's an encrypted message, but still receives it as HTML and  
can't decrypt it.

For signed messages, there are now extra steps.
First the message is the usual HTML one with no MIMESUPPORT in  
getMessage, but then it triggers an itemoperation which includes  
MIMESUPPORT.