General discussion on installation and configuration of SOGo

Text archives Help


Re: [SOGo] Issue with SOGoMailComposeMessageType


Chronological Thread 
  • From: "Laz C. Peterson" < >
  • To:
  • Subject: Re: [SOGo] Issue with SOGoMailComposeMessageType
  • Date: Tue, 3 Jun 2014 11:38:21 -0700

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
< >
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
> < >
> wrote:
>
>> Hi Laz
>>
>> On Jun 3, 2014, at 11:26 AM, Laz C. Peterson
>> < >
>> 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--
>>
>> https://inverse.ca/sogo/lists
>
> --
>
> https://inverse.ca/sogo/lists




Archive powered by MHonArc 2.6.18.

Top of page