mailcow: dockerized - 🐮 + 🐋 = 💕

Want to support mailcow?

Please consider a support contract with Servercow to support further development. We support you while you support us. :)

You can also get a SAL which is a one-time payment with no liabilities or returning fees.

Or just spread the word: moo.

Many thanks to our GitHub Sponsors ❤️

A big thank you to everyone supporting us on GitHub Sponsors—your contributions mean the world to us! Special thanks to the following amazing supporters:

100$/Month Sponsors

50$/Month Sponsors

Info, documentation and support

Please see the official documentation for installation and support instructions. 🐄

🐛 If you found a critical security issue, please mail us to info at servercow.de.

Cowmunity

mailcow community

Telegram mailcow channel

Telegram mailcow Off-Topic channel

Official 𝕏 (Twitter) Account

Official Mastodon Account

Telegram desktop clients are available for multiple platforms. You can search the groups history for keywords.

Misc

Important: mailcow makes use of various open-source software. Please assure you agree with their license before using mailcow.
Any part of mailcow itself is released under GNU General Public License, Version 3.

mailcow is a registered word mark of The Infrastructure Company GmbH, Parkstr. 42, 47877 Willich, Germany.

The project is managed and maintained by The Infrastructure Company GmbH.

Originated from @andryyy (André)

Contributor Covenant Code of Conduct

Our Pledge

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.

Our Standards

Examples of behavior that contributes to creating a positive environment include:

• Using welcoming and inclusive language
• Being respectful of differing viewpoints and experiences
• Gracefully accepting constructive criticism
• Focusing on what is best for the community
• Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

• The use of sexualized language or imagery and unwelcome sexual attention or advances
• Trolling, insulting/derogatory comments, and personal or political attacks
• Public or private harassment
• Publishing others' private information, such as a physical or electronic address, without explicit permission
• Other conduct which could reasonably be considered inappropriate in a professional setting

Our Responsibilities

Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, documentation edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

Scope

This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at [email protected]. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.

Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.

Attribution

This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at http://contributor-covenant.org/version/1/4

Contribution Guidelines

Last modified on 12th November 2025

First of all, thank you for wanting to provide a bugfix or a new feature for the mailcow community, it's because of your help that the project can continue to grow!

As we want to keep mailcow's development structured we setup these Guidelines which helps you to create your issue/pull request accordingly.

PLEASE NOTE, THAT WE WILL CLOSE ISSUES/PULL REQUESTS IF THEY DON'T FULFILL OUR WRITTEN GUIDELINES WRITTEN INSIDE THIS DOCUMENT. So please check this guidelines before you propose a Issue/Pull Request.

Topics

• Pull Requests
• Issue Reporting
  • Guidelines
  • Issue Report Guide

Pull Requests

Last modified on 15th August 2024

However, please note the following regarding pull requests:

1. ALWAYS create your PR using the staging branch of your locally cloned mailcow instance, as the pull request will end up in said staging branch of mailcow once approved. Ideally, you should simply create a new branch for your pull request that is named after the type of your PR (e.g. feat/ for function updates or fix/ for bug fixes) and the actual content (e.g. sogo-6.0.0 for an update from SOGo to version 6 or html-escape for a fix that includes escaping HTML in mailcow).
2. ALWAYS report/request issues/features in the english language, even though mailcow is a german based company. This is done to allow other GitHub users to reply to your issues/requests too which did not speak german or other languages besides english.
3. Please keep this pull request branch clean and free of commits that have nothing to do with the changes you have made (e.g. commits from other users from other branches). If you make changes to the update.sh script or other scripts that trigger a commit, there is usually a developer mode for clean working in this case.
4. Test your changes before you commit them as a pull request. If possible, write a small test log or demonstrate the functionality with a screenshot or GIF. We will of course also test your pull request ourselves, but proof from you will save us the question of whether you have tested your own changes yourself.
5. Please use the pull request template we provide once creating a pull request. HINT: During editing you encounter comments which looks like: <!-- CONTENT -->. These can be removed or kept, as they will not rendered later on GitHub! Please only create actual content without the said comments.
6. Please ALWAYS create the actual pull request against the staging branch and NEVER directly against the master branch. If you forget to do this, our moobot will remind you to switch the branch to staging.
7. Wait for a merge commit: It may happen that we do not accept your pull request immediately or sometimes not at all for various reasons. Please do not be disappointed if this is the case. We always endeavor to incorporate any meaningful changes from the community into the mailcow project.
8. If you are planning larger and therefore more complex pull requests, it would be advisable to first announce this in a separate issue and then start implementing it after the idea has been accepted in order to avoid unnecessary frustration and effort!
9. If your PR requires a Docker image rebuild (changes to Dockerfiles or files in data/Dockerfiles/), update the image tag in docker-compose.yml. Use the base-image versioning (e.g. ghcr.io/mailcow/sogo:5.12.4 → :5.12.5 for version bumps; append a letter for patch fixes, e.g. :5.12.4a). Follow this scheme.

Issue Reporting

Last modified on 12th November 2025

If you plan to report a issue within mailcow please read and understand the following rules:

Security disclosures / Security-related fixes

• Security vulnerabilities and security fixes must always be reported confidentially first to the contact address specified in SECURITY.md before they are integrated, published, or publicly disclosed in issues/PRs. Please wait for a response from the specified contact to ensure coordinated and responsible disclosure.

Issue Reporting Guidelines

1. ONLY use the issue tracker for bug reports or improvement requests and NOT for support questions. For support questions you can either contact the mailcow community on Telegram or the mailcow team directly in exchange for a support fee.
2. ONLY report an error if you have the necessary know-how (at least the basics) for the administration of an e-mail server and the usage of Docker. mailcow is a complex and fully-fledged e-mail server including groupware components on a Docker basement and it requires a bit of technical know-how for debugging and operating.
3. ALWAYS report/request issues/features in the english language, even though mailcow is a german based company. This is done to allow other GitHub users to reply to your issues/requests too which did not speak german or other languages besides english.
4. ONLY report bugs that are contained in the latest mailcow release series. The definition of the latest release series includes the last major patch (e.g. 2023-12) and all minor patches (revisions) below it (e.g. 2023-12a, b, c etc.). New issue reports published starting from January 1, 2024 must meet this criterion, as versions below the latest releases are no longer supported by us.
5. When reporting a problem, please be as detailed as possible and include even the smallest changes to your mailcow installation. Simply fill out the corresponding bug report form in detail and accurately to minimize possible questions.
6. Before you open an issue/feature request, please first check whether a similar request already exists in the mailcow tracker on GitHub. If so, please include yourself in this request.
7. When you create a issue/feature request: Please note that the creation does not guarantee an instant implementation or fix by the mailcow team or the community.
8. Please ALWAYS anonymize any sensitive information in your bug report or feature request before submitting it.

Issue Report Guide

1. Read your logs; follow them to see what the reason for your problem is.
2. Follow the leads given to you in your logfiles and start investigating.
3. Restarting the troubled service or the whole stack to see if the problem persists.
4. Read the documentation of the troubled service and search its bugtracker for your problem.
5. Search our issues for your problem.
6. Create an issue over at our GitHub repository if you think your problem might be a bug or a missing feature you badly need. But please make sure, that you include all the logs and a full description to your problem.
7. Ask your questions in our community-driven support channels.

When creating an issue/feature request or a pull request, you will be asked to confirm these guidelines.

Security Policies and Procedures

This document outlines security procedures and general policies for the mailcow: dockerized project as found on mailcow-dockerized.

• Reporting a Vulnerability
• Disclosure Policy
• Comments on this Policy

Reporting a Vulnerability

The mailcow team and community take all security vulnerabilities
seriously. Thank you for improving the security of our open source
software. We appreciate your efforts and responsible disclosure and will
make every effort to acknowledge your contributions.

Report security vulnerabilities by emailing the mailcow team at:

info at servercow.de

mailcow team will acknowledge your email as soon as possible, and will
send a more detailed response afterwards indicating the next steps in
handling your report. After the initial reply to your report, the mailcow
team will endeavor to keep you informed of the progress towards a fix and
full announcement, and may ask for additional information or guidance.

Report security vulnerabilities in third-party modules to the person or
team maintaining the module.

Disclosure Policy

When the mailcow team receives a security bug report, they will assign it
to a primary handler. This person will coordinate the fix and release
process, involving the following steps:

• Confirm the problem and determine the affected versions.
• Audit code to find any potential similar problems.
• Prepare fixes for all releases still under maintenance.

Comments on this Policy

If you have suggestions on how this process could be improved please submit a
pull request.