# Bug 10979 — DKIM/ARC and MTA-STS missing for email setup on firefly

**Mantis:** https://bugs.gnunet.org/view.php?id=10979
**Category:** deployment and operations · **Host:** firefly.gnunet.org

## Problem

The ticket asks for DKIM/ARC and MTA-STS to be set up for firefly's mail. Current
state, confirmed read-only on firefly today:

| Mechanism | State on firefly |
| --- | --- |
| **DKIM signing** | **Already enabled** in rspamd (`/etc/rspamd/local.d/dkim_signing.conf`, `enabled = true`, `selector = "mail-2026-3"`, keys under `/etc/rspamd/dkim/$domain/`). A code comment notes the selector is *"invalid in DNS"*. |
| **ARC** | **Missing** — no `/etc/rspamd/local.d/arc.conf`. |
| **MTA-STS** | **Partially present but broken** — an `mta-sts.taler.net` nginx vhost serves a policy, but the policy body is malformed (see below) and only covers `taler.net`. |

### The MTA-STS policy is malformed

The `mta-sts.taler.net` vhost returns:

```
location /.well-known/mta-sts.txt {
    default_type text/plain;
    return 200 "version: STSv1
        mode: testing
        max_age: 86400
        mx: gv.taler.net
        mx: *.taler.net";
}
```

The continuation lines are indented in the nginx source, so the **served bytes
contain leading whitespace** on every line after the first:
`"        mode: testing"`. RFC 8461 §3.2 requires lines of the form `key: value`
with no leading whitespace; a parser that follows the grammar will treat the
policy as invalid and ignore it. So MTA-STS is effectively **not working** even for
taler.net. It is also in `mode: testing` (no enforcement) and exists for no other
domain.

## What can be fixed on firefly (this fix.sh)

Two changes that live entirely on the host and need no DNS:

1. **Enable ARC signing in rspamd.** Add `/etc/rspamd/local.d/arc.conf` mirroring
   the existing DKIM signing config (same key path and selector). ARC ("Authenticated
   Received Chain") lets downstream receivers trust the original SPF/DKIM results
   through firefly when it *forwards* mail — directly complementary to the SRS work
   in 11462 and the forwarding/reputation problems in 11317/11393.

2. **Fix the MTA-STS policy** so it is actually valid: rewrite the
   `mta-sts.taler.net` vhost with the policy lines flush-left (no leading
   whitespace). Mode is kept at `testing` deliberately — that is the safe state
   until reporting confirms senders honour the policy; flipping to `enforce` is a
   one-word follow-up once validated. nginx config is validated (`nginx -t`) before
   reload.

## What cannot be done from firefly (needs DNS — documented, not scripted)

These require editing DNS zones, which is explicitly out of reach from this host
(see also 11264/11279 where the team notes "we don't control the DNS zones"):

- **DKIM:** publish the `mail-2026-3._domainkey.<domain>` TXT record with the public
  key for each signing domain (the in-code comment says the current selector is
  "invalid in DNS" — i.e. the record is missing/wrong). Generate the public record
  per domain with:
  `rspamadm dkim_keygen -s mail-2026-3 -d <domain>` (public part only) or read the
  existing key's `.pub`/`.txt` — then publish it.
- **MTA-STS DNS:** for each domain needing MTA-STS, publish
  `_mta-sts.<domain>. TXT "v=STSv1; id=<timestamp>"` and an
  `mta-sts.<domain>` A/AAAA record pointing at firefly, plus (recommended) a
  TLSRPT record `_smtp._tls.<domain> TXT "v=TLSRPTv1; rua=mailto:..."`.
- **DMARC** (to make DKIM/SPF actionable): `_dmarc.<domain> TXT "v=DMARC1; p=..."`.
- Extending MTA-STS beyond taler.net (gnunet.org, anastasis.lu, taler-systems.com,
  taler-ops.ch) additionally needs a vhost + certificate per `mta-sts.<domain>`,
  which depends on the DNS records above existing first.

## Verification

```
# ARC
rspamadm configtest                       # rspamd config still valid
grep enabled /etc/rspamd/local.d/arc.conf
# send a test message through a forward and confirm ARC-Seal/ARC-Message-Signature headers

# MTA-STS validity (no leading spaces)
curl -s https://mta-sts.taler.net/.well-known/mta-sts.txt | cat -A | head
```