Tickets :: Comment on [#12970] Don't override sticky OPTIONS values with default values.

* Your Email Address
* Spam protection	Enter the letters below: .___. ..__ .__.. . [__ \| \|[__)\| \|\|_/ [___\|__\|[__)\|__\\| \
Comment	>> 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.
Attachment
Watch this ticket

Saved Queries