[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         | 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-26 17:26) wrote:

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

That doesn't matter. It's supposed to be set for each  
fetch/sync/itemoperation to tell the server the client can accept the  
MIME blob. If it's missing, it's assumed to be zero. See MS-ASCMD  
section 2.2.3.100.3.

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

Exactly. This is what the problem is. The client is fetching a S/MIME  
message, but fails to tell the server that it can support it.

> For an encrypted message, there is no itemoperations command being  
> sent when receiving the message

Doesn't matter. It can be requested via a SYNC FETCH, though that  
method is deprecated.

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

If it's not sending non-empty MIMESupport tag, that it's not expecting  
anything related to MIME.

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

As per the specs, if MimeSupport is missing in any request, the  
default value of 0 should be used. See the reference I posted earlier  
in this message.

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

There is no mechanism or expectation in the EAS protocol to use an  
earlier value of just one OPTION field. The client can omit the entire  
collection in a SYNC request, and flag it as a PARTIAL, in which case  
the server falls back to the last SYNC information for that collection  
in it's entirety. If this is what BB is expecting, it's a bug in their  
implementation.