infrastructure/mox
1
0
Fork 0
mirror of https://github.com/mjl-/mox.git synced 2025-07-14 16:54:36 +03:00
Code Issues Packages Projects Releases Wiki Activity

implement outgoing tls reports

Browse Source 
we were already accepting, processing and displaying incoming tls reports. now
we start tracking TLS connection and security-policy-related errors for
outgoing message deliveries as well. we send reports once a day, to the
reporting addresses specified in TLSRPT records (rua) of a policy domain. these
reports are about MTA-STS policies and/or DANE policies, and about
STARTTLS-related failures.

sending reports is enabled by default, but can be disabled through setting
NoOutgoingTLSReports in mox.conf.

only at the end of the implementation process came the realization that the
TLSRPT policy domain for DANE (MX) hosts are separate from the TLSRPT policy
for the recipient domain, and that MTA-STS and DANE TLS/policy results are
typically delivered in separate reports. so MX hosts need their own TLSRPT
policies.

config for the per-host TLSRPT policy should be added to mox.conf for existing
installs, in field HostTLSRPT. it is automatically configured by quickstart for
new installs. with a HostTLSRPT config, the "dns records" and "dns check" admin
pages now suggest the per-host TLSRPT record. by creating that record, you're
requesting TLS reports about your MX host.

gathering all the TLS/policy results is somewhat tricky. the tentacles go
throughout the code. the positive result is that the TLS/policy-related code
had to be cleaned up a bit. for example, the smtpclient TLS modes now reflect
reality better, with independent settings about whether PKIX and/or DANE
verification has to be done, and/or whether verification errors have to be
ignored (e.g. for tls-required: no header). also, cached mtasts policies of
mode "none" are now cleaned up once the MTA-STS DNS record goes away.
This commit is contained in:
Mechiel Lukkien
2023-11-09 17:40:46 +01:00
parent df18ca3c02
commit 893a6f8911
58 changed files with 3246 additions and 504 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
smtpserver/analyze.go
View File

@ -210,7 +210,7 @@ func analyze(ctx context.Context, log *mlog.Log, resolver dns.Resolver, d delive
// Similar to DMARC reporting, we check for the required DKIM. We'll check
// reputation, defaulting to accept.
var tlsReport *tlsrpt.Report
if d.rcptAcc.destination.TLSReports {
if d.rcptAcc.destination.HostTLSReports || d.rcptAcc.destination.DomainTLSReports {
// Valid DKIM signature for domain must be present. We take "valid" to assume
// "passing", not "syntactically valid". We also check for "tlsrpt" as service.
// This check is optional, but if anyone goes through the trouble to explicitly
@ -218,6 +218,13 @@ func analyze(ctx context.Context, log *mlog.Log, resolver dns.Resolver, d delive
// ../rfc/8460:320
ok := false
for _, r := range d.dkimResults {
// The record should have an allowed service "tlsrpt". The RFC mentions it as if
// the service must be specified explicitly, but the default allowed services for a
// DKIM record are "*", which includes "tlsrpt". Unless a the DKIM record
// explicitly specifies services (e.g. s=email), a record will work for TLS
// reports. The DKIM records seen used for TLS reporting in the wild don't
// explicitly set "s" for services.
// ../rfc/8460:326
if r.Status == dkim.StatusPass && r.Sig.Domain == d.msgFrom.Domain && r.Sig.Length < 0 && r.Record.ServiceAllowed("tlsrpt") {
ok = true
break