Files

T

lukasandClaude Opus 5.5 463f96ad57 Invite a friend; handle field shows the domain; system mail fixes

- Invitations: each user can invite two friends by email (sign-up works
  through the link even while registration is closed); admin-editable
  template, subject and sender.
- Invitation sender defaults to the system-mail From address, which the
  SMTP account is allowed to send as (was postmaster@APP_DOMAIN, refused
  with 553 when the two differ).
- Sign-in, sign-up and forgot-password fields show the fixed
  @domain after the typed name; the registration status reports it.
- System mail gets a Date header; the invitation's plain-text part keeps
  its paragraphs and line breaks.
- SMTP EHLO uses SMTP_HELO_NAME / APP_DOMAIN, not the container name.
- DNS recommendations for the mail domains.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-15 19:34:31 +02:00

4.8 KiB

Raw Blame History

DNS recommendations — ultimo.email and imaginary-pixels.com

Checked 2026-10-14, after the security assessment (DMARC/SPF finding) and the first DMARC test mails. In priority order. See also docs/mail-server-network.md for the hosted-mail (Stalwart) plan.

State when checked

	ultimo.email (DNS at home.pl)	imaginary-pixels.com (DNS at Cloudflare)
MX	`serwer2295308.home.pl` (46.242.246.139)	`_dc-mx…` → 46.242.246.139 (home.pl)
SPF	`v=spf1 a mx ~all`	`v=spf1 mx a ptr ~all`
DKIM	selector `dkim` present	selector `dkim` present, signing verified (PASS at Gmail)
DMARC	`p=none; rua=mailto:postmaster@ultimo.email; fo=1`	`p=none; rua=mailto:admin@imaginary-pixels.com` (added 2026-10-14)
CAA	none	none
DNSSEC	no	no
Other	wildcard `*.ultimo.email` → `ultimo.email`; SRV `_imaps`/`_submission` → `ultimo.email:993/587` (ports closed)	—

Mail from the webmail goes out through home.pl's SMTP (46.242.246.139), which both domains' SPF already allow through mx. The home IP 178.219.143.96 has reverse DNS pub-143.96.multiplay.pl (cannot be changed by the ISP), so the QNAP must not send directly to the internet.

1. Remove the mail-app SRV records for ultimo.email — now

_imaps._tcp.ultimo.email       SRV 10 5 993 ultimo.email.
_submission._tcp.ultimo.email  SRV 10 5 587 ultimo.email.

They tell Thunderbird, iPhones and other mail apps that ultimo.email's mail server is ultimo.email on 993/587 — the home IP, where those ports are closed (hosted mail is not live; mail is at home.pl). Apps that set themselves up from them fail to connect. Delete both in the home.pl DNS panel; add them back when Stalwart goes live.

2. Remove the wildcard `*.ultimo.email` — now

Every made-up name (e.g. random-xyz123.ultimo.email) resolves to the home IP and lands on the Synology; lookups such as _mta-sts.ultimo.email and _smtp._tls.ultimo.email come back with the SPF record. Delete the wildcard and keep explicit records only for names in use: ultimo.email itself, plus www if wanted (point 3). mail. and autoconfig. come back with the Stalwart launch. Check first whether the wildcard was a home.pl default or deliberate.

3. `www.ultimo.email` — decide

It resolves but has no certificate, so https://www.ultimo.email shows a browser error. Either drop it (it disappears with the wildcard), or keep it as CNAME ultimo.email, add it to the DSM certificate and add a reverse-proxy rule for it (HTTP rule with X-Forwarded-Proto: http, HTTPS rule like the main one).

4. CAA for ultimo.email — recommended

Only the named certificate authority may issue certificates for the domain. The Synology uses Let's Encrypt:

ultimo.email.  CAA  0 issue "letsencrypt.org"

Before adding it, confirm with home.pl that they don't issue a certificate for ultimo.email themselves; if they do, add their CA as another issue line or skip CAA. Not needed for imaginary-pixels.com (Cloudflare manages its certificates there).

5. SPF cleanups — after reviewing the DMARC reports

ultimo.email: v=spf1 mx -all. The QNAP sends through home.pl (covered by mx), so a — the home IP — is not needed. Change it together with the move to p=quarantine.
imaginary-pixels.com: v=spf1 mx ~all. a points at Cloudflare's web servers (never send mail); ptr is deprecated. First check the reports for any other legitimate sender (e.g. a website contact form).

6. DMARC staging — both domains

Collect aggregate reports for about 2 weeks (p=none). Make sure postmaster@ultimo.email exists at home.pl, or its reports go nowhere.
When every legitimate sender passes: p=quarantine.
After another 2–4 weeks without legitimate failures: p=reject.

DMARC TXT records have a 5-minute TTL, but a missing record is cached for up to 30 minutes (Cloudflare SOA minimum) — retest a while after creating one.

7. DNSSEC — optional, worth doing

Protects MX and other records against forged DNS answers.

imaginary-pixels.com: Cloudflare → DNS → Settings → Enable DNSSEC, then add the DS record it shows at the registrar.
ultimo.email: check the home.pl panel for a DNSSEC option.

Later — when hosted mail (Stalwart) goes live

MX to mail.ultimo.email; SPF to match the real sending path (with the home.pl relay, mx/home.pl keeps covering it).
SRV (_imaps, _submission, _submissions) and autoconfig back, pointing at mail.ultimo.email.
Optional MTA-STS + TLS-RPT (needs a real mta-sts.ultimo.email with a certificate — another reason to remove the wildcard now).
SMTP_HELO_NAME=mail.ultimo.email in docker/.env.prod if Stalwart's hostname should be the one announced.

Not fixable in DNS: the home IP's reverse DNS — avoided by always sending through home.pl.

4.8 KiB Raw Blame History Unescape Escape