Merge pull request #238 from heavygale/patch-4

Random fixes and improvements

docs/debug-attach_service.md

@@ -36,6 +36,8 @@ Here is a brief overview of what container / service does what:
 | redis-mailcow     | Storage back-end for DKIM keys and Rspamd                                 |
 | rspamd-mailcow    | Mail filtering system. Used for av handling, dkim signing, spam handling  |
 | clamd-mailcow     | Scans attachments for viruses                                             |
+| olefy-mailcow     | Scans attached office documents for macro-viruses                         |
+| solr-mailcow      | Provides full-text search in Dovecot                                      |
 | sogo-mailcow      | Webmail client that handles Microsoft ActiveSync and Cal- / CardDav       |
 | nginx-mailcow     | Nginx remote proxy that handles all mailcow related HTTP / HTTPS requests |
 | acme-mailcow      | Automates HTTPS (SSL/TLS) certificate deployment                          |

docs/debug-common_problems.md

@@ -10,7 +10,7 @@ Please check in your mailcow UI if you made the domain a **backup MX**:
 
 There are a lot of things that could prevent you from sending mail:
 
-- Check if your IP is on any blacklists. You could use [dnsbl.info](http://www.dnsbl.info/) or any other similar service to check for your IP.
+- Check if your IP address is on any blacklists. You could use [dnsbl.info](http://www.dnsbl.info/) or any other similar service to check for your IP address.
 - There are some consumer ISP routers out there, that block mail ports for non whitelisted domains. Please check if you can reach your server on the ports `465` or `587`:
 
 ```
@@ -40,7 +40,7 @@ This error tries to tell you that one of the (health) conditions for a certain c
 
 A wrong configured firewall could also cause such a failure. The containers need to be able to talk to each other over the network 172.22.1.1/24.
 
-It might also be wrongly linked file (i.e. SSL certificate) that prevents a crucial container (nginx) from starting, so always check your logs to get an Idea where your problem is coming from.
+It might also be wrongly linked file (i.e. SSL certificate) that prevents a crucial container (nginx) from starting, so always check your logs to get an idea where your problem is coming from.
 
 
 ## Address already in use
@@ -51,7 +51,7 @@ If you get an error message like:
 ERROR: for postfix-mailcow  Cannot start service postfix-mailcow: driver failed programming external     connectivity on endpoint mailcowdockerized_postfix-mailcow_1: Error starting userland proxy: listen tcp 0.0.0.0:25: bind: address already in use
 ```
 
-while trying to start / install mailcow: dockerized, make sure you've followed our section on the [prerequisites](prerequisite-system/#firewall-ports).
+while trying to start / install mailcow: dockerized, make sure you've followed our section on the [prerequisites](../prerequisite-system/#firewall-ports).
 
 ## XYZ can't connect to ...
 

docs/firststeps-rspamd_ui.md

@@ -1,4 +1,4 @@
-Rspamd (https://rspamd.com/webui/) is an easy to use spam filtering tool presently installed with mailcow.
+[Rspamd](https://rspamd.com/) is an easy to use spam filtering tool presently installed with mailcow.
 
 1. Go to the mailcow web admin interface
 2. Navigate to the Access tab. (Configuration > Administration > Access)

docs/firststeps-snat.md

@@ -1,7 +1,5 @@
-## SNAT
-
 SNAT is used to change the source address of the packets sent by mailcow.
-It can be used to change the outgoing IP on systems with multiple IP addresses.
+It can be used to change the outgoing IP address on systems with multiple IP addresses.
 
 Open `mailcow.conf`, set either or both of the following parameters:
 

docs/firststeps-ssl.md

@@ -7,7 +7,7 @@ The "acme-mailcow" container will try to obtain a LE certificate for `${MAILCOW_
 
 By default, which means **0 domains** are added to mailcow, it will try to obtain a certificate for `${MAILCOW_HOSTNAME}`.
 
-For each domain you add, it will try to resolve `autodiscover.ADDED_MAIL_DOMAIN` and `autoconfig.ADDED_MAIL_DOMAIN` to its IPv6 or - if IPv6 is not configured in your domain - IPv4 address. If it succeeds, a name will be added as SAN to the certificate request.
+For each domain you add, it will try to resolve `autodiscover.ADDED_MAIL_DOMAIN` and `autoconfig.ADDED_MAIL_DOMAIN` to its IPv6 address or - if IPv6 is not configured in your domain - IPv4 address. If it succeeds, a name will be added as SAN to the certificate request.
 
 Only names that can be validated, will be added as SAN.
 
@@ -25,7 +25,7 @@ Do not use quotes (`"`) and do not use spaces between the names!
 ADDITIONAL_SAN=smtp.*,cert1.example.com,cert2.example.org,whatever.*
 ```
 
-Each name will be validated against its IPv6 or - if IPv6 is not configured in your domain - IPv4 address.
+Each name will be validated against its IPv6 address or - if IPv6 is not configured in your domain - IPv4 address.
 
 A wildcard name like `smtp.*` will try to obtain a smtp.DOMAIN_NAME SAN for each domain added to mailcow.
 
@@ -47,9 +47,9 @@ The file will be deleted automatically.
 
 ### Validation errors and how to skip validation
 
-You can skip the **IP verification** by setting `SKIP_IP_CHECK=y` in mailcow.conf (no quotes). Be warned that a misconfiguration will get you ratelimited by Let's Encrypt! This is primarily useful for multi-IP setups where the IP check would return the incorrect source IP. Due to using dynamic IPs for acme-mailcow, source NAT is not consistent over restarts.
+You can skip the **IP verification** by setting `SKIP_IP_CHECK=y` in mailcow.conf (no quotes). Be warned that a misconfiguration will get you ratelimited by Let's Encrypt! This is primarily useful for multi-IP setups where the IP check would return the incorrect source IP address. Due to using dynamic IPs for acme-mailcow, source NAT is not consistent over restarts.
 
-If you encounter problems with "HTTP validation", but your IP confirmation succeeds, you are most likely using firewalld, ufw or any other firewall, that disallows connections from `br-mailcow` to your external interface. Both firewalld and ufw disallow this by default. It is often not enough to just stop these firewall services. You'd need to stop mailcow (`docker-compose down`), stop the firewall service, flush the chains and restart Docker.
+If you encounter problems with "HTTP validation", but your IP address confirmation succeeds, you are most likely using firewalld, ufw or any other firewall, that disallows connections from `br-mailcow` to your external interface. Both firewalld and ufw disallow this by default. It is often not enough to just stop these firewall services. You'd need to stop mailcow (`docker-compose down`), stop the firewall service, flush the chains and restart Docker.
 
 You can also skip this validation method by setting `SKIP_HTTP_VERIFICATION=y` in "mailcow.conf". Be warned that this is discouraged. In most cases, the HTTP verification is skipped to workaround unknown NAT reflection issues, which are not resolved by ignoring this specific network misconfiguration. If you encounter problems generating TLSA records in the DNS overview within mailcow, you are most likely having issues with NAT reflection you should fix.
 
@@ -73,9 +73,10 @@ By default, "acme-mailcow" will create a single SAN certificate for all validate
 This provides best compatibility but means the Let's Encrypt limit exceeds if you add too many domains to a single mailcow installation.
 
 To solve this, you can configure `ENABLE_SSL_SNI` to generate:
-* A main server certificate with `MAILCOW_HOSTNAME` and all fully qualified domain names in the `ADDITIONAL_SAN` config
-* One additional certificate for each domain found in the database with autodiscover.*, autoconfig.* and any other `ADDITIONAL_SAN` configured in this format (subdomain.*).
-* Limitations: A certificate name `ADDITIONAL_SAN=test.example.com` will be added as SAN to the main certificate. A separate certificate/key pair will **not** be generated for this format.
+
+- A main server certificate with `MAILCOW_HOSTNAME` and all fully qualified domain names in the `ADDITIONAL_SAN` config
+- One additional certificate for each domain found in the database with autodiscover.*, autoconfig.* and any other `ADDITIONAL_SAN` configured in this format (subdomain.*).
+- Limitations: A certificate name `ADDITIONAL_SAN=test.example.com` will be added as SAN to the main certificate. A separate certificate/key pair will **not** be generated for this format.
 
 Postfix, Dovecot and Nginx will then serve these certificates with SNI.
 
@@ -86,14 +87,16 @@ Set `ENABLE_SSL_SNI=y` in "mailcow.conf" and recreate "acme-mailcow" by running
     You should make sure these clients use the `MAILCOW_HOSTNAME` for secure connections if you enable this feature.
 
 Here is an example:
-* `MAILCOW_HOSTNAME=server.email.tld`
-* `ADDITIONAL_SAN=webmail.email.tld,mail.*`
-* Mailcow email domains: "domain1.tld" and "domain2.tld"
+
+- `MAILCOW_HOSTNAME=server.email.tld`
+- `ADDITIONAL_SAN=webmail.email.tld,mail.*`
+- Mailcow email domains: "domain1.tld" and "domain2.tld"
 
 The following certificates will be generated:
-* `server.email.tld, webmail.email.tld` -> this is the default certificate, all clients can connect with these domains
-* `mail.domain1.tld, autoconfig.domain1.tld, autodiscover.domain1.tld` -> individual certificate for domain1.tld, cannot be used by clients without SNI support
-* `mail.domain2.tld, autoconfig.domain2.tld, autodiscover.domain2.tld` -> individual certificate for domain2.tld, cannot be used by clients without SNI support
+
+- `server.email.tld, webmail.email.tld` -> this is the default certificate, all clients can connect with these domains
+- `mail.domain1.tld, autoconfig.domain1.tld, autodiscover.domain1.tld` -> individual certificate for domain1.tld, cannot be used by clients without SNI support
+- `mail.domain2.tld, autoconfig.domain2.tld, autodiscover.domain2.tld` -> individual certificate for domain2.tld, cannot be used by clients without SNI support
 
 ### How to use your own certificate
 
@@ -111,7 +114,7 @@ docker restart $(docker ps -qaf name=nginx-mailcow)
 docker restart $(docker ps -qaf name=dovecot-mailcow)
 ```
 
-See https://mailcow.github.io/mailcow-dockerized-docs/firststeps-rp/#optional-post-hook-script-for-non-mailcow-acme-clients for a full example script.
+See [Post-hook script for non-mailcow ACME clients](../firststeps-rp/#optional-post-hook-script-for-non-mailcow-acme-clients) for a full example script.
 
 ### Test against staging ACME directory
 

docs/firststeps-sync_jobs_migration.md

@@ -10,7 +10,7 @@ Sync jobs are used to copy or move existing emails from an external IMAP server
 
 3. Fill in the "Host" and "Port" fields with their respective correct values from the upstream IMAP server.
 
-4. In the "Username" and 'Password" fields, supply the correct access credentials from the upstream IMAP server.
+4. In the "Username" and "Password" fields, supply the correct access credentials from the upstream IMAP server.
 
 5. Select the "Encryption Method". If the upstream IMAP server uses port 143, it is likely that the encryption method is TLS and SSL for port 993. Nevertheless, you can use PLAIN authentication, but it is stongly discouraged.
 
@@ -19,4 +19,4 @@ Sync jobs are used to copy or move existing emails from an external IMAP server
 7. Make sure to tick "Active" and click "Add".
 
 !!! info
-    Once Completed, log into the mailbox and check if all emails are imported correctly. If all goes well, All your mails shall end up in your new mailbox. And don't forget to delete or deactivate the sync job after it is used.
+    Once Completed, log into the mailbox and check if all emails are imported correctly. If all goes well, all your mails shall end up in your new mailbox. And don't forget to delete or deactivate the sync job after it is used.

docs/i_u_m_install.md

@@ -108,7 +108,7 @@ networks:
 If you do not have an IPv6 enabled network on your host and you don't care for a better internet (thehe), it is recommended to [disable IPv6](https://mailcow.github.io/mailcow-dockerized-docs/firststeps-disable_ipv6/) for the mailcow network to prevent unforeseen issues.
 
 
-**5\.** Pull the images and run the composer file. The parameter `-d` will start mailcow: dockerized detached:
+**5\.** Pull the images and run the compose file. The parameter `-d` will start mailcow: dockerized detached:
 ```
 docker-compose pull
 docker-compose up -d

docs/prerequisite-dns.md

@@ -9,9 +9,9 @@ Below you can find a list of **recommended DNS records**. While some are mandato
 - An in-depth discussion of SPF, DKIM and DMARC:
   ["How to eliminate spam and protect your name with DMARC"](https://www.skelleton.net/2015/03/21/how-to-eliminate-spam-and-protect-your-name-with-dmarc/)
 
-## Reverse DNS of your IP
+## Reverse DNS of your IP address
 
-Make sure that the PTR record of your IP matches the FQDN of your mailcow host: `${MAILCOW_HOSTNAME}` [^1]. This record is usually set at the provider you leased the IP (server) from.
+Make sure that the PTR record of your IP address matches the FQDN of your mailcow host: `${MAILCOW_HOSTNAME}` [^1]. This record is usually set at the provider you leased the IP address (server) from.
 
 ## The minimal DNS configuration
 
@@ -31,7 +31,7 @@ autoconfig          IN CNAME   mail
 In the example DNS zone file snippet below, a simple **SPF** TXT record is used to only allow THIS server (the MX) to send mail for your domain. Every other server is disallowed but able to ("`~all`"). Please refer to [SPF Project](http://www.open-spf.org/) for further reading.
 
 ```
-@                   IN TXT     "v=spf1 mx a -all"
+@                   IN TXT     "v=spf1 mx -all"
 ```
 
 It is highly recommended to create a **DKIM** TXT record in your mailcow UI and set the corresponding TXT record in your DNS records. Please refer to [OpenDKIM](http://www.opendkim.org) for further reading.
@@ -82,4 +82,4 @@ If you are interested in statistics, you can additionally register with the [Pos
 @                   IN TXT     "google-site-verification=..."
 ```
 
-[^1]: A **Fully Qualified Domain Name** (**FQDN**) is the complete (absolute) domain name for a specific computer or host, on the Internet. The FQDN consists of at least three parts divided by a dot: the hostname (myhost), the domain name (mydomain) and the top level domain in short **tld** (com). In the example of `mx.mailcow.email` the hostname would be `mx`, the domain name 'mailcow' and the tld `email`.
+[^1]: A **Fully Qualified Domain Name** (**FQDN**) is the complete (absolute) domain name for a specific computer or host, on the Internet. The FQDN consists of at least three parts divided by a dot: the hostname (myhost), the domain name (mydomain) and the top level domain in short **tld** (com). In the example of `mx.mailcow.email` the hostname would be `mx`, the domain name `mailcow` and the tld `email`.