2021-03-10 04:30:57 +00:00
# Site specific:
2021-02-28 11:53:15 +00:00
site_name : 'Docker Mailserver'
docs(chore): Normalize for consistency (#2206)
"Brief" summary/overview of changes. See the PR discussion or individual commits from the PR for more details.
---
Only applies to the `docs/content/**` content (_and `setup` command_). `target/` and `test/` can be normalized at a later date.
* Normalize to `example.com`
- Domains normalized to `example.com`: `mywebserver.com`, `myserver.tld`, `domain.com`, `domain.tld`, `mydomain.net`, `my-domain.tld`, `my-domain.com`, `example.org`, `whoami.com`.
- Alternative domains normalized to `not-example.com`: `otherdomain.com`, `otherdomain.tld`, `domain2.tld`, `mybackupmx.com`, `whoareyou.org`.
- Email addresses normalized to `admin@example.com` (in `ssl.md`): `foo@bar.com`, `yourcurrentemail@gmail.com`, `email@email.com`, `admin@domain.tld`.
- Email addresses normalized to `external-account@gmail.com`: `bill@gates321boom.com`, `external@gmail.com`, `myemail@gmail.com`, `real-email-address@external-domain.com`.
- **`faq.md`:** A FAQ entry title with `sample.domain.com` changed to `subdomain.example.com`.
- **`mail-fetchmail.md`:** Config examples with FQDNs for `imap`/`pop3` used `example.com` domain for a third-party, changed to `gmail.com` as more familiar third-party/external MTA.
* Normalize config volume path
- Normalizing local config path references to `./docker-data/dms/config/`: `./config/`, `config/`, \``config`\`, `/etc/` (_volume mount src path prefix_).
- Normalize DMS volume paths to `docker-data/dms/mail-{data,state,log}`: `./mail`, `./mail-state` `./data/mail`, `./data/state`, `./data/logs`, `./data/maildata`, `./data/mailstate`, `./data/maillogs`, (_dropped/converted data volumes: `maildata`, `mailstate`_).
- Other docker images also adopt the `docker-data/{service name}/` prefix.
* `ssl.md` - Use `dms/custom-certs` where appropriate.
* Apply normalizations to README and example `docker-compose.yml`
---
Common terms, sometimes interchangeably used or now invalid depending on context: `mail`, `mail container`, `mail server`, `mail-server`, `mailserver`,`docker-mailserver`, `Docker Mailserver`.
Rough transformations applied to most matches (_conditionally, depending on context_):
- 'Docker Mailserver' => '`docker-mailserver`'
- 'mail container' => '`docker-mailserver`' (_optionally retaining ' container'_)
- 'mail server' => 'mail-server' / '`docker-mailserver`'
- 'mail-server' => '`docker-mailserver`'
- 'mailserver' => 'mail-server' / '`docker-mailserver`'
Additionally I checked `docker run` (_plus `exec`, `logs`, etc, sub-commands_) and `docker-compose` commands. Often finding usage of `mail` instead of the expected `mailserver`
Additionally changes `mailserver` hostname in k8s to `mail` to align with other non-k8s examples.
---
* drive-by revisions
Mostly minor revisions or improvements to docs that aren't related to normalization effort.
2021-09-22 23:29:37 +00:00
site_description : 'A fullstack but simple mail-server (SMTP, IMAP, LDAP, Antispam, Antivirus, etc.) using Docker.'
2021-02-28 11:53:15 +00:00
site_author : 'docker-mailserver (Github Organization)'
2021-03-10 04:30:57 +00:00
copyright : '<p>© <a href="https://github.com/docker-mailserver"><em>Docker Mailserver Organization</em></a><br/><span>This project is licensed under the MIT license.</span></p>'
# Project source specific:
2021-02-28 11:53:15 +00:00
repo_name : 'docker-mailserver'
repo_url : 'https://github.com/docker-mailserver/docker-mailserver'
2021-03-10 04:30:57 +00:00
# All docs `edit` button will go to this subpath of the `repo_url`:
# For versioned docs, this may be a little misleading for a user not viewing the `edge` docs which match the `master` branch.
2021-03-02 17:48:28 +00:00
edit_uri : 'edit/master/docs/content'
2021-03-10 04:30:57 +00:00
# The main docs content lives here, any files will be copied over to the deployed version,
# unless the file or directory name is prefixed with a `.`
2021-02-28 11:53:15 +00:00
docs_dir : 'content/'
2021-03-10 04:30:57 +00:00
# Canonical URL (HTML content instructs search engines that this is where the preferred version of the docs is located, useful when we have duplicate content like versioned docs)
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs#using_%3Clink_relcanonical%3E
# Also required for `sitemap.xml` generation at build time; which bots use to assist them crawling and indexing a website,
# the `mkdocs-material` 'Instant Navigation' feature utilizes the sitemap data to work.
docs(ci): Deploy Previews (#1988)
* docs(ci): Support deploy previews for documentation
Each PR that contributes to docs will generate a unique (to that PR) URL to preview the PR live for review.
* docs(ci): Split workflow
To support previews from non-collaborators PR contributions, we cannot rely on secrets access from workflows triggered by the `pull_request` event.
To do so securely, according to official advice from Github, we must run the third-party contribution in the restricted `pull_request` context, and then use a 2nd workflow to deploy the build (which requires secrets access).
* docs(ci): Rename doc workflows + add commit status
Better naming convention for documentation workflows.
Split workflow only indicated status on PR of the 1st stage (building the preview to deploy), not the deployment progress/result. This needs to be managed more directly until the action better supports split-workflow scenario.
* docs(ci): Add concurrency limit to preview deploy workflow
This would be more ideal on the 2nd phase workflow (`workflow_run`), however keeping it simple for now.
Limits the concurrency of the initial pull request workflow for documentation contributions that have PRs with multiple event triggers in a small time span (before the workflow triggered would complete). The main benefit is to avoid redundant deploys if the initial workflow has been triggered again to build the PR once more. It only will work against concurrent workflows for that PR in the 1st stage, if an existing `workflow_run` (2nd stage) is active for that PR it will not be cancelled.
* docs(ci): Add sponsor branding for deploy preview service
A requirement from Netlify for the [sponsored OSS organization plan](https://www.netlify.com/legal/open-source-policy).
* docs(ci): Use a shared build script
Production and Deploy Preview builds are now maintained via the same shell command, so version updates of docker image is in one place.
Additionally deletes unnecessary build output which upstream provides no support to exclude.
* docs: Add a custom 404 page
This is used by the preview deploys on Netlify. Production deploys on Github Pages require a top-level 404 page manually deployed (since all are deployed to a version subpath).
This 404 page was custom built and optimized by me. This is the final minified output, separate source to build is available if needed.
---
Likewise the `favicon.ico` is a fallback for browsers that implicitly check the domain root for this file if the SVG isn't supported/preferred. Browsers check for this file without it being present in the HTML head meta elements.
On Github Pages the `favicon.ico` isn't likely to be picked up by even top-level as typical deployment has the project name as a subpath. The docs however reference a PNG favicon which should be widely supported.
The `favicon.ico` was generated by RealFaviconGenerator online tool with SVG source input. It contains 16px, 32px and 48px sizes. Quality is better than the `favicon.io` generator.
* chore: Optimized logo
SVG source cleaned up and optimized with SVGO 2.3.
Minified versions (`.min.svg` extension) remove unnecessary data and white-space to reduce size further for production use. This extension better differentiates by filename that it's different from the `src` version.
2021-05-20 10:24:46 +00:00
site_url : 'https://docker-mailserver.github.io/docker-mailserver/edge/'
2021-03-10 04:30:57 +00:00
# Anything related to the `mkdocs-material` theme config goes here:
2021-02-28 11:53:15 +00:00
theme :
name : 'material'
docs(ci): Deploy Previews (#1988)
* docs(ci): Support deploy previews for documentation
Each PR that contributes to docs will generate a unique (to that PR) URL to preview the PR live for review.
* docs(ci): Split workflow
To support previews from non-collaborators PR contributions, we cannot rely on secrets access from workflows triggered by the `pull_request` event.
To do so securely, according to official advice from Github, we must run the third-party contribution in the restricted `pull_request` context, and then use a 2nd workflow to deploy the build (which requires secrets access).
* docs(ci): Rename doc workflows + add commit status
Better naming convention for documentation workflows.
Split workflow only indicated status on PR of the 1st stage (building the preview to deploy), not the deployment progress/result. This needs to be managed more directly until the action better supports split-workflow scenario.
* docs(ci): Add concurrency limit to preview deploy workflow
This would be more ideal on the 2nd phase workflow (`workflow_run`), however keeping it simple for now.
Limits the concurrency of the initial pull request workflow for documentation contributions that have PRs with multiple event triggers in a small time span (before the workflow triggered would complete). The main benefit is to avoid redundant deploys if the initial workflow has been triggered again to build the PR once more. It only will work against concurrent workflows for that PR in the 1st stage, if an existing `workflow_run` (2nd stage) is active for that PR it will not be cancelled.
* docs(ci): Add sponsor branding for deploy preview service
A requirement from Netlify for the [sponsored OSS organization plan](https://www.netlify.com/legal/open-source-policy).
* docs(ci): Use a shared build script
Production and Deploy Preview builds are now maintained via the same shell command, so version updates of docker image is in one place.
Additionally deletes unnecessary build output which upstream provides no support to exclude.
* docs: Add a custom 404 page
This is used by the preview deploys on Netlify. Production deploys on Github Pages require a top-level 404 page manually deployed (since all are deployed to a version subpath).
This 404 page was custom built and optimized by me. This is the final minified output, separate source to build is available if needed.
---
Likewise the `favicon.ico` is a fallback for browsers that implicitly check the domain root for this file if the SVG isn't supported/preferred. Browsers check for this file without it being present in the HTML head meta elements.
On Github Pages the `favicon.ico` isn't likely to be picked up by even top-level as typical deployment has the project name as a subpath. The docs however reference a PNG favicon which should be widely supported.
The `favicon.ico` was generated by RealFaviconGenerator online tool with SVG source input. It contains 16px, 32px and 48px sizes. Quality is better than the `favicon.io` generator.
* chore: Optimized logo
SVG source cleaned up and optimized with SVGO 2.3.
Minified versions (`.min.svg` extension) remove unnecessary data and white-space to reduce size further for production use. This extension better differentiates by filename that it's different from the `src` version.
2021-05-20 10:24:46 +00:00
custom_dir : 'overrides/'
2021-03-04 12:39:26 +00:00
favicon : assets/logo/favicon-32x32.png
docs(ci): Deploy Previews (#1988)
* docs(ci): Support deploy previews for documentation
Each PR that contributes to docs will generate a unique (to that PR) URL to preview the PR live for review.
* docs(ci): Split workflow
To support previews from non-collaborators PR contributions, we cannot rely on secrets access from workflows triggered by the `pull_request` event.
To do so securely, according to official advice from Github, we must run the third-party contribution in the restricted `pull_request` context, and then use a 2nd workflow to deploy the build (which requires secrets access).
* docs(ci): Rename doc workflows + add commit status
Better naming convention for documentation workflows.
Split workflow only indicated status on PR of the 1st stage (building the preview to deploy), not the deployment progress/result. This needs to be managed more directly until the action better supports split-workflow scenario.
* docs(ci): Add concurrency limit to preview deploy workflow
This would be more ideal on the 2nd phase workflow (`workflow_run`), however keeping it simple for now.
Limits the concurrency of the initial pull request workflow for documentation contributions that have PRs with multiple event triggers in a small time span (before the workflow triggered would complete). The main benefit is to avoid redundant deploys if the initial workflow has been triggered again to build the PR once more. It only will work against concurrent workflows for that PR in the 1st stage, if an existing `workflow_run` (2nd stage) is active for that PR it will not be cancelled.
* docs(ci): Add sponsor branding for deploy preview service
A requirement from Netlify for the [sponsored OSS organization plan](https://www.netlify.com/legal/open-source-policy).
* docs(ci): Use a shared build script
Production and Deploy Preview builds are now maintained via the same shell command, so version updates of docker image is in one place.
Additionally deletes unnecessary build output which upstream provides no support to exclude.
* docs: Add a custom 404 page
This is used by the preview deploys on Netlify. Production deploys on Github Pages require a top-level 404 page manually deployed (since all are deployed to a version subpath).
This 404 page was custom built and optimized by me. This is the final minified output, separate source to build is available if needed.
---
Likewise the `favicon.ico` is a fallback for browsers that implicitly check the domain root for this file if the SVG isn't supported/preferred. Browsers check for this file without it being present in the HTML head meta elements.
On Github Pages the `favicon.ico` isn't likely to be picked up by even top-level as typical deployment has the project name as a subpath. The docs however reference a PNG favicon which should be widely supported.
The `favicon.ico` was generated by RealFaviconGenerator online tool with SVG source input. It contains 16px, 32px and 48px sizes. Quality is better than the `favicon.io` generator.
* chore: Optimized logo
SVG source cleaned up and optimized with SVGO 2.3.
Minified versions (`.min.svg` extension) remove unnecessary data and white-space to reduce size further for production use. This extension better differentiates by filename that it's different from the `src` version.
2021-05-20 10:24:46 +00:00
logo : assets/logo/dmo-logo-white.min.svg
2021-02-28 11:53:15 +00:00
icon :
repo : fontawesome/brands/github
features :
- navigation.tabs
2021-04-08 10:27:37 +00:00
- navigation.top
2021-02-28 11:53:15 +00:00
- navigation.expand
2021-03-11 03:49:43 +00:00
- navigation.instant
2023-05-14 21:54:53 +00:00
- content.action.edit
- content.action.view
2021-12-13 07:43:01 +00:00
- content.code.annotate
2021-04-08 10:27:37 +00:00
palette :
# Light mode
docs(ci): Deploy Previews (#1988)
* docs(ci): Support deploy previews for documentation
Each PR that contributes to docs will generate a unique (to that PR) URL to preview the PR live for review.
* docs(ci): Split workflow
To support previews from non-collaborators PR contributions, we cannot rely on secrets access from workflows triggered by the `pull_request` event.
To do so securely, according to official advice from Github, we must run the third-party contribution in the restricted `pull_request` context, and then use a 2nd workflow to deploy the build (which requires secrets access).
* docs(ci): Rename doc workflows + add commit status
Better naming convention for documentation workflows.
Split workflow only indicated status on PR of the 1st stage (building the preview to deploy), not the deployment progress/result. This needs to be managed more directly until the action better supports split-workflow scenario.
* docs(ci): Add concurrency limit to preview deploy workflow
This would be more ideal on the 2nd phase workflow (`workflow_run`), however keeping it simple for now.
Limits the concurrency of the initial pull request workflow for documentation contributions that have PRs with multiple event triggers in a small time span (before the workflow triggered would complete). The main benefit is to avoid redundant deploys if the initial workflow has been triggered again to build the PR once more. It only will work against concurrent workflows for that PR in the 1st stage, if an existing `workflow_run` (2nd stage) is active for that PR it will not be cancelled.
* docs(ci): Add sponsor branding for deploy preview service
A requirement from Netlify for the [sponsored OSS organization plan](https://www.netlify.com/legal/open-source-policy).
* docs(ci): Use a shared build script
Production and Deploy Preview builds are now maintained via the same shell command, so version updates of docker image is in one place.
Additionally deletes unnecessary build output which upstream provides no support to exclude.
* docs: Add a custom 404 page
This is used by the preview deploys on Netlify. Production deploys on Github Pages require a top-level 404 page manually deployed (since all are deployed to a version subpath).
This 404 page was custom built and optimized by me. This is the final minified output, separate source to build is available if needed.
---
Likewise the `favicon.ico` is a fallback for browsers that implicitly check the domain root for this file if the SVG isn't supported/preferred. Browsers check for this file without it being present in the HTML head meta elements.
On Github Pages the `favicon.ico` isn't likely to be picked up by even top-level as typical deployment has the project name as a subpath. The docs however reference a PNG favicon which should be widely supported.
The `favicon.ico` was generated by RealFaviconGenerator online tool with SVG source input. It contains 16px, 32px and 48px sizes. Quality is better than the `favicon.io` generator.
* chore: Optimized logo
SVG source cleaned up and optimized with SVGO 2.3.
Minified versions (`.min.svg` extension) remove unnecessary data and white-space to reduce size further for production use. This extension better differentiates by filename that it's different from the `src` version.
2021-05-20 10:24:46 +00:00
- media: '(prefers-color-scheme : light)'
2021-04-08 10:27:37 +00:00
scheme : default
primary : indigo
accent : indigo
toggle :
icon : material/weather-night
name : Switch to dark mode
# Dark mode
docs(ci): Deploy Previews (#1988)
* docs(ci): Support deploy previews for documentation
Each PR that contributes to docs will generate a unique (to that PR) URL to preview the PR live for review.
* docs(ci): Split workflow
To support previews from non-collaborators PR contributions, we cannot rely on secrets access from workflows triggered by the `pull_request` event.
To do so securely, according to official advice from Github, we must run the third-party contribution in the restricted `pull_request` context, and then use a 2nd workflow to deploy the build (which requires secrets access).
* docs(ci): Rename doc workflows + add commit status
Better naming convention for documentation workflows.
Split workflow only indicated status on PR of the 1st stage (building the preview to deploy), not the deployment progress/result. This needs to be managed more directly until the action better supports split-workflow scenario.
* docs(ci): Add concurrency limit to preview deploy workflow
This would be more ideal on the 2nd phase workflow (`workflow_run`), however keeping it simple for now.
Limits the concurrency of the initial pull request workflow for documentation contributions that have PRs with multiple event triggers in a small time span (before the workflow triggered would complete). The main benefit is to avoid redundant deploys if the initial workflow has been triggered again to build the PR once more. It only will work against concurrent workflows for that PR in the 1st stage, if an existing `workflow_run` (2nd stage) is active for that PR it will not be cancelled.
* docs(ci): Add sponsor branding for deploy preview service
A requirement from Netlify for the [sponsored OSS organization plan](https://www.netlify.com/legal/open-source-policy).
* docs(ci): Use a shared build script
Production and Deploy Preview builds are now maintained via the same shell command, so version updates of docker image is in one place.
Additionally deletes unnecessary build output which upstream provides no support to exclude.
* docs: Add a custom 404 page
This is used by the preview deploys on Netlify. Production deploys on Github Pages require a top-level 404 page manually deployed (since all are deployed to a version subpath).
This 404 page was custom built and optimized by me. This is the final minified output, separate source to build is available if needed.
---
Likewise the `favicon.ico` is a fallback for browsers that implicitly check the domain root for this file if the SVG isn't supported/preferred. Browsers check for this file without it being present in the HTML head meta elements.
On Github Pages the `favicon.ico` isn't likely to be picked up by even top-level as typical deployment has the project name as a subpath. The docs however reference a PNG favicon which should be widely supported.
The `favicon.ico` was generated by RealFaviconGenerator online tool with SVG source input. It contains 16px, 32px and 48px sizes. Quality is better than the `favicon.io` generator.
* chore: Optimized logo
SVG source cleaned up and optimized with SVGO 2.3.
Minified versions (`.min.svg` extension) remove unnecessary data and white-space to reduce size further for production use. This extension better differentiates by filename that it's different from the `src` version.
2021-05-20 10:24:46 +00:00
- media: '(prefers-color-scheme : dark)'
2021-04-08 10:27:37 +00:00
scheme : slate
primary : indigo
accent : blue
toggle :
icon : material/weather-sunny
name : Switch to light mode
2021-03-11 03:49:43 +00:00
2021-03-10 04:30:57 +00:00
# We make some minor style adjustments or resolve issues that upstream `mkdocs-material` would not accept a PR for:
2021-03-11 03:49:43 +00:00
extra_css :
- assets/css/customizations.css
2021-02-28 11:53:15 +00:00
2021-03-11 04:57:16 +00:00
# We do not use `mike`, but enabling this will enable the version selector UI.
# It references `versions.json` on `gh-pages` branch,
# however we have a basic setup that only matches `version` to a subdirectory.
extra :
version :
provider : mike
2021-03-10 04:30:57 +00:00
# Various extensions for `mkdocs` are enabled and configured here to extend supported markdown syntax/features.
2021-02-28 11:53:15 +00:00
markdown_extensions :
- toc :
2021-03-11 03:49:43 +00:00
anchorlink : true
2021-02-28 11:53:15 +00:00
- abbr
- attr_list
- admonition
2021-03-01 10:41:19 +00:00
- pymdownx.details
2022-02-19 20:26:56 +00:00
- pymdownx.superfences :
custom_fences :
- name : mermaid
class : mermaid
format : !!python/name:pymdownx.superfences.fence_code_format
2023-04-10 10:08:58 +00:00
- pymdownx.tabbed :
alternate_style : true
2021-03-10 04:30:57 +00:00
- pymdownx.magiclink
2021-04-01 20:44:31 +00:00
- pymdownx.inlinehilite
2021-09-11 23:29:02 +00:00
- pymdownx.tilde
2021-03-10 04:30:57 +00:00
- pymdownx.emoji :
emoji_index : !!python/name:materialx.emoji.twemoji
emoji_generator : !!python/name:materialx.emoji.to_svg
2021-02-28 11:53:15 +00:00
- pymdownx.highlight :
extend_pygments_lang :
- name : yml
lang : yaml
- name : cf
lang : cfg
- name : conf
lang : cfg
2021-03-01 10:41:19 +00:00
- name : env
lang : properties
# Not helpful with Python Pygments lexer highlighting, but we might change to a JS highlighter in future
# Ideally, this type of codefence might also have word-wrap enabled (CSS: {white-space: pre-wrap})
- name : log
lang : shell-session
- name : fetchmailrc
lang : txt
2023-05-23 15:25:08 +00:00
- name : getmailrc
lang : txt
2021-03-01 10:41:19 +00:00
- name : caddyfile
lang : txt
2021-03-02 17:48:28 +00:00
2021-03-10 04:30:57 +00:00
# Hard-coded navigation list. Key(UI label): Value(relative filepath from `docs_dir`).
# - If referencing a file more than once, the URLs will all point to the nav hierarchy of the last file reference entry. That usually breaks UX, try avoid it.
# - The top-level elements are presented as tabs (due to `theme.features.navigation.tabs`).
# - Nested elements appear in the sidebar (left) of each tabs page.
# - 3rd level and beyond are automatically expanded in the sidebar instead of collapsed (due to `theme.features.navigation.expand`)
2021-03-02 17:48:28 +00:00
nav :
- 'Home' : index.md
- 'Introduction' : introduction.md
2023-02-19 12:25:14 +00:00
- 'Usage' : usage.md
2021-03-02 17:48:28 +00:00
- 'Configuration' :
2021-05-11 10:15:34 +00:00
- 'Environment Variables' : config/environment.md
2023-04-09 09:27:00 +00:00
- 'User Management' : config/user-management.md
2021-03-02 17:48:28 +00:00
- 'Best Practices' :
2023-04-10 10:08:58 +00:00
- 'DKIM, DMARC & SPF' : config/best-practices/dkim_dmarc_spf.md
2021-03-02 17:48:28 +00:00
- 'Auto-discovery' : config/best-practices/autodiscover.md
- 'Security' :
- 'Understanding the Ports' : config/security/understanding-the-ports.md
- 'SSL/TLS' : config/security/ssl.md
- 'Fail2Ban' : config/security/fail2ban.md
2021-04-18 00:12:36 +00:00
- 'Mail Encryption' : config/security/mail_crypt.md
2023-01-25 09:28:59 +00:00
- 'Rspamd' : config/security/rspamd.md
2023-04-08 09:54:16 +00:00
- 'Debugging' : config/debugging.md
2021-03-02 17:48:28 +00:00
- 'Mail Delivery with POP3' : config/pop3.md
2023-04-10 09:37:25 +00:00
- 'About setup.sh' : config/setup.sh.md
2021-03-02 17:48:28 +00:00
- 'Advanced Configuration' :
- 'Optional Configuration' : config/advanced/optional-config.md
- 'Maintenance' :
- 'Update and Cleanup' : config/advanced/maintenance/update-and-cleanup.md
- 'Override the Default Configs' :
- 'Dovecot' : config/advanced/override-defaults/dovecot.md
- 'Postfix' : config/advanced/override-defaults/postfix.md
2021-04-01 20:44:31 +00:00
- 'Modifications via Script' : config/advanced/override-defaults/user-patches.md
2021-03-02 17:48:28 +00:00
- 'LDAP Authentication' : config/advanced/auth-ldap.md
- 'Email Filtering with Sieve' : config/advanced/mail-sieve.md
- 'Email Gathering with Fetchmail' : config/advanced/mail-fetchmail.md
2023-05-23 15:25:08 +00:00
- 'Email Gathering with Getmail' : config/advanced/mail-getmail.md
2021-03-02 17:48:28 +00:00
- 'Email Forwarding' :
- 'Relay Hosts' : config/advanced/mail-forwarding/relay-hosts.md
- 'AWS SES' : config/advanced/mail-forwarding/aws-ses.md
- 'Full-Text Search' : config/advanced/full-text-search.md
- 'Kubernetes' : config/advanced/kubernetes.md
- 'IPv6' : config/advanced/ipv6.md
2021-09-19 16:55:51 +00:00
- 'Podman' : config/advanced/podman.md
2022-05-07 22:28:32 +00:00
- 'Dovecot Master Accounts' : config/advanced/dovecot-master-accounts.md
2021-03-02 17:48:28 +00:00
- 'Examples' :
- 'Tutorials' :
- 'Basic Installation' : examples/tutorials/basic-installation.md
2021-09-27 07:01:41 +00:00
- 'Mailserver behind Proxy' : examples/tutorials/mailserver-behind-proxy.md
2023-11-25 10:02:42 +00:00
- 'Crowdsec' : examples/tutorials/crowdsec.md
2021-09-27 07:01:41 +00:00
- 'Building your own Docker image' : examples/tutorials/docker-build.md
2021-07-30 11:38:46 +00:00
- 'Blog Posts' : examples/tutorials/blog-posts.md
2021-03-02 17:48:28 +00:00
- 'Use Cases' :
2022-02-21 11:05:39 +00:00
- 'Forward-Only Mail-Server with LDAP' : examples/use-cases/forward-only-mailserver-with-ldap-authentication.md
- 'Customize IMAP Folders' : examples/use-cases/imap-folders.md
2023-08-29 21:40:54 +00:00
- 'iOS Mail Push Support' : examples/use-cases/ios-mail-push-support.md
2023-11-08 21:18:17 +00:00
- 'Lua Authentication' : examples/use-cases/auth-lua.md
2021-03-11 19:41:24 +00:00
- 'FAQ' : faq.md
2021-03-02 17:48:28 +00:00
- 'Contributing' :
2022-09-23 06:23:20 +00:00
- 'General Information' : contributing/general.md
2023-01-24 22:10:49 +00:00
- 'Tests' : contributing/tests.md
2021-03-02 17:48:28 +00:00
- 'Issues and Pull Requests' : contributing/issues-and-pull-requests.md
2021-09-13 07:03:40 +00:00
- 'DockerHub' : https://hub.docker.com/r/mailserver/docker-mailserver/
- 'GHCR' : https://github.com/docker-mailserver/docker-mailserver/pkgs/container/docker-mailserver
