Oh no! My laptop just sent notifications to 10,000 users

Email functionality is something we web developers often forget to account for when working on client sites. It's so easy to forget that almost everyone has a horror story sending out a mass email to a site's users from the test server, or local development environment. Luckily, there are a few different ways to manage how emails are delivered from a Drupal site -- and prevent unwelcome accidents.

Method 1: Postfix Email Rewriting

Postfix is a popular mail server that's installed on many UNIX machines -- including the Mac OS X machines often used by developers. It supports the creation of rewrite rules that can channel email away from its original destination, and because it's so widely supported, this is my preferred method of preventing accidents. Postfix maintains a "canonical" database which is used to determine address mapping for local and non-local addresses. The canonical file is incredibly powerful, as it can use regular expressions to rewrite email destinations. Unlike the aliases or virtual files, the canonical file will rewrite mail headers as well. For more information, see the canonical man page. This method will redirect all mail sent, so it's great if you have non-Drupal applications on your system as well.

To set up the canonical address table:

1. Load up the terminal and change to the postfix configuration directory with cd /etc/postfix
2. Edit main.cf as root with your editor of choice: sudo vim main.cf
3. Add the following line to the end of main.cf:
   
   canonical_maps = regexp:/etc/postfix/canonical
4. Create and edit a file, with sudo, called canonical if it doesn't exit. It should exist on OS X by default, but only contain comments.
5. At the end of the file, add a line with the following to redirect all mail to your local mail spool, filling in your user name:
   
   /.*@.*/ USERNAME@localhost
6. Update the canonical.db file by running sudo postmap canonical
7. Test your mail rewrite rule by send a message with a command like date | mail -s Test me@myrealemail.com. Run mail from the command line to view your message.

It's possible to redirect messages to a real account somewhere. However, it can be tricky to set up depending on your ISP (most will filter outbound port 25) and you run the risk of being caught by spam filters. For development servers this shouldn't be an issue.

Note for OS X 10.8 users: If Postfix doesn't seem to be running for you, take a look at this fix for Postfix. While postfix used to be an "on demand" service that would automatically run when needed, it was disabled entirely for me after upgrading from OS X 10.7.

Method 2: Reroute Email

Reroute Email is a Drupal module that allows for both redirecting email and whitelisting specific addresses from rerouting. It's great for stage environments where QA or other team members might need to update rewrite rules. Simply enable the module, and browse to admin/config/development/reroute_email to configure it. One thing to keep in mind is that only the first email address is the redirect address. Subsequent addresses are whitelisted from rewriting. For example, in this configuration, qualityassurance@myproject.ca gets copies of all emails except those sent to admin@myproject.ca.

Method 3: Devel's mail logger

The Devel module ships with a replacement mail library that writes all emails to the watchdog instead of delivering them. This is great if emails can't be sent at all from a development environment, or when emails are plain text and don't need to be viewed in a mail client. Add the following to settings.php to enable the mail logger.

$conf['smtp_library'] = 'sites/all/modules/devel/devel.module';

With these three methods, you never again will have an excuse to send out unintended emails from your development environment. What other tips have you used when debugging email notifications?