3 Likes
#chatops
Today I produced the following script, that receives as input an email containing a DMARC XML report as an attachment, extracts the attachment, decompresses it, and queries the report to see if there are failures coming from any of the IPs that I use to send mail (ignoring those I don’t use/control), and sends an error message and the decompressed file to a room on my Matrix server for any failures it finds.
#!/bin/bash
TMP=$(mktemp -d)
SOURCE_IPS=$(host mail.koehn.com | grep address | awk '{print "\""$(NF)"\","}' | tr '\n' ' ' | sed 's/, $//')
cd "$TMP" || exit 1
function cleanup {
rm -rf "$TMP"
}
trap cleanup EXIT
FILES=$(munpack -f 2>/dev/null | awk '{print $1}')
for file in $FILES ; do
if 7z e -so "$file" | xidel --data - --xquery './/row[source_ip=('"$SOURCE_IPS"') and (policy_evaluated/dkim="fail" or policy_evaluated/spf="fail")]' 2> >(grep -v "Processing: stdin") | grep . ; then
mc -m "🔴 Received DMARC report containing failures: $file"
mc -f "$file"
fi
done
1 Comments
It took way too long, but my #ChatOps quest continues. Today I finished adding #Matrix support to my #Dovecot Sieve scripts, so that things like #DKIM and MTA-STS TLS reports could go to a matrix chat channel rather than sitting in a mail folder. Basically I now have an email 👉️ matrix bridge.
It took a fair amount of fussing about, mostly because (a) it takes matrix commander
(a Matrix CLI) a long time to post a message to Synapse (read: more than ten seconds), (b) Dovecot’s documentation for altering settings for external scripts is byzantine, and (c) rather than cramming matrix commander
into my already bloated Dovecot #Docker image I wanted to use the Docker image they provide, and I needed to work out a way to invoke matrix-commander
from another container on the same pod.
But now it’s done, and I have another vector for #admin alerts that I can coalesce into a single place for easy review.
One person like that