This quick tip is for Mozilla Thunderbird users who use Thunderbird with an IMAP account, but also use another mail user application (MUA) such as Outlook or webmail. If you’re in a similar situation, you might notice that when you delete messages in Thunderbird, they remain visible in your other MUA, until you exit Thunderbird. This can be especially impractical, for example, when you left Thunderbird running at the office and go to check your webmail from home. All of the spam you deleted in Thunderbird is still sitting there.

Fortunately, there’s an extremely simple solution to this problem. In Thunderbird:

Preferences -> Advanced -> Config Editor…

Search for “expunge”, and enable the “mail.imap.expunge_after_delete” option by double-clicking it. You need to restart Thunderbird after applying this setting.

Here are the before and after shots:

This setting tells Thunderbird to automatically “expunge” (IMAP terminology for “permanently delete”) any messages that have been deleted within Thunderbird. Otherwise, it just marks the message with a “delete” flag that many other mail clients ignore by default.

The “expunge_after_delete” option should be safe to use; your Trash folder will still work normally. This setting only controls the communication with the email server.

Today, I received numerous forwards of an email that apparently comes from eNom. If you receive this email, delete it, it is a scam.

The rest of this article will cover a few low-tech tips anyone can use to identify similar emails.

This is fine for me to tell you, but how would you have determined this for yourself?

Dead Giveaways

This email appears to be legitimate; it comes from an enom.com email address (enom is a major, reputable seller of Internet domain names), and has a sufficient amount of convincing technobabble. However, there are a couple of highly suspicious bits, here:

1. They say the main site (www.enom.com) is going to be down; why would they give you a link to www.enom.com to access your account?
2. Why would you need to access your account in this case anyway?
3. The grammar in the email is spotless, except for the line about the account information: “For access your account follow this link” — most likely, the phisher (and apparently, bad grammarian) took a real email from eNom, and added this line.
4. Most damning, but also least obvious (and the hallmark trait of a phishing email) is that the link appears to go to http://www.enom.com/, but if you hover over the link in most email programs, you’ll see the real destination:

Instead of going to www.enom.com, you will be taken to www.enom.comsys52.net. Most modern email programs and web browsers have technology to attempt to detect this, but the technology is not perfect. And, phishers’ nefarious livelihood depends on exploiting any weakness in such systems. So, your best defense is always to be aware of the risks, and learn to pick up on these “phishy” characteristics.

If in doubt, always err on the side of caution; avoid clicking links in emails–instead, go to the company’s web site from your browser’s bookmarks, or look them up and give them a call if you feel they may actually need some information from you.

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.