My OpenDMARC package recently broke following an update. Investigating what had happened, it appears that version 1.4.0 has introduced a new feature i.e. support for ARC.

This has required a few changes both in packaging and runtime environment. I am using archlinuxARM and their packaging of OpenDMARC is taken directly from upstream Archlinux. Unfortunately, the packagers missed the requirement that OpenDMARC-1.4.0 needs perl-json.

The added support for ARC also requires additions to the Report Database schema in the form of some new tables and extra fields on existing ones. The History file format has also changed and requires some manual intervention.

In summary, after an update of OpenDMARC to 1.4.0 you need to do the following:

• For Archlinux package opendmarc-1.4.0-1, also install perl-json
• Update your Report Database with e.g. schema.mysql (recreating the database is the easiest method)
• Truncate your existing history file before the next scheduled report import time

I have raised a bug report against Archlinux for opendmarc-1.4.0-1 missing the perl-json dependency so later versions of this package should fix this.

No, I'm not talking about a new human member of the family. Today marks the first week of life for our ARM-based Home Server and, so far, things are going very well. What's been achieved during this short period?

The Postfix and Dovecot mailserver has been verified as working. OpenDKIM and OpenDMARC checks and report generation are working fine. ClamAV has been scanning incoming and outgoing email and caught a few incoming virus-infected ones. Needless to say, SMTP and IMAP services are both experiencing brute-force password cracking attacks at moderate levels.

Lighttpd has been provisioned with Let's Encrypt certificates for the small number of virtual-hosted domains it serves. HTTP to HTTPS request promotion has been implemented and this blog is being served on the primary domain. Certificate updates are handled by acme.sh and its deployment mechanism distributes them to the containers providing the hosted services.

Prosody is serving, at the moment, one multi-user chatroom (MUC) with less than a dozen participants. The configuration has been updated to add server-to-server two-way communication over a single connection (mod_bidi) and stream management (mod_smacks) for message retrieval following a disconnect and subsequent reconnect from either a client or server connection. Audio and video calling hasn't yet been tested but should be functional.

General infrastructure management is operating well with DHCP, DNS, NTP, firewall and routing functions operating correctly. Memory usage is good with 600MB-800MB of the 2GB RAM being available as spare under normal operating conditions. Networking performance is good, achieving a 160Mbps download speed with 5G WiFi for our 200Mbps cable Internet connection.