gestaltware

Content that you publish and comments about the content you publish are both just as likely to be found beyond the ramparts of your website as within it.¹ In the latter case, a communication standard broadly called trackbacks has evolved to facilitate automated notification between websites, letting the original content publisher know that related information has been created and inserting a brief excerpt of the new content on the original site. Despite the obvious benefit of this reciprocal linking, trackbacks have also been criticized in both implementation and as yet another avenue for spammers to attack your site. Are trackbacks worth the effort?

The decision for me is an easy one: it comes down to whether you are interested in acknowledging a community beyond your website, desire to remain in the flow of this on-going conversation, and, in short, want to remain relevant. There are of course alternatives to using trackbacks, such as old-fashioned referral log parsing or using external services like Technorati, IceRocket, or Bloglines. However, none of these alternatives provide explicit context-sensitive connections like trackbacks, nor do they serve as annotations between postings when trackbacks are done properly.² While the decision for you may not be so cut and dry, the implementation is easy on a Drupal site with a contributed module.

Trackback module works well, though the instructions are a little sparse. As of the time of this writing, the project page did not show the latest 1.3 tagged release, which you will want since it adds an important anti-spam feature (discussed below) and a security fix. Make sure to download 5.x-1.x-dev in the meantime. I would recommend configuring Trackback to run auto-detection with cron on links only, and enabling both trackback moderation and reject one-way trackbacks.

On a popular site, the flood of trackback spam requests creates a large administrative burden. Trackback module implements a simple, but effective check to see if a link to your site actually exists on the referenced page before accepting an incoming trackback. In other words, you will never have to wade through and review the vast majority of trackback spam because it will be rejected at request (this unfortunately does address inherent weaknesses in the trackback specification itself). Trackback module could be further improved by:

• first checking if the trackback sender and webserver IP addresses are identical (lower cost than pulling the trackback referenced page)
• optionally bypassing the moderation queue for trackbacks from IP addresses that have previously been published (e.g. a whitelist)
• close accepting trackbacks for a given post after a certain period of time from publish date or last comment/trackback

I will add these capabilities as time permits. If you need more robust trackback spam handling, take a look at the standard spam-fighting contributed modules Spam and Akismet web service. Since there is no other notification that a trackback has been received, checking the approval queue will quickly get tiresome. The contributed module Admin block will speed up the process.

Edit October 15: the directions for testing trackbacks have been moved here.