Technically, the current setup config dkim support would also produce the example.private and example.txt files that Rspamd needs. They're very much the same, except OpenDKIM is generating with h=sha256; header option in the example.txt file.

The script would need to be adjusted to more generic (eg: only create open dkim related config if ENABLE_OPENDKIM=1?). They support most of the same command options as well (--subdomains in opendkim isn't necessary as it appears to be the default, --nosubdomains would add t=s;, but we don't support changing that). Other than that no -k / --privkey or -t / --type options are supported by OpenDKIM.

That leaves us with step 4. You can kind of generate this via concatenation of the top half of the config + some loops for domain (with conditional on selectors array injection), but that's a bit awkward to maintain in bash IMO. I think fetchmail and the current PR for getmail take this sort of approach at generating similar config.

From the examples below at least, it looks fairly doable, especially if we're in control of the file path / name conventions.

Is this the parsing concern? From the looks of it with OpenDKIM, and it's probably applicable to Rspamd support, the config duration could be generated instead via a runtime helper script:

The relevant information seems to be persisted into the file path, similar to how the LetsEncrypt support is, thus might be able to lean on logic from there:

We can see how OpenDKIM is sourcing the keys from a config mount, and copying them over to an internal location at start up. That ensures ownership is correct.

Likewise, this would probably enable both to leverage check-for-changes.sh to configure and reload instead of needing to restart the container fully? (potentially useful if you rotate DKIM keys)

I wouldn't encourage pursuing that in this PR though 😅 Might be a worthwhile improvement to open an issue about and implement in future?

For reference, the open_dkim.bats test would extract out the public key and concatentate it (similar to what the DNS advice for web UI suggests further down):

Smallstep CLI can generate the keypairs (including Ed25519), while another command from their CLI can inspect the private key or derive the public key from it (in PEM format). That would technically be capable of generating the main data for DKIM, the rest could be templated.

That said if OpenDKIM is going to be dropped by end of the year, setup config dkim could just replace opendkim for rspamd equivalent command 😅

Found this awful looking monstrosity one-liner that reads in a public key in PEM format, excludes the header/footer lines and concatenates the base64 encoded content to a single line:

awk 'NR>2 { sub(/\r/, ""); printf "%s\\n",last} { last=$0 }' example.pub `

Probably don't want the \n being added there, so removing that and optionally using fold to revert back to the same PEM width:

awk 'NR>2 { sub(/\r/, ""); printf "%s",last} { last=$0 }' example.pub
  | fold --width 64

DKIM key + dns record generator helper:

#!/bin/bash

SELECTOR=${1:-mail}
KEYSIZE=${2:-2048}

# Create your own keypair instead of via `opendkim-genkey` or `rspamadm dkim_keygen`:
#step crypto keypair "${SELECTOR}.pub" "${SELECTOR}.private" --kty RSA --size "${KEYSIZE}" --no-password --insecure

# Derive the public key from the private key as a single line
PUBLIC_KEY=$(
  step crypto key public "${SELECTOR}.private" \
    | awk 'NR>2 { sub(/\r/, ""); printf "%s",last} { last=$0 }'
)

# Format into multiline 255 char segments for DNS record zone file:
PUBLIC_KEY_SPLIT=$(
  fold --width 255 <<< "p=${PUBLIC_KEY}" \
    | sed -E 's#(.*)#        "\1"#'
)

# Template of rspamadm output:
cat << EOF > "${SELECTOR}.dns.txt"
${SELECTOR}._domainkey IN TXT ( "v=DKIM1; k=rsa; "
${PUBLIC_KEY_SPLIT}
) ;
EOF

There you go, does not depend on opendkim or rspamd to generate the keypair and record, and can output the single line entry or multi-part DNS zone record.

setup config dkim could be retrofitted with that to generate a key in config volume that is stored in a common folder that both opendkim and rspamd could copy from at runtime and generate their configs for.

I know you've replaced our kebab-case naming convention with snake_case in some of the script files as of late, and now you're introducing that into the docs.

I really don't want to see this deteriorate further over time. Please decide on a convention and be consistent with it throughout. I don't recall your motivation for introducing snake_case into file names, but you'll typically find advice online, to use - for separation of words. Google has it's own guidelines that also advise this for directory and file names.

On the web with URLs hyphens are also preferred (and the only choice when it comes to DNS names IIRC). The anchor links to page sections strip special symbols and substitute spaces with -, so underscores won't be consistent there regardless (SEO tends to prefer - too IIRC).

I won't commit this, but it's a bit of a hack indenting everything another level to use a title-less admonition as a clearer content boundary.

There doesn't seem to be any other supported way to achieve the same beyond the unavailable card grid feature. From what I can see the regular grid wouldn't add a border.

I'm pretty sure I can instead add a <div class="my-border-style"> to wrap the content without an indent, and use some custom CSS if we need that. Slight maintenance risk with the upstream updates potentially not liking that though.