1
1
mirror of https://github.com/docker-mailserver/docker-mailserver synced 2024-12-18 23:14:11 +01:00
docker-mailserver/docs/content/config/advanced/mail-sieve.md
Brennan Kinney 0698ad9370
docs: Refactor pages for Account Management (#4122)
* docs: Relocate account / auth pages into a common section

* docs: Update references to relocated pages

* docs: Add account management overview page

Updates remaining links to account sections on this page instead (_for `accounts`, `aliases`, `quotas`_).

This page will cover the features and defer to separate pages for more specific content where relevant.

* docs: Correct relocated pages titles and links

* docs: Accounts (Dovecot Master) - Minor revisions

* docs: Fix highlighting roundcube PHP snippet in OAuth2 page

* docs: Accounts (File) - Refactor

- Manual method not necessary to document.
- Condense `setup` example guidance.
- Quotas / Aliases content migrated to Overview when not specific about file provisioner.

Some of the content is this commit is not a complete revision.

* chore: Temporary commit

* docs(refactor): Sub-addressing section

Much better docs on the sub-addressing feature supported by Postfix and Dovecot, along with the guidance with usage in Sieve.

* docs:  Revise accounts section

Add some context regarding DMS accounts and their distinction/overlap from the email address functionality, and it's relevant context for receiving/sending.

File provisioner, minor revisions to referencing associated config files and account management.

* docs: Minor adjustments

* docs: Refactor the quota section

Better documented with links and coverage over the workaround details we've implemented.

* docs: Revise the quota section

Minor revisions with phrasing, admonitions for structure and better explanation of the feature functionality/purpose.

* docs: Alias section refactor

Extensively covers known issues and technical details that have been discussed often enough.

The improvements should benefit both users and maintainers.

* docs: Refactor master accounts page

This rewrite should more clearly document the feature, along with a better example and additional links for reference.

* docs: OAuth2 revision

Minor update to this page:
- Links extracted to bottom of page as per convention.
- ENV file example converted to preferred `compose.yaml` ENV settings.

* docs: Sieve minor revisions

- Correct link to subaddressing section
- Make the config file example snippets intended filename less ambiguous.
- Minor rephrasng.

* docs: Revise accounts overview section

Revised the account section and added additional clarity for common confusion with relation to sender address and multi-domain support.

Top of the page now clarifies it's a technical reference and directs users to the related pages for configuration / caveats.

Technical Overview links to Dovecot docs were missing.

* docs: Another revision pass

File based provisioner docs:
- Sections indent with info admonitions.
- Accounts section expanded with config format and example.
- Quotas section expanded and shifted to bottom (alphabetical sort).
- Split into `setup` CLI and config reference groups.

Overview page:
- Sections indent with info admonitions.
- Revised content.

* docs(chore): Shift sub-addressing section

This is related to accounts and aliases, but not provisioners, thus extract out of the accounts parent section.

* docs: Document `postfix-accounts.cf` third column

This lacked documentation but was community contributed feature to allow further customization of a Dovecot Account.

It has caveats as DMS does not take these into consideration anywhere in scripts. Documenting officially for better awareness.

* docs: Revise and expand supplementary pages

Better outline the OAuth2 login process, the two supported login mechanisms and their docs/rfcs, along with documenting caveat with mail client compatibility.

Add a verification tip for the OAuth2 support, showing how `curl` can be used, along with caveat presently affecting the `curl` in DMS v14.

Additionally note the feature still isn't documented fully, providing the user with additional references for more information.

`ACCOUNT_PROVISIONER` ENV docs minimized. No `OIDC` provisioner plans, the OAuth2 docs page now mentions SCIM 2.0 API as the next step towards resolving that concern. The tip admonition was removed as it no longer provides value, instead we link to the Account Management overview page.

Dovecot Master Accounts docs page now lightly document the `setup` CLI and config format for the feature.

* docs: Fix broken anchor links

Some anchor links to different parts of our docs have gone stale. This branch also broke a few itself that I missed.

The build now only reports issues with anchor links to Content Tabs, which it must not be aware of during the build (_MKDocs Material specific feature?_)

* docs(lint): Fix indentation level

* chore: Add entry to `CHANGELOG.md` + corrections
2024-07-22 10:00:53 +12:00

9.4 KiB

title
Advanced | Email Filtering with Sieve

User-Defined Sieve Filters

!!! warning "Advice may be outdated"

This section was contributed by the community some time ago and some configuration examples may be outdated.

Sieve allows to specify filtering rules for incoming emails that allow for example sorting mails into different folders depending on the title of an email.

!!! info "Global vs User order"

There are global and user specific filters which are filtering the incoming emails in the following order:

Global-before -> User specific -> Global-after

Global filters are applied to EVERY incoming mail for EVERY email address.

  • To specify a global Sieve filter provide a docker-data/dms/config/before.dovecot.sieve or a docker-data/dms/config/after.dovecot.sieve file with your filter rules.
  • If any filter in this filtering chain discards an incoming mail, the delivery process will stop as well and the mail will not reach any following filters (e.g. global-before stops an incoming spam mail: The mail will get discarded and a user-specific filter won't get applied.)

To specify a user-defined Sieve filter place a .dovecot.sieve file into a virtual user's mail folder (e.g. /var/mail/example.com/user1/home/.dovecot.sieve). If this file exists dovecot will apply the filtering rules.

It's even possible to install a user provided Sieve filter at startup during users setup: simply include a Sieve file in the docker-data/dms/config/ path for each user login that needs a filter. The file name provided should be in the form <user_login>.dovecot.sieve, so for example for user1@example.com you should provide a Sieve file named docker-data/dms/config/user1@example.com.dovecot.sieve.

An example of a sieve filter that moves mails to a folder INBOX/spam depending on the sender address:

!!! example

```sieve
require ["fileinto", "reject"];

if address :contains ["From"] "spam@spam.com" {
  fileinto "INBOX.spam";
} else {
  keep;
}
```

!!! warning

That folders have to exist beforehand if sieve should move them.

Another example of a sieve filter that forward mails to a different address:

!!! example

  ```sieve
  require ["copy"];

  redirect :copy "user2@not-example.com";
  ```

Just forward all incoming emails and do not save them locally:

!!! example

```sieve
redirect "user2@not-example.com";
```

You can also use external programs to filter or pipe (process) messages by adding executable scripts in docker-data/dms/config/sieve-pipe or docker-data/dms/config/sieve-filter.

This can be used in lieu of a local alias file, for instance to forward an email to a webservice.

  • These programs can then be referenced by filename, by all users.
  • Note that the process running the scripts run as a privileged user.
  • For further information see Dovecot's docs.
require ["vnd.dovecot.pipe"];
pipe "external-program";

For more examples or a detailed description of the Sieve language have a look at the official site. Other resources are available on the internet where you can find several examples.

Automatic Sorting Based on Sub-addresses

When mail is delivered to your account, it is possible to organize storing mail into folders by the subaddress (tag) used.

!!! example "Example: user+<tag>@example.com to INBOX/<Tag>"

This example sorts mail into inbox folders by their tag:

```sieve title="docker-data/dms/config/user@example.com.dovecot.sieve"
require ["envelope", "fileinto", "mailbox", "subaddress", "variables"];

# Check if the mail recipient address has a tag (:detail)
if envelope :detail :matches "to" "*" {
  # Create a variable `tag`, with the the captured `to` value normalized (SoCIAL => Social)
  set :lower :upperfirst "tag" "${1}";

  # Store the mail into a folder with the tag name, nested under your inbox folder:
  if mailboxexists "INBOX.${tag}" {
    fileinto "INBOX.${tag}";
  } else {
    fileinto :create "INBOX.${tag}";
  }
}
```

When receiving mail for `user+social@example.com` it would be delivered into the `INBOX/Social` folder.

??? tip "Only redirect mail for specific tags"

If you want to only handle specific tags, you could replace the envelope condition and tag assignment from the prior example with:

```sieve title="docker-data/dms/config/user@example.com.dovecot.sieve"
# Instead of `:matches`, use the default comparator `:is` (exact match)
if envelope :detail "to" "social" {
  set "tag" "Social";
```

```sieve title="docker-data/dms/config/user@example.com.dovecot.sieve"
# Alternatively you can also provide a list of values to match:
if envelope :detail "to" ["azure", "aws"] {
  set "tag" "Cloud";
```

```sieve title="docker-data/dms/config/user@example.com.dovecot.sieve"
# Similar to `:matches`, except `:regex` provides enhanced pattern matching.
# NOTE: This example needs you to `require` the "regex" extension
if envelope :detail :regex "to" "^cloud-(azure|aws)$" {
  # Normalize the captured azure/aws tag as the resolved value is no longer fixed:
  set :lower :upperfirst "vendor" "${1}";
  # If a `.` exists in the tag, it will create nested folders:
  set "tag" "Cloud.${vendor}";
```

**NOTE:** There is no need to lowercase the tag in the conditional as the [`to` value is a case-insensitive check][sieve-docs::envelope].

??? abstract "Technical Details"

- Dovecot supports this feature via the _Sieve subaddress extension_ ([RFC 5233][rfc::5233::sieve-subaddress]).
- Only a single tag per subaddress is supported. Any additional tag delimiters are part of the tag value itself.
- The Dovecot setting [`recipient_delimiter`][dovecot-docs::config::recipient_delimiter] (default: `+`) configures the tag delimiter. This is where the `local-part` of the recipient address will split at, providing the `:detail` (tag) value for Sieve.

---

`INBOX` is the [default namespace configured by Dovecot][dovecot-docs::namespace].

- If you omit the `INBOX.` prefix from the sieve script above, the mailbox (folder) for that tag is created at the top-level alongside your Trash and Junk folders.
- The `.` between `INBOX` and `${tag}` is important as a [separator to distinguish mailbox names][dovecot-docs::mailbox-names]. This can vary by mailbox format or configuration. DMS uses [`Maildir`][dovecot-docs::mailbox-formats::maildir] by default, which uses `.` as the separator.
- [`lmtp_save_to_detail_mailbox = yes`][dovecot-docs::config::lmtp_save_to_detail_mailbox] can be set in `/etc/dovecot/conf.d/20-lmtp.conf`:
    - This implements the feature globally, except for the tag normalization and `INBOX.` prefix parts of the example script.
    - However, if the sieve script is also present, the script has precedence and will handle this task instead when the condition is successful, otherwise falling back to the global feature.

Manage Sieve

The Manage Sieve extension allows users to modify their Sieve script by themselves. The authentication mechanisms are the same as for the main dovecot service. ManageSieve runs on port 4190 and needs to be enabled using the ENABLE_MANAGESIEVE=1 environment variable.

!!! example

```yaml title="compose.yaml"
ports:
  - "4190:4190"
environment:
  - ENABLE_MANAGESIEVE=1
```

All user defined sieve scripts that are managed by ManageSieve are stored in the user's home folder in /var/mail/example.com/user1/home/sieve. Just one Sieve script might be active for a user and is sym-linked to /var/mail/example.com/user1/home/.dovecot.sieve automatically.

!!! note

ManageSieve makes sure to not overwrite an existing `.dovecot.sieve` file. If a user activates a new sieve script the old one is backed up and moved to the `sieve` folder.

The extension is known to work with the following ManageSieve clients:

  • Sieve Editor a portable standalone application based on the former Thunderbird plugin.
  • Kmail the mail client of KDE's Kontact Suite.