Community support is offered through the mailing list. You can subscribe to it and ask questions related to SOGo.

The SOGo community is very large and active so do not hesitate to subscribe to the mailing list and ask questions. However, please make sure to respect the following guidelines when posting a new message :

  • post constructive emails - rants will be automatically discarded
  • consult the FAQ for previously answered questions
  • send plain text message (no HTML or Rich Text) to avoid getting rejected by our spam filters
  • avoid replying to a message on top of the quoted text of the previous correspondence


You can also visit and contribute to the official SOGo Wiki maintained by SOGo users.

Go to the Wiki

Consulting Services

Groupware deployment projects are complex in nature because they usually involve many different technologies. We have done hundreds of large-scale deployment projects for prestigious organizations, all around the world. Let us help you make this deployment project a success by using our unmatched expertise!

If you are looking for a SOGo expert to help you:

  • Install, configure, customize and optimize the solution to meet your needs
  • Perform a pre or post-implementation audit to make sure your SOGo deployment performs optimally
  • Correct a specific issue with your installation or with components related to it
  • Migrate calendars, address books and emails from a previous solution to SOGo
  • Efficiently integrate SOGo with in-house systems (CRM, ERP, portal, etc.)
  • Develop specific features mentioned in the roadmap, vertical to your environment or others

Contact Us

Support Packages

Duration 1 year 1 year 1 year 1 year
Support Method Support Portal Support Portal / Phone Support Portal / Phone Support Portal / Phone
Response Time 1 business day 4 business hours 2 hours 1 hour
Support Hours From 8:00am
to 5:00pm EST/EDT - Monday to Friday
From 8:00am
to 5:00pm EST/EDT - Monday to Friday
24 / 7 24 / 7
Multi-Server No No Yes Yes
Notifications None Security Security / Bug Fixes Security / Bug Fixes
Bug Fixes No No No Yes
Included Incidents 5 10 30 75
Included Consulting Hours - - 2 4
Cost $750 USD
700 €
$1,500 USD
1400 €
$5,000 USD
4600 €
$10,000 USD
9200 €
Order Order Order Order
More incident credits are consumed when support is offered outside 8:00am to 5:00pm EST/EDT - Monday to Friday. Contact us for details.

Supported operating systems:

  • Red Hat Enterprise Linux (RHEL) 5+
  • Community ENTerprise Operating System (CentOS) 5+
  • Debian 4+
  • Ubuntu 8+

The support packages do not include:

  • components installation
  • custom development
  • preventive system monitoring
  • training and documentation

The included consulting hours can be consumed for:

  • architecture design and review
  • migration from another system
  • performance tuning
  • best practices

Reselling SOGo Support

If you want to resell SOGo support contracts to your customers, and even better, participate in providing support, contact us to learn more about the partner programs offered by Inverse.


SOGo - Installation and Configuration Guide
For SOGo version 3.2.10
Mozilla Thunderbird - Installation and Configuration Guide
For SOGo version 3.2.10
Native Microsoft Outlook Configuration Guide
For SOGo version 3.2.10
SOGo - Installation and Configuration Guide
For SOGo version 2.3.23
Mozilla Thunderbird - Installation and Configuration Guide
For SOGo version 2.3.23
Native Microsoft Outlook Configuration Guide
For SOGo version 2.3.23


How do I debug SOGo?


First, make sure you’ve installed the debugging symbols for GNUstep, openchange, samba4, SOGo and SOPE. On RHEL-based distributions, debugging symbols will be located in packages with the “debuginfo” suffix, while on Debian-based distributions, the suffix is “dbg”.

So, on RHEL-based distributions, proceed with the following command:

yum install sogo-debuginfo sope49-debuginfo gnustep-base-debuginfo

On Debian-based distributions, proceed with the following command:

apt-get install libgnustep-base*-dbg sogo-dbg sope4.9-dbg openchangeserver-gdb

On older Debians (Squeeze), the gdb version shipped with the system won’t work with PIE executables. To workaround this problem, a newer gdb must be installed from the backports.

  1. Add this line to /etc/apt/sources.list (or add a new file with the “.list” extension to /etc/apt/sources.list.d/):

    deb squeeze-backports main
  2. Run apt-get update

    1. Install the package apt-get -t squeeze-backports install "gdb"

Using gdb

If you’re only interested in debugging SOGo, make sure it’s first stopped and no “sogod” process is running.

Then, change to the SOGo user and launch SOGo inside gdb:

% su -s /bin/bash - sogo
% gdb --args /usr/sbin/sogod -WOUseWatchDog NO -WONoDetach YES -WOPort 20000 -WOWorkersCount 1 -WOLogFile - -WOPidFile /tmp/

Launch the application using the “run” command (or “r”). This will start SOGo using a single process inside gdb.

Once SOGo is launched, hit Control-C and set breakpoints, like this:

(gdb) b [NSException raise] 
Breakpoint 1 at 0x7ffff5241d90: file NSException.m, line 955. 
(gdb) b abort 
Breakpoint 2 at 0x7ffff5352f50: abort. (2 locations)

Resume’s SOGo state, putting it back into a running one:

(gdb) c 

When the application is about to crash, your breakpoints should be raised:

Breakpoint 1, -[NSException raise] (self=0x55555611fe20, _cmd=0x7ffff56f5f00) at NSException.m:955 

At this point, you can produce a back trace using the “bt” command:

(gdb) bt 
#0  -[NSException raise] (self=0x55555611fe20, _cmd=0x7ffff56f5f00) at NSException.m:955 
#1  0x00007ffff5242231 in +[NSException raise:format:] (self=0x7ffff56f6080, _cmd=<optimized out>, name=0x7ffff56f6220, 
    format=0x7ffff56c57f0) at NSException.m:835 
#2  0x00007ffff51b8e89 in characterAtIndex_c (index=306, self=<optimized out>) at GSString.m:1199 
#3  -[GSMutableString characterAtIndex:] (self=0x555555878630, _cmd=<optimized out>, index=<optimized out>) at GSString.m:3797 
#4  0x00007ffff7b73185 in -[NSString(SOGoURLExtension) _rangeOfURLInRange:] (self=0x555555878630, _cmd=0x7ffff7dc9e00, refRange=...) 
    at NSString+Utilities.m:133 
#5  0x00007ffff7b73732 in -[NSString(SOGoURLExtension) _handleURLs:textToMatch:prefix:inRanges:] (self=0x55555610bbf0, _cmd=0x7ffff7dc9ec0, 
    selfCopy=0x555555878630, match=0x7ffff7dc9240, prefix=0x7ffff7dc9260, ranges=0x555555878b70) at NSString+Utilities.m:202 
#6  0x00007ffff7b73c49 in -[NSString(SOGoURLExtension) stringByDetectingURLs] (self=0x55555610bbf0, _cmd=0x7fffea5b6c80) 
    at NSString+Utilities.m:258 
#7  0x00007fffea3a8537 in -[UIxMailPartTextViewer flatContentAsString] (self=0x555556056070, _cmd=0x5555562d6e00) 
    at UIxMailPartTextViewer.m:48

You can also attach to a running sogod process using gdb. For example, if a sogod process is consuming 100% and its PID is 1234, you can attach to it using “gdb -p 1234”. At this point, you can also produce back traces (“bt” or “bt full”), put the process back in the running state (“c”) or interrupt it (Control-C).

Debugging Samba4 and OpenChange

If you are interested in debugging Samba4/OpenChange, you should install the openchangeserver-dbg package and then make sure no samba processes are running prior launching it from gdb:

% gdb --args /usr/sbin/samba -M single -i -d 10

This will start Samba4 inside gdb using a single samba process. You must make sure that you do NOT use Samba4’s internal LDAP server for authentication in SOGo. If you do this, the authentication code in SOGo will cause a deadlock, because the code path is re-entrant (ie., the running Samba4 process will try to connect to itself using the LDAP-based authentication code triggered by the SOGo code it loads). Debugging Samba4 in multithreaded mode is not an option so if you use Samba4’s internal LDAP server for authentication in SOGo, you should use a temporary SQL-based authentication source for testing purposes.

An alternative method for gathering valuable debugging information for Samba/OpenChange/SOGo is to use the panic action samba parameter in order to automatically get a backtrace if samba crashes.

To do so, fetch the gdb_backtrace script from the samba git repository:

curl ';a=blob_plain;f=selftest/gdb_backtrace;hb=HEAD' >/usr/local/bin/gdb_backtrace
chmod +x /usr/local/bin/gdb_backtrace

Then add the following to the [global] section of smb.conf:

panic action = /usr/local/bin/gdb_backtrace %d 

Finally, restart samba and trigger the bug (or wait for it to happen…). A backtrace should be logged in the samba log file.

Next thing is to file a detailed bug on

July 7, 2016

Bug Tracking System

If you encounter a possible bug with SOGo, you can access our bug tracking system

Please make sure to respect the following guidelines when reporting a bug:

  • verify that the bug you found is not already known or even fixed in the trunk version
  • make the actual facts very clear; be precise, we need to be able to reproduce the problem
  • explain your speculations, if any
  • add a screenshot to the ticket if appropriate