After further investigation, here’s the exact scoop. Since we run our SOGo server internally, there is a default IE10 setting that (for whatever silly reason) automatically sets all intranet sites to use Compatibility View.
I disabled this feature by opening up Group Policy Management MMC and changing the following: User Configuration -> Admin Templates -> Windows Components -> Internet Explorer -> Compatibility View -> Turn on Internet Explorer Standards Mode for local intranet -> Enabled By setting this, a simple logoff (for a domain user) and the issue is resolved. Of course, for non-domain users (or domain users that are not managed by GPO), you may simply disable that setting within the Compatibility View Settings. Thanks again! ~Laz On Jun 3, 2014, at 10:06 AM, Laz C. Peterson <l...@paravis.net> wrote: > Francis — BINGO! As usual … :-) > > The user agent string that should be relayed to SOGo is: Mozilla/5.0 > (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0) > > The user agent string that is actually being reported to SOGo is: Mozilla/4.0 > (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/6.0; SLCC2; .NET CLR > 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; > .NET4.0C; .NET4.0E) > > I believe we have found our culprit! Not sure why, what or how … But it > seems that these domain-based computers are for some reason setting > themselves to compatibility mode for SOGo. Let me check some things out, but > you hit the nail right on the head! > > Thanks again, Francis. > ~Laz > > > On Jun 3, 2014, at 8:39 AM, Francis Lachapelle <flachape...@inverse.ca> wrote: > >> Hi Laz >> >> On Jun 3, 2014, at 11:26 AM, Laz C. Peterson <l...@paravis.net> wrote: >> >>> Yea, upon my investigation, I cannot find anything out of the ordinary as >>> well. >>> >>> It does appear, however, that something within IE10 is “forcing” plain text >>> mode. Do we know how SOGo loads the HTML-based editor? Are there >>> Javascript-related functions that check certain browser functionality >>> before allowing HTML-based editing? Possibly there is some type of policy >>> within IE10 that requires a change? >>> >>> Oddly enough, this issue we are having happens only on domain computers >>> that exist within a certain OU in Active Directory. I would have guessed >>> it was due to a user policy, though when logging in as the local >>> (non-domain) administrator, this problem persists. So it is most >>> definitely an affected system (setting?), versus a particular user. >>> >>> Really, the only user policies that we do change are related to Trusted >>> Sites and the setting to “Low”. And of course, we do include SOGo as a >>> trusted site. >>> >>> We don’t have the option of running another browser, for application and >>> security purposes. (Yes, yes, I know, that statement sounds like I’ve been >>> having a few too many already this morning …) >>> >>> I may try moving systems outside of their OU to try and at least narrow >>> down the issue, but it does seem extremely odd that it would do this. >>> Nothing out of the ordinary has been installed either on our systems. In >>> fact, since our applications are all web-based, we hardly have any local >>> applications to begin with. >> >> Since version 2.2.0, we force the composition mode to be "plain text" when >> using IE 7. But it should not affect IE 10 users .. Unless the useragent is >> not properly parsed by SOPE. >> >> Ref: >> https://github.com/inverse-inc/sogo/commit/ef79c09642009cb7eb74d5261e60bb48e5c2d6b7 >> >> >> Francis-- >> users@sogo.nu >> https://inverse.ca/sogo/lists > > -- > users@sogo.nu > https://inverse.ca/sogo/lists -- users@sogo.nu https://inverse.ca/sogo/lists
