One of my domains has recently been suffering a spate of backscatter from an email Joe-job. Basically, spammers are sending out emails with forged From: fields, that appear to be sent from, say abcdef@ry.ca, to random recipients. There is no practical way to prevent or stop these attacks, since those emails never even come near my server before the recipients see them.

A significant percentage of the forged emails are either caught by the recipient’s spam filter, or are simply sent to addresses that don’t exist. Those messages should die right then and there, but some servers will actually accept the message, and then bounce it back to the (apparent) sender, instead of rejecting it immediately at the SMTP level.

It turns out there are enough of these servers to subject my server to over a million bounces per week.

The server runs exim, which uses a maildir format for its local storage, meaning, one-file-per-email. When I returned from my holidays, the filesystem had nearly run out of inodes (Linux/UNIX filesystems have a limit on the total number of files (inodes) they may contain–in this case, about 4 million).

I wrote some filter rules to drop the bounces to forged addresses, but I still had a directory containing a rather inconvenient number of files, to say the least.

Perl to the rescue

My goal was to prune the directory, but keep the most recent samples for analysis. Fortunately, exim stores each email with a filename beginning with the number of seconds since 1970 (a common timestamp method)–this eliminates the need to hit the disk again to get the actual timestamp of the file, which is a relatively costly operation. The following Perl script takes no parameters and gives no output; it simply deletes all exim email files that are more than 3 days old, from the current directory:

#!/usr/bin/perl

use warnings;
use strict;

my $DAYS = 3;  # Keep this much history

my $older = scalar time - 86400 * $DAYS;

opendir DIR, ".";
while (my $file = readdir DIR) {
    next unless ($file =~ /^(\d{10})\./);
    unlink $file if ($1 < $older);
}

I hereby release this code to the public domain. Use at your own risk; after all, it’s designed to delete files by the millions, very efficiently. It will potentially delete any file that starts with ten digits followed by a dot.

To mitigate the risk of accidental deletions (notably, some maildir implementations (e.g., cyrus) use sequential integers instead of timestamps), the script will not delete any files with nine or fewer digits. This corresponds to September 8, 2001, which should be fine for most purposes.

It took just shy of an hour to process ~4 million directory entries, and I was left with a far more manageable directory. Following this, I did some analysis on the remaining messages to help identify patterns and set up additional rules.

Markus Braun wrote an essential gnupg Vim plugin for Linux/UNIX users who regularly work with GPG encrypted text files at the command line level. (Or, perhaps, for those of you who probably should be working with GPG encrypted text files more often!) Best of all, installation is a one-liner, and it comes with some security benefits, while allowing transparent editing of encrypted files.

One-liner Installation

wget -O ~/.vim/plugin/gnupg.vim \

http://www.vim.org/scripts/download_script.php?src_id=9142

Yes, it’s usually that simple. However, if wget complains that the ~/.vim/plugin directory doesn’t exist, type mkdir -p ~/.vim/plugin to create it.

Usage

Using this plugin really couldn’t be much easier. Simply edit any encrypted file with a .gpg, .pgp, or .asc extension, and you’ll see something like the following:

$ vim top-secret.txt.gpg

"top-secret.txt.gpg" [noeol][converted] 3L, 1045C
You need a passphrase to unlock the secret key for
user: "Ryan Thompson <email@example.org>"
2048-bit ELG-E key, ID 12345678, created 2008-05-26 (main key ID 09876543)

Enter passphrase:

Bingo! Once you key in your passphrase, you will have a normal Vim session with the unencrypted contents of the file. Upon closing the file, the plugin will re-encrypt the file.

It also supports creating new encrypted files. If you edit any nonexistent file with a .gpg, .pgp, or .asc extension, you will first be prompted (within Vim) for a list of recipients in its own buffer:

GPG: ----------------------------------------------------------
GPG: Please edit the list of recipients, one recipient per line
GPG: Unknown recipients have a prepended "!"
GPG: Lines beginning with "GPG:" are removed automatically
GPG: Closing this buffer commits changes
GPG: ----------------------------------------------------------

It’s even smart enough to detect whether recipients are in your public keyring, and will alert you if any errors arise.

Typing the command :GPGEditRecipients will allow you to edit the recipient list on-the-fly.

Security Considerations

No matter which installation method you choose, I highly recommend you verify the download, especially when dealing with software that you are about to trust with your encryption and key data!

This plugin actually takes some additional precautions that would be difficult to achieve manually. This plugin:

• Does not use temp files. All editing is done in RAM; the plaintext is never written to disk
• Automatically disables the Vim swapfile and viminfo, to prevent cached copies of the data from being saved on disk
• Overrides Vim’s “write” command such that it writes back the encrypted file from the buffer

In short, this plugin makes encryption significantly easier to use on a daily basis, without compromising security (depending on your existing habits, it may arguably handle editing more securely). If that gives you the freedom to encrypt sensitive material that you previously couldn’t be bothered to encrypt, that’s a pretty big win (assuming, of course, that your Poodle doesn’t eat your private key–but that’s a topic for another article). My thanks to Markus for creating this.