Description

Some small tasks that shouldn't require much time / effort individually if anyone wants to tackle them:

Docs:

• Rspamd advice for adjusting symbols config should be polished into a smaller section on our Rspamd docs page to show how users can do this, along with some troubleshooting tips.
  • Related example for Rspamd multimap config that shows how to manage a block list for senders and customize the rejection message sent back to the MTA.
• Our Fetchmail docs should add a mention about FETCHMAIL_PARALLEL / IMAP IDLE support?
• Document catch-all alias search order and caveat with preserving subaddress value. Full insights + compose.yaml documented as an answer, just needs to be revised into more visible/discoverable docs 👍
• DKIM key setup and testing (Full compose.yaml example, OpenDKIM + Rspamd compatible)
  • Notably the setup config dkim help shows some extra options that aren't as well documented on the page?
  • Related is this alternative answer with compose.yaml + commands, which details a slight delay in child process startup for Rspamd (20 sec on my VPS tested), and the approach desired for DMS Rspamd DKIM config in future that is more simpler. Also better documents relevant rspamd settings involved, notably regarding eSLD.
• Dovecot sieve examples:
  • Full compose.yaml with commands for the most common use-case. Also includes some troubleshooting advice and link to Dovecot sieves extension list.
  • Possibly worth referencing is an example for how to retain the original alias used for the recipient.
• SpamAssassin tag logic could be better documented (ref. There is some indirect references to useful information which is provided via a related DMS ENV doc, we could better demonstrate this as it can be useful for troubleshooting/testing.
• SpamAssassin + Amavis: D_BOUNCE vs D_PASS logic is not documented well, especially with current logic in DMS that relies on SA to be enabled. This should be documented better, or ideally look into resolving the actual logic we have to fix and queue into a breaking change release.
  • Assess relevance of keeping Pyzor + Razor #4351 (comment) (see bottom of linked comment)
  • other: Outlook 2016 test messages get bounced? Missing date in header. #4378 (comment) (logic flow reference for scripts to change or document)
• Add a small FAQ / troubleshooting entry about fail2ban-client start.
• Potentially add a mention in our docs for always_bcc Postfix setting? There's been a couple user issues raised about this functionality.
  • Full reproduction example can be linked to here.
  • There are two additional BCC settings that are sender/recipient maps. Probably worth covering that too? There was also an observation noted that outbound BCC was not signing mail with DKIM (ARC might also be relevant here if forwarding?)
  • Related feature request where BCC was a suggested alternative to the desired ability to have a virtual alias deliver mail to the same address as a local mailbox, and then also deliver to an external address at another MTA. As of DMS v16, this is still forbidden and actively forbidden by setup email add / setup alias add (unless manually editing postfix-virtual.cf).
• Look into improving the relay host docs with information provided here (more thorough compose.yaml example).
  • User found the exist v15.1 docs to be a bit overwhelming/complicated, despite only really needing 3 ENV.
  • The docs don't presently link to the git repo relay-host compose.yaml example, but this has some added noise with port 465 and local TLS certs. A revised version is at the discussion comment I linked with a variation that skips TLS and documents how to configure DMS to connect to a relay host without enforcing TLS (albeit discouraged).
  • An additional concern raised was that DMS might be too much overhead vs an alternative. The image size is definitely large but memory usage of DMS as a simple relay-host was measured to be only 50MB. This should be acceptable for those already using DMS and preferring familiar config/support vs identifying an alternative and how to configure that accordingly (user had some trouble in this area only finding services that relay port 25 to authenticated ports 587/465 of another MTA for storage purposes of third-party mail received, but the user actually wanted to relay outbound mail they sent through an authenticated relay host as per our docs guidance on the topic).
  • Here's another compose.yaml reference example for DMS 15.1 I've provided with someone else needing forwarding of a foreign domain to multiple recipients via an alias (resolving to one local mailbox and another external address, similar to the BCC use-case but additionally relying on SRS to forward the foreign mail domain to a destination not owned/managed by the user).
    • There was an observation where the user may have misconfigured and had trouble due to a mix of ENV and config files for the same relay config. DMS should probably fix that in scripts or at least raise awareness in docs to avoid that. I share advice on how to configure for the relay host in different ways.
    • While the relayhost portion appears to be resolved, an issue with the relay service used was observed still rejecting the mail despite using SRS, presumably a mismatch on the FROM header sender address domain compared to the rewritten MAIL FROM envelope sender address.
    • The relay example I provide with multiple containers could potentially be adapted to support Podman via Quadlets? (low priority).
• Better clarify DMS stance on multi-domain certs being discouraged. DMS has a certificate as an MTA, the mail domains it manages aren't relevant for DMS certs provisioned FQDN beyond vanity reasons. Another recent attempt at explaining it but a bit too verbose.
• We could better document how DMS handles volume storage, such as file permissions/ownership changes and expectations. I've partially documented that here.
• Better document setup email restrict CLI commands (fully detailed here). For other related restrictions, this advice shows how to manually add such config with compose.yaml and user-patches.sh.
• Provide a better user-patches.sh docs page example, with copy/paste compose.yaml reference? Also make sure to communicate clearly this will only run on initial container setup, not container restarts.
• Fetchmail docs page should perhaps add a mention about reliance upon hostname as an FQDN? Seems to have a compatibility issue in kubernetes, but I've not yet verified. Presumably it could be reproduced with Docker Compose too if no hostname were set (only relying on OVERRIDE_HOSTNAME). (EDIT: Confirmed, will need to improve documentation based on these findings).
• Some users are using systems on devices or OS that are EOL. There are requests to allow outdated versions of TLS to establish connections, but DMS is preventing that with plans to change our legacy TLS support.
  • Workarounds that could be documented for better visibility.
  • Recent summary.
  • Known users:
    • chore: Drop support for deprecated TLS versions #2945 (comment) (Windows 7)
    • https://github.com/orgs/docker-mailserver/discussions/4481#discussion-8352315 (old iPhone / iOS)
• Add a mention to our docs (troubleshooting and volumes pages, maybe FAQ?) regarding limited support for remote network storage (NFS, SMB (Samba/CIFS)), which is relevant to at least Dovecot and /var/mail-state (various reports over the years like this one, often due to NFS).
• Document guidance for Amavis / Rspamd whitelist per mail address?
• Document a common request for Fail2Ban or similar whitelist / allowlist functionality.
  • Some of the previous issues referenced (with solutions).
  • Simple example self-contained in compose.yaml.
• Add reproduction and reference in docs for this example to show how to store attachments at a separate location. Attachment size config needs better documentation in general so it could be grouped in a section of our docs with that. Note the Dovecot 2.3 vs 2.4 differences.
• Document an example of pre-provisioned users for automated usage?
• Add a FAQ entry with some guidance for backup MX config? Or potentially just relay_domains + relay_recipient_maps for forwarding/relaying mail arriving on port 25 instead of virtual aliases (I think it's common to see a wildcard / catch-all used this way to relay to Gmail but this might be better handled via relay_domains).
• Improve setup config dkim CLI output to align with docs advice to restart DMS (after unified DKIM refactor, it may be possible to leverage change detector support to avoid this requirement?).
• Better document config like our override support with Compose configs feature?
  • Some users raise PRs or FRs for simple ENV to service config setting mappings, when configs is usually just as good when wanting to avoid creating a separate file. We could probably better raise awareness of configs for this.
  • Linked discussion also covers a Dovecot setting that can be useful for integration with Roundcube for preserving IPs? That's come up a few times, would be worth documenting as a FAQ entry.
  • Likewise I comment about PERMIT_DOCKER feature where that kind of network trust could be included, or a rework of the feature where we can provide more granular control (or have a dedicated docs page for related settings to manually manage via configs + .env).
• Consider documenting doveconf usage (may be useful to mention in troubleshooting docs page + override / user-patches.sh, although unlike postconf it's read-only output of config)
• Getmail docs page, add mention about an empty/invalid Return-Path caveat.
• Consider documenting topics covered here. Alias/Mailbox address overlap forbidden (documented), ARC for forwarding (may need to verify concern), SRS alternative.
• Add a docs page for swaks usage (upstream docs + FAQ) that covers common commands users can utilize for troubleshooting or testing anti-spam (GTUBE) and anti-virus (EICAR)
  • This reference of mine provides a fairly good starting point?
  • This reference shows a useful tip for changing the default --data template. Also the --dump-mail option for outputting to a file instead of sending to an MTA (it's also possible to skip Postfix and deliver to Dovecot directly via LMTP socket + protocol, as the swaks docs document).
  • This reference provides a compose.yaml example (Amavis whitelist) with swaks for testing.
  • There's another useful feature for default options that might be useful too (our test-suite should adopt that to simplify the usage of swaks vs our current wrapper method). I have discussed using this feature in a past issue/PR related to the test suite PR that introduced swaks.
    • --config option and docs linked covers the feature, with ENV support to override when needed.
    • Related ENV
• Check docs for any existing mention of client access restriction. If nothing to update, this discussion may be worth adding a FAQ link to. Another detailed answer with a compose.yaml example.
• Add FAQ entry and reference it from SMTP_ONLY=1 ENV docs for common use-case of unauthenticated mail submission to authenticated relay service. Consider directing user to separate service? (some suggestions)
• LDAP docs may need to clarify concern over config with foreign domains being configured as managed by DMS.
• The v15.0 docs have a dovecot-solr example with compose.yaml snippet that demonstrates how to easily extend DMS without extra files. Some users aren't aware of this useful feature, could be good to raise awareness? (here's another similar snippet, but adds -y to the package install which was necessary, and another example for mysql support)
  • Might be worth adding as a subsection to the build DMS image page, or a separate complimentary page for extending the image.
  • Another good location is the demo-setups repo folder. Including a compose.yaml there is simple copy/paste (with either link reference to the docs, or git blame the dovecot-solr page PR for an issue comment link for context?)
• Other examples to consider documenting properly:
  • Legacy iptables support instead of nftables example might be worth documenting somewhere, although only likely to be relevant on older NAS systems?
  • Using postconf -M to edit/add master.cf entries via user-patches.sh can be useful to document.
    • Related is this discussion question which asks about configuring master.cf to process mail through a python script, a request I've seen several times.
    • Here's an example about postfix-main.cf / postfix-master.cf support but suggests using user-patches.sh instead with postconf -P and sed for editing a multi-value setting.
    • Another one that should probably be documented is a one-line change to support connecting to relay hosts with implicit TLS (port 465), which is via our postfix-master.cf feature or postfix -P with user-patches.sh. If DMS had multiple relay hosts and needed to support both implicit and explicit TLS connections due to a relayhost maps config, this would need master.cf to have a separate relay service for each (example of configuring new services via user-patches.sh is covered here), which complicates config a bit more and might warrant improved relay host support in DMS?
  • List-Unsubscribe header for outgoing mail as an example of customizing header modification. Linked comment also references a potential existing implementation concern in DMS that should be addressed.

Scripts:

• Traces of SSL_DOMAIN need to be removed once verifying Traefik acme.json support for wildcard certs is not dependent upon it (as per observations in the test-case bulletpoint, it seems unlikely).
  • As per the linked docs config, no wildcard prefix (*.example.com) should be set as SSL_DOMAIN, so related logic for that should not be a concern and could be dropped? There was an earlier query to acme.json, and we seem to only have a test-case run with the wildcard prefix, as-such this docs reference might have been accidentally missed by this related PR and those two lines can probably be removed from the docs.
  • There is a test-case for acme.json + SSL_DOMAIN using a wildcard in the SSL_DOMAIN configured value, which our extraction method only strips away from the subsequent storage path check (_similar to how the acme specific TLS helper logic doesn't strip this wildcard when querying the extraction method, but the related letsencrypt storage helper method does strip the wildcard prefix away. Meanwhile our Traefik compose.yaml example docs briefly mention SSL_DOMAIN should be set without the wildcard prefix when using a wildcard cert, and since there has been no reports after the fact about the prefix being necessary, it's probably safe to assume SSL_DOMAIN is redundant when the related DOMAINNAME vars checked for the DMS FQDN represent the same value without that prefix.
  • There is one known use-case of SSL_DOMAIN being used as a workaround for LetsEncrypt certs provisioned via NPM with a different storage naming convention than expected. This can be worked around with other DMS TLS ENV as the linked comment documents, but is potentially relevant to an associated planned refactor for TLS cert handling.
• Postfix 3.10 added an opt-in privacy feature with smtpd_hide_client_session = yes, which might be worthwhile to assess using compared to our existing attempt for such.
• This comment references some issues related to Amavis + SpamAssassin, where one identifies a bug that should be resolved, and another about an indirect breakage in SA behaviour with a point release update of DMS (Debian packages updated).
• When operating on postfix-virtual.cf it has been reported that sed will fail when the user config/value includes a | character for piping mail to a command. This will be due to some of our sed expressions using | as a delimiter, so that should probably be escaped from input?
• POSTFIX_MESSAGE_SIZE_LIMIT (default 10MB) + POSTFIX_MAILBOX_SIZE_LIMIT (default unlimited) need to be revisited.
  • These are documented but are Postfix oriented without any mention of usage with Dovecot Quota config. The user in the linked discussion also mentions concerns with Getmail6 behaviour (may also affect Fetchmail?) which fails delivery.
  • Default message size limit should be raised to 25MB to align with popular mail providers limit like Gmail? This has been discussed in the past, yet no action was taken.
  • Suggestion to have separate limit ENV or global ENV control rather than current misleading postfix scope. Global makes more sense as DMS should avoid simple ENV mappings when equivalent support can be documented with our config file overrides feature instead.
• Sender header filter support should be reviewed / corrected, especially if it's only meant to be used for mail sent through submission(s) ports.
• Cleanup Dovecot config we add into the image to be minimized to only what is relevant and migrate actual changes to dedicated base config or scripts. Possibly important for Dovecot 2.4 support?
  • One example is we have LDA config for sieve support handled via script, while we have an old LMTP config for the same sieve support being copied via config instead of handled with scripts as well. These two protocol don't appear to have parity with settings, might be relevant when considering LMTP vs LDA for Dovecot Sieve (ref 1 (comment), ref 2 (task)).
• Update check-for-changes.sh to include support for sieve scripts (see this guidance for reference)
• Not important to fix - SMTP_ONLY=1 (and likely ACCOUNT_PROVISIONER=LDAP?) don't actually support the current DMS default of ENABLE_QUOTAS=1.
  • setup email list is for postfix-accounts.cf, which should rarely exist with either of those ENV settings.
  • The list command will fail to query quota since Dovecot would not have been configured with the feature, triggering this call to error/fail here.

Tests:

• Move the setup CLI test from parallel set to serial to avoid sporadic failure (details)
• Add a test case that checks /etc/services for service aliases used such as smtp, submission, submissions (referenced by /etc/postfix/master.cf, possibly elsewhere), similar might apply for imap. This test case is intended for detecting potential change, either in a future release of the current Debian base image, or a change to another base image distro where /etc/services is not always consistent with these (notably submissions may not exist).
• Postgrey whitelist may need to be looked at. I recall there are two types of files for that support and vaguely recalling a concern about that seeming redundant when looking over the test usage. That linked PR also added an empty header_checks file without proper implementation (see the above List-Unsubcribe linked issue), DMS has better support since that PR which probably applies to the whitelist contribute too.
• SMTP_ONLY=1 has a feature test that wasn't implemented well. It's presently skipped but should be revised once migration to compose.yaml + DNS service are available. See this related comment with link to test feedback.

CI:

• When publishing patch version tags, our production docs deploy workflow has a final step to update a latest tag alias (docs version dropdown selector managed via a JSON file). Since our docs only version major.minor, point release tags will fail this step as there is no change to the current latest alias (still valid, assuming no backport tag releases). Thus might need some extra logic to detect and skip that step, probably fine for skipping when the patch version of a semver tag is not 0. For reference, it was encountered here.

To consider:

• Revise the FTS docs for Xapian + Solr page reference, and consider the official Dovecot support for flatcurve going forward from Dovecot 2.4: https://github.com/orgs/docker-mailserver/discussions/4461#discussioncomment-13002388

Personal tasks

These are tasks that are dependent upon myself, I don't expect anyone else to be able to assist with these but they're here as reminders for myself.

• Do another revision pass over the revised Podman docs. There was concerns about statements regarding the two network drivers and rootful vs rootless contexts, along with some information I should have locally that I wanted to touch on about with machinectl or similar systemd commands to manage via CLI (the merged PR has a section on machinectl instructions from the contributor that I had not yet revised as planned).