It has long been good practice to use email-validation tools such as Sender Protection Framework (SPF) and Domainkeys / DKIM to provide confidence that a given server or domain has the authority to send emails on behalf of its own or other domains. We use Postfix and Amavisd-new on Debian to perform DKIM signing of messages on a central mail server that relays mail for many other servers. There were a couple of catches to getting it all working that I wanted to record for posterity, should anyone else run into similar problems.

First. amavisd-new can now (since version 2.6.0) handle DKIM signing itself, meaning you can do away with additional milters or the use of dkimproxy. To tell amavis that you want it to sign mail, you need only add this line to an appropriate config file (say, conf.d/50-user):

$enable_dkim_signing = 1;

Keys and selectors are assigned to domains by adding lines like so:

dkim_key('example.com', 'selector', '/var/db/dkim/example.com.key.pem');

(I am omitting the details of generating keys and creating the DNS records necessary to make DKIM work. There are lots of tutorials on the net that cover that material.)

The folks at Make Poverty History wanted to make sure they had good data about their participant records, and so asked if we could make the connect module update information about existing participants.

The WYSIWYG module does a great job of centralizing and abstracting the use of various graphical editors in Drupal. Its relative newness means it is poorly and confusingly documented in some respects. I recently had to add the headings plugin for TinyMCE and ran into a lot of confusing information about how to make that happen.

We use multi-site installations pretty much exclusively. Moving sites around (from development to production, say) can be a pain, especially when there are a large number of modules in sites/all/modules, relatively few of which are used by a given subsite.

I recently turned my hand to using drush to pick out just the enabled modules for a given subsite to make for easy migration. This is my proof of concept script; there is lots of room for improvement.

Apt-dater is a relatively new utility that allows easy package management of multiple Debian servers from a central control server. I wrote up the necessary steps below, as the existing instructions (http://www.ibh.de/apt-dater/) are slightly unclear on a couple of things.

We run Debian stable (currently lenny) on many servers. Apt-dater is new enough that it is currently only available via the lenny-backports repository. (NB: in what follows I assume knowledge of basic package management and ssh configuration. Help with both of these is widely available on the 'Net.)

OK, so the Connect module has actually been around for a while now, but the first version was painfully difficult to use, and the second version has only just seen an official, albeit beta, release.

Connect arose because we wanted to create a flexible and extensible online campaign platform for Drupal. The goal was to produce a framework that would allow different features to be added as necessary. Thus, a single tool could be used to create a simple petition or a sophisticated online email- or fax-sending campaign.

Setting up the CiviMail return channel is a notorious pain in the ass. The return channel is the mechanism by which email is passed back into the CiviMail system. It's necessary to allow replies and bounces to be handled by CiviCRM, making it fairly essential to the successful use of CiviMail.

The official way of setting things up is unfortunate in a couple of respects: it requires the installation of a customized version of the amavisd-new content-filtering daemon*, and it cannot handle multi-site installs. The "alternative" return channel implementation, although rumoured to not scale as well, requires no additional software, and can be easily adapted for servers hosting multiple domains that use CiviMail.

In recent months we have been transitioning from Fedora Core systems to Debian ones. Our standard install is Debian stable "Etch", and the standard slate of packages serves almost all our needs admirably.

With one exception.

CiviCRM 2.1, which is (barely) still in alpha requires PHP version 5.2.1+, and the version that comes with Debian stable is 5.2.0. The way around this is to install the Debian packages from the testing distribution, which currently offers the latest 5.2.6 version of PHP.

The CiviLingua project was an attempt to build i18n/l10n into CiviCRM core in the late 1.6 / early 1.7 release era. Details are available on the CiviCRM wiki:
http://wiki.civicrm.org/confluence/display/CRM/CiviLingua+-+support+for+multi-lingual+sites

And in my earlier blog posts:

I recently tried to add breadcrumbs to one of our client sites. We wanted breadcrumbs to reflect the location of the current page in the nested menu system. The usual Drupal breadcrumb functions failed utterly, returning bizarre values for the supposed menu items in the current trail. (Things like a negative int where one expects a positive value in a string.)