one verdict for a mail domain, sixteen checks in parallel
probe-mailserver answers one question about a mail domain: is anything
wrong with it right now. Sixteen checks -- MX and its address, PTR and
FCrDNS, SPF, DKIM, DMARC, CAA, MTA-STS DNS record and served policy,
TLS-RPT, the TLS certificates of ports 25, 465 and 587 against the name
of each endpoint, DANE/TLSA, the DNSKEY and DS without which a TLSA
proves nothing, open
relay in both directions, the RFC 2142 role addresses, DNSBL
listings, the SPF record of the MX host name (the HELO identity), and
the client-facing half -- SRV records and the autoconfig
and autodiscover documents an MUA reads to configure itself -- run in
parallel, each under its own deadline, so the probe costs the slowest
check and not their sum.

The argument may be the name of an MX host instead of a domain: the
probe then analyses the parent domain that lists it, on that host. -s
turns this off.

The default output follows the reed-alert probe contract: silence and rc
0 when everything holds, rc 1 and a single summary line on stderr naming
the failing checks, rc 2 when the probe itself could not do its work.
With -f json the same run is printed as one JSON object, the summary
line staying on stderr so an alerting daemon keeps working either way.
With -f text every check is listed with its verdict and its detail, for
someone reading at a terminal rather than a daemon.

The configuration comes from the file -c names, else from
/etc/probe-mailserver/<domain>.conf, else from
/etc/probe-mailserver.conf: one command watches domains that do not
hold the same policy. It reads that file and nothing else: no cache,
no state directory, no privilege. SMTP dialogues stop at QUIT, before
DATA, so no mail is ever sent.

Maintainer: Jean-Gerard Pailloncy <j-g@pailloncy.com>
