Attending the Global Cyber Alliance’s DMARC Bootcamp has motivated me to move past just implementing SPF and so implementing DKIM and DMARC too. So far the bootcamp hasn’t talked about implementation details but searching the web turned up some useful tutorials on how to implement it on a Debian host using postfix and bind9. The first one was

https://www.linode.com/docs/email/postfix/configure-spf-and-dkim-in-postfix-on-debian-9/

I didn’t need the SPF instructions but the DKIM ones were very useful. At step 8 it sets the algorithm as “rsa-sha256” but I changed it to “sha256” instead. This means that the “txt” file generated can be simply cut’n’pasted into the DNS without modification. I use bind9 rather than Linode’s DNS manager so I didn’t bother joining the multiple parts of the public key as bind9 was happy with the record as it was (always handy when you plan to create a script to update it).

I chose to make the selector more specific, in case I needed more than one update a month while I was debugging it but maybe a single digit would have been sufficient and I used an inet socket rather than a local one (for no particular reason).

The section on DMARC in this tutorial only configured the DNS record so I had to search for another page to find out what to do with it and I found that at

https://www.skelleton.net/2015/03/21/how-to-eliminate-spam-and-protect-your-name-with-dmarc/

opendmarc is in the standard repository so there is no need to play with backports. I added “IgnoreAuthenticatedClients true” to the opendmarc.conf file to take into account that users use an authenticated submission to send email. Without it there was an erroneous Authentication-Results indicating that dmarc had failed for mrp.net. This didn’t seem to have any impact on sending email to Google but I wanted to get rid of it.

Applying the mysql schema also turned up a problem when creating the domains table failed. It looked like it should have worked but it would seem that a character was larger than I expected. I added “DEFAULT CHARSET=utf8” to the domains and reporters commands to get around that problem.

When I first used the report_script I executed it in a directory that opendmarc couldn’t write in so the opendmarc-reports script failed. It seemed prudent to modify the script to “cd ${WORK_DIR}” even if it was only to be accessed via cron.

I haven’t modified spamassassin’s rules as I want to check the SPAM like email I receive to see if it would make a difference.

So far I’ve received aggregate reports from Google and Oath. It would seem that a number of sites in China are trying to send it email using my domain while the Oath report showed an attempt from Taiwan.