Wandering Thoughts archives

Some problems in common definitions of 'spam email'

The most common attempts to define 'spam email' is either as 'UBE' (Unsolicited Broadcast Email) or 'UCE' (Unsolicited Commercial Email); for example, the spamhaus.org definition here. I tend to think that this sort of definition of spam has some problems.

Let's start with a provocative question: is advance fee fraud (so-called '419' email) spam email? (You know this type of spam; the classic version has Mrs. Mariam Abacha, wife of the late Nigerian dictator Sani Abacha, asking you to help get her husband's fortune to safety.)

A peculiarity of advance fee fraud email is that the messages are often composed by hand (sometimes by people sitting in an Internet cafe in Nigeria) and sent to relatively few people. So it isn't necessarily UBE (or at least not straightforwardly).

One can say that this is UCE because it is 'commercial' in the sense of 'having profit as a chief aim' (cf this definition of 'commercial'), but I think that this is stretching the term. The sender hopes to profit not through a business transaction with you, but by defrauding you out of some money.

But let's go one step further. Take a message that was dumped into my mailbox in August 2005, that started with:

The forgotten facts in all religions are explained by Allah through Imam Iskender Ali MIHR.

This is clearly not UCE; there's no attempt to profit, just proselytize (for www.mihr.com). This particular example was probably UBE (but I don't know for sure), but sooner or later similar messages may be composed by earnest people in Internet cafes and sent out just to you. Does that make them not spam? I'm pretty sure most people would disagree and call such email spam.

Clearly people's practical, gut definition of email spam is wider than just UCE or UBE.

Spamhaus has a technical definition of spam that would include the 'Iskender' email above, because it had no personalization for each recipient. But what if the earnest young men start personalizing their proselytization, perhaps using information from your web page; is their email transmuted to 'not spam' just because they are doing research and typing things by hand?

Was it spam when a fire and forget Microsoft recruiter sent Eric S. Raymond (a well known open-source booster and no fan of Microsoft) a recruitment pitch? (It was probably sent by hand.)

This matters because there are a number of ISPs and other organizations that find it convenient to define spam as only UCE (or UBE, depending on the organization). If their customers are doing things that fall outside of UCE or UBE, you are generally out of luck. (And I'm sure that Microsoft would assure us that the email to ESR is definitely not spam.)

Perhaps this is why brinkster.com has yet to do anything about www.mihr.com (IP address 65.182.104.58), despite the August 2005 spam being sent from mihrfoundation.com (IP address 65.182.104.57 at the time, right next door). After all, it wasn't UCE.

The many consoles of Linux

People who are considering setting up serial consoles for their Linux machines often wind up a little bit confused about what's necessary and what sort of features are possible. A lot of this is natural, because the PC is fundamentally convinced that the console is the more or less mandatory video display.

This results in a situation where there are many different consoles in a Linux system. I'll inventory them, in the order that they get encountered during booting a system.

1. where the BIOS output appears. Expensive servers (and expensive addins) can change this from 'only the video display'
2. what the bootloader talks to; how to configure this varies with the bootloader.
3. where Linux kernel messages go. This is set by the kernel's 'console=...' arguments; you can specify multiple places. The kernel listen for so-called 'magic SysRq' keys on all of these.
4. what is /dev/console. This has to be a single real device, and is either the last console=... device listed or the video console.
5. where you can log in after the kernel has finished booting, which is determined by what /etc/inittab says to start getty on.

/dev/console is what init talks to during system startup (and system shutdown). This means that it's where startup messages appear (barring things like Red Hat's simplified graphical boot process) and what you need to interact with during single-user mode or if an automated fsck fails and needs a person to help it out.

In many situations, the ideal answer for 'what device is the console' is 'both the video display and a serial line', and most of these many consoles allow this. /dev/console is the unfortunate exception; you have to pick just one, because the Linux kernel requires it to map to only a single real device.

(I sympathize with the Linux kernel about /dev/console, honestly. The issues involved with merging simultaneous input from multiple real terminal devices are kind of tricky, especially if you want to avoid hooking into very low-level input routines down in the depths of drivers.)