Last week the first Mongolian Network Operators Group meeting was held in Ulaanbaatar. Unfortunately I couldn’t attend but I managed to get a list of the attendees and added their organisations to the IPv6 Survey. No great surprises in the list. Most of the local companies only had IPv6 access through their email systems and only because they were using Google.

I recently tried to post a blog entry after upgrading WordPress from v4 to v5 and discovered that I couldn’t save a draft or publish it. The diagnostic in the console wasn’t all that helpful to me. Entries such as

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.mrp.net/blog/index.php?rest_route=%2Fwp%2Fv2%2Fposts%2F255&_locale=user. (Reason: missing token ‘x-http-method-override’ in CORS header ‘Access-Control-Allow-Headers’ from CORS preflight channel).
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.mrp.net/blog/index.php?rest_route=%2Fwp%2Fv2%2Fposts%2F255&_locale=user. (Reason: CORS request did not succeed).

This came as quite a surprise and challenged my ability to work out how to fix it. Fortunately I eventually discovered mention of a change of editor (which I had noticed) and that the old one was available so I installed it and my problem was solved. I still don’t understand what is going on with CORS but I have a viable workaround.

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.

I’ve changed the theme again and gone through the web site updating the photography pages so that they use a common configuration (and should use the theme’s font rather than some random one). I have tried to implement a content security policy, centralised the CSS and cleaned up the javascript.