[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 15:22) wrote:

> What do you mean "with mimesupport set at 1 or 2"? This is not a  
> configurable value. It comes from the client and it indicates what  
> the client is able to understand, or what it is expecting to be  
> returned. Changing it on the server side after the client sends it  
> leads to undefined behavior because the device is not longer  
> receiving what it is expecting in return.
>

I set it manually to see what the client would say. Based on my  
comment #32, the client supports type 1. It's defined at provisioning  
time or when adding a collection.
I've verified that the client never sets it in itemoperations for  
unencrypted messages and I think it's normal, as it's an optional  
element, unless the client is fetching a S/MIME message. For an  
encrypted message, there is no itemoperations command being sent when  
receiving the message

> Wait, I'm confused now. You said earlier that the MessageClass was   
> always being set to IPM.Note, and NOT IPM.Note.SMIME. Below, it   
> clearly shows that it IS set correctly.

That's when I manually enable a mimetype. I did it to check what would  
happen later on in the chain if given the mimetype I think it expects.

> This means that the client is NOT requesting the MIME data. You will  
>  never get the full MIME message as long as the client is sending   
> MIMESUPPORT of 0.

The client is not sending mimesupport of 0. Horde is using the default  
value because it could not find it in the request, but a value of 1  
has been sent when adding the collection via a sync command and I  
think that it's the value which should be used since the client is not  
sending an updated value of 0 per example.