How to Contact the Open-Xchange Support
In order to contact Open-Xchange support you will need two things: a license key and a customer ID. If you have already signed up for Open-Xchange support then you should have received an email containing both these items.
In case you have lost or haven’t received this email, please send us an email and ask for your license key details.
The License Key entitles you to use a purchased product and/or get updates. This entitlement is valid for a specified period of time and for a number of licensed users. It may also include the ability to contact Open-Xchange support too. Please note that Open-Xchange activates all provided license key.
The customer ID identifies you as an Open-Xchange customer and gives you access to the Open-Xchange Portal.
You are entitled to advanced support if you:
- have obtained one of Open-Xchange's support offerings.
- have registered all your support keys (you will have received these after purchasing your support offering) and have an issue with your Open-Xchange product.
- have regularly updated to the latest available release (Open-Xchange Version Support Commitment).
To contact Open-Xchange:
- Send an email to support(at)open-xchange.com
- Provide the following information in the email body:
Support Key: OX-SUPPORT-OR-LICENSE-KEY-XXX
Server: url of the machine
Server Version: server version or package list
Platform: Please choose one from possible values.
Environment: Staging or Production
GUI Version: GUI version or package list
Category: Please choose one from possible values.
Severity: 4, 3, 2, 1 (see description of Severity Levels)
Track-ID: the customer's internal tracking number, e.g. from its Bugzilla
Product: Please choose one from possible values.
Date/time of last changes to configuration or installing updates (with description) or any other changes that were done
within at least the last 24 hours or ...
Steps to reproduce:
Provide a detailed description of the issue/incident and ideally a step-by-step description
Used OS/Browser/Client (with version):
Date/time of test (with timezone):
Current behaviour / Error or Unexpected Results (Date/time):
(Test account to reproduce issue: )
Additional information needed within a newly opened ticket? Click here.
Please note that Open-Xchange can only guarantee a fast responses if the report is submitted in English.
The severity of an incident determines the impact it has on your business and in turn the urgency we place on solving the incident.
Please note that Open-Xchange's response time depends on both the severity and your service level agreement.
If all information has been provided, and is clear, you will receive a confirmation email directly from the Open-Xchange ticket system. This email will contain a ticket number that identifies this incident.
Customers with a valid support license have access to all their tickets via the Open-Xchange ticket system (OTRS). The ticket system provides additional features for communication between you and Open-Xchange, but it is not meant as a full substitution of email conversation.
The following user guide provides an overview about the Open-Xchange ticket system.
If you are an Open-Xchange customer, you are able to file bug reports, via e-mail, to our support engineers. Please check How to contact the Open-Xchange Support for information on how to report a bug. The benefit to you is that reports are handled as a regular support ticket. The Open-Xchange support team validates it and then provides you with progress updates on the filed report.
Open-Xchange Severity Levels
Shall mean Incidents that are defined as a complete outage of either a Primary Service (e.g. IMAP, POP3, SMTP, or the WebUI and depends on the supported components of the Joint Solution Environment) or an interruption or malfunction causing a critical impact on Customer’s business with no possible Workaround, meaning it affects more than 35% of the Users deployed on the system.
It also means a concrete security threat causing an imminent risk to the Customer’s or a User’s data integrity to lead to an unintended data disclosure.
This means that the Customer’s business is severely disrupted. This is the case when a Primary Service (e.g. IMAP, POP3, SMTP, or the WebUI and depends on the supported components of the Joint Solution Environment) is performing below the defined Performance Threshold or cannot be used by more than 10% of the provisioned Users on the system. A major functionality (e.g. search function, the ability of users to create new contacts), or a Secondary Service (e.g. Provisioning API, CalDAV, CardDAV, OX Documents and depends on the supported components of the Joint Solution Environment) cannot be used by more than 35% of the Users.
Shall mean Incidents, which involve partial loss of non-critical functionality, one that impairs many operations, but allows the Customer to continue to operate. It also means issues occurring in a Staging Environment that would normally cause a Severity 1 or Severity 2 Incident to the Production Environment.
Shall mean general usage questions, recommendations for product enhancements or modifications, documentation, translation errors and all other issues not qualify for a Severity defined above.
According to German law, companies are forced to handle any (log) files from customers which contain data related to a third person or has any personal protection in a special way. Personal data shall mean any information concerning the personal or material circumstances of an identified or identifiable natural person. Even so they have to be deleted once they aren't used any more. To fulfil this requirement, customers and support agents have to keep the readable ticket communication, in form of email/article body, subject or attachment names, free from any personal data. This can be every thing from names, email addresses, screen-shots, logs files and even credentials to system accounts. This personal data only has to be handed over in form of attachments which was common practice before. Transfer channels for personal data are attachments via the ticket system, attachment in encrypted emails or provided by protected download links. How to send encrypted emails via PGP is described here.
The integrity of an 'Incident Request' with all available data needs to be saved up to 90 days after a ticket was closed to ensure a holistic assessment in case of Contractual complaints. This time frame is mandatory and gives also the customer time for detailed tests. In case of reopening an incident within these three months all information is still available and needs not to be recollected by customers and end users.
Open-Xchange introduced a weekly deletion process, the deletion work on ticket attachments and on raw email files which are affected by attachments. The automatic deletion of all ticket attachments takes place weekly at Sunday and affects all tickets which are in a 'closed' state since 90 days.
Security Patch Release
Open-Xchange takes security related topics very seriously. In order to provide customers, and their users, a safe and reliable working environment, security vulnerabilities are handled with a high priority and are covered by an optimized delivery process. We believe that security issues must be communicated openly, while at the same time protecting customers that may be affected by that issue.
To provide input to the software security community we publish all security issues. This is done once the issue has been identified, a Patch Release has been provided to our customers, and they have had sufficient time to respond and roll out the Patch Release. It is for this reason that we have chosen a hybrid model of responsible-disclosure, and full-disclosure, when announcing vulnerabilities. Open-Xchange is very eager to get feedback from the security community about unknown issues. We are committed to resolve them quickly without bureaucracy or hassle. Vulnerabilities are discussed within Open-Xchange, prior to providing a Security Patch Release. This ensures that customers can request deployment information from their Support or Services contacts.
Metrics and Frameworks
When vulnerabilities are discovered, either internally at Open-Xchange or externally, they first get evaluated. We use industry standard metrics such as CVSS (Common Vulnerability Scoring System), CWE (Common Weakness Enumeration) and get identified by CVE-IDs (Common Vulnerability and Exposures). This information is then made available through Patch Release Notes, once the vulnerability has been solved. The Release Notes do not contain specific information about the vulnerability. This makes sure that customers are protected until public disclosure is attained.
Public disclosure is achieved by using the “full-disclosure” Mailing List. The posts contain detailed information about the vulnerability as well as a history of the vulnerabilities discovery process. These postings can be used to map CVE-Identifiers from the Release Notes with a detailed description of the vulnerability. The public announcement usually takes place within 5 to 10 business days after a Security Patch Release has been provided to all customers. To avoid exploitation of a known security issues, please make sure to update your systems to a Security Patch Release as quickly as possible.
Please note that Security Patch Releases are provided for Open-Xchange software versions that are supported at the time of vulnerability discovery.