ae68edbc58
Three bugs the owner hit: 1. Per-operator reputation alert (06:10 cron, mail_reputation_monitor --alert) silently never ran: it redirected to /var/log/pw-mail-reputation.log but /var/log is root-only and that file was never pre-created, so the deploy user's >> redirect failed and cron aborted before the command. Repointed both mail-alert crons to deploy-writable /opt/performancewest/logs/. 2. IP reputation alert (20:00 cron) still referenced the removed rehab pool (.91-.93) and used 8.8.8.8 for Spamhaus (which returns the open-resolver error, not a real answer). Dropped the rehab section, relabeled to the two live IPs (.94/.107), and switched the DNSBL check to Control D (76.76.2.0) which returns real Spamhaus ZEN data. (It was correctly SILENT lately because delivery is healthy -- silent-on-healthy is by design.) 3. DMARC daily digest was pure noise: it alerted on ANY external IP with >=20 failing msgs, but those are legit recipient-side forwarders/security gateways (inkyphishfence, cloud-sec-av, Proofpoint, Mimecast, ...) that re-send our mail and naturally break SPF/DKIM alignment -- benign under p=reject. Added PTR-based forwarder detection (FORWARDER_PTR_HINTS) so the digest tags them [fwd] and only alerts on (a) OUR IP <95% pass or (b) an UNKNOWN non-forwarder external IP with >=100 failing msgs = real spoofing. Verified: all 4 currently-flagged external IPs now classify as forwarder=True.
12 lines
1 KiB
Text
12 lines
1 KiB
Text
# Nightly mail-reputation snapshot. Parses the day's postfix log and upserts
|
|
# per-IP/per-receiving-operator delivery outcomes into mail_reputation_daily,
|
|
# giving an SNDS-equivalent reputation trend (accepted% / throttled% / reputation-
|
|
# reject%) WITHOUT any provider login. --alert sends a Telegram warning if a big
|
|
# operator regresses (>=10% reputation rejects, or Microsoft >=70% throttled).
|
|
#
|
|
# The host owns /var/log/mail.log (root) but the DB is only reachable inside the
|
|
# docker network, so we `sudo cat` the log (deploy has NOPASSWD sudo, same as the
|
|
# warmup-tg-alert cron) and pipe it into the DB-connected workers container.
|
|
# Runs at 06:10 UTC (before the 06:30 scrub + the 07:00-08:00 campaign builders)
|
|
# so it captures the full prior day before logrotate.
|
|
10 6 * * * deploy { sudo cat /var/log/mail.log /var/log/mail.log.1 2>/dev/null; sudo zcat /var/log/mail.log.2.gz 2>/dev/null; } | (cd /opt/performancewest && docker compose exec -T workers python3 -m scripts.mail_reputation_monitor --alert -) >> /opt/performancewest/logs/pw-mail-reputation.log 2>&1
|