Merge branch 'master' into patch-2

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.*).
+- A main server certificate with `MAILCOW_HOSTNAME` and all fully qualified domain names in the `ADDITIONAL_SAN` config
-* 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.
+- 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_HOSTNAME=server.email.tld`
-* Mailcow email domains: "domain1.tld" and "domain2.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
+- `server.email.tld, webmail.email.tld` -> this is the default certificate, all clients can connect with these domains
-* `mail.domain2.tld, autoconfig.domain2.tld, autodiscover.domain2.tld` -> individual certificate for domain2.tld, cannot be used by clients without SNI support
+- `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

@@ -12,9 +12,9 @@ Below you can find a list of **recommended DNS records**. While some are mandato
 ["Demystifying DMARC: A guide to preventing email spoofing"](https://seanthegeek.net/459/demystifying-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
 
@@ -35,7 +35,7 @@ In the example DNS zone file snippet below, a simple **SPF** TXT record is used
 
 ```
 # Name              Type       Value
-@                   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.
@@ -100,4 +100,4 @@ It is worth mentioning, that the following suggestions are not a comprehensive l
 **NOTE:** The services may provide you with a TXT record, which you would insert into your DNS records as the provider specifies. This record will give you details about spam-classified mails by your domain. However, please ensure to read the providers documentation from the service you choose, as this process may vary and not all providers may use a TXT record.
 
 ### Fully Qualified Domain Name (FQDN)
-[^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`.

docs/restrictions_ip_accss.md

@@ -0,0 +1,15 @@
+_WIP_
+
+# Protocol restrictions and IP access
+
+Denied access will be shown to the user as failed login attempts.
+
+## Protocol restrictions in Dovecot
+
+Protocol restrictions work by filtering the passdb query for IMAP and POP3 as well as reading the JSON value for %s_access where %s reflects the protocol seen by Dovecot.
+
+In the future we may use virtual colums in SQL to add an index on these values.
+
+## Protocol restrictions in Postfix
+
+Filtering SMTP protocol access works by using a check_sasl_map in the smtpd_recipient_restrictions.

docs/third_party-roundcube.md

@@ -2,9 +2,9 @@ Download Roundcube 1.4.x to the web htdocs directory and extract it (here `rc/`)
 ```
 # Check for a newer release!
 cd data/web
-wget -O - https://github.com/roundcube/roundcubemail/releases/download/1.4.8/roundcubemail-1.4.8-complete.tar.gz | tar xfvz -
+wget -O - https://github.com/roundcube/roundcubemail/releases/download/1.4.9/roundcubemail-1.4.9-complete.tar.gz | tar xfvz -
 # Change folder name
-mv roundcubemail-1.4.8 rc
+mv roundcubemail-1.4.9 rc
 # Change permissions
 chown -R root: rc/
 ```

docs/u_e-dovecot-static_master.md

@@ -0,0 +1,21 @@
+Random master usernames and passwords are automatically created on every restart of dovecot-mailcow.
+
+**That's recommended and should not be changed.**
+
+If you need the user to be static anyway, please specify two variables in `mailcow.conf`.
+
+**Both** parameters must not be empty!
+
+```
+DOVECOT_MASTER_USER=mymasteruser
+DOVECOT_MASTER_PASS=mysecretpass
+```
+
+Run `docker-compose up -d` to apply your changes.
+
+The static master username will be expanded to `DOVECOT_MASTER_USER@mailcow.local`.
+
+To login as `test@example.org` this would equal to `test@example.org*mymasteruser@mailcow.local` with the specified password above.
+
+A login to SOGo is not possible with this username. A click-to-login function for SOGo is available for admins as described [here](https://mailcow.github.io/mailcow-dockerized-docs/debug-admin_login_sogo/)
+No master user is required.

mkdocs.yml

@@ -79,14 +79,15 @@ nav:
       - 'Using an external DNS service': 'u_e-unbound-fwd.md'
   - 'Dovecot':
       - 'Enable "any" ACL settings': 'u_e-dovecot-any_acl.md'
-      - 'Public folders': 'u_e-dovecot-public_folder.md'
       - 'Expunge a Users mails': 'u_e-dovecot-expunge.md'
       - 'Customize/Expand dovecot.conf': 'u_e-dovecot-extra_conf.md'
+      - 'FTS (Solr)': 'u_e-dovecot-fts.md'
+      - 'IMAP IDLE interval': 'u_e-dovecot-idle_interval.md'
       - 'Mail crypt': 'u_e-dovecot-mail-crypt.md'
       - 'More Examples with DOVEADM': 'u_e-dovecot-more.md'
       - 'Move vmail volume': 'u_e-dovecot-vmail-volume.md'
-      - 'IMAP IDLE interval': 'u_e-dovecot-idle_interval.md'
+      - 'Public folders': 'u_e-dovecot-public_folder.md'
-      - 'FTS (Solr)': 'u_e-dovecot-fts.md'
+      - 'Static master user': 'u_e-dovecot-static_master.md'
   - 'Nginx': 
      - 'Custom sites': 'u_e-nginx.md'
      - 'Create subdomain webmail.example.org': 'u_e-webmail-site.md'