A Stricter DMARC Policy, Part II

Last month, we let you know a stricter DMARC policy was being applied to Kolab Now infrastructure. With a primary aim to increase our reputation and decrease phishing attempts from clearly false senders, we’ve since learned about some secondary effects;

A concept known as “alignment” is taken very strictly. For some reason, the specification for DMARC specifies this involves the party signing emails (i.e. Kolab Now) must use a domain-specific key connotation in its signature, which matches the domain in which the RFC 5322 sender resides. In other words, a Group Manager account for the kolab.org domain cannot set its DMARC policy’s adkim parameter to s (strict), unless the Kolab Now infrastructure uses a private/public key pair for kolab.org specifically, and provides the DKIM signature with a connotation d=kolab.org.

Our documented recommendations for Group Managers has been updated to reflect this implementation detail.

At the time of this writing, all domains that are not explicitly listed with a separate signature are signed as originating with d=kolabnow.com (thus signed with any of the keys for kolabnow.com). Amavisd does not currently appear to support looking up domains eligible for DKIM signing using the LDAP protocol.

Also, we have no means to allow customers to upload their own private/public key pairs for DKIM signing.

All together, this to me seems like a flaw in the design and/or implementation of DMARC. As a service provider, I clearly and very explicitly wish to not have to hold any private keys except my own — even DKIM key pairs our service generates for domains registered with us would not provide sufficient security. Maybe there’s not going to be another option — but we’ll continue searching 😉 Stay tuned!