Wandering Thoughts archives

A recent spam oddity that I've been mulling over

One of my habits is that I don't directly subscribe to mailing lists; instead, I subscribe aliases to them and forward the aliases to me. These aliases are generally purely collection points that are almost never used as the From: address or explicitly copied on messages. As a result of all of this, these aliases should never get spam and almost always don't. All of this is background.

A couple of weeks after our phish compromise incident, one of those aliases received a distinct burst of spam, hitting it on Thursday, Friday, and then the next Tuesday and Wednesday. All of the spam messages were various sorts of phish attempts but not for banking credentials; they targeted business services (efax.com, adp.com, American Express, and the Better Business Bureau). Most of the phish attempts were your standard fake website things, but one of them was trying to get you to run a zipped Windows executable (some online analysis sites say that as expected, this is an already-seen trojan). Based on evidence in the message headers all of these phish attempts had multiple recipients here, not just my little alias.

So in short, a couple of weeks after a phish compromise we were spammed with a significant phish spam run that hit even a normally invisible address. This makes me wonder two questions.

First, did our initial phish compromise somehow read out a significant portion of our local addresses and then pass them on to other spammers? On the one hand, this would explain why this spam hit my alias. On the other hand, it's hard to see how it would have happened. I don't think that our webmail systems support this, it's far from obvious how to do this on our machines, and there wasn't any evidence that the spammer accessed our systems apart from webmail.

(I was going to say that this alias had never appeared anywhere and had never been spammed before, but both turn out to be wrong. It's appeared in a place or two and it did receive an advance fee fraud spam back at the start of July.)

Second, did the initially successful phish spam cause the followup? I can certainly construct a story where spammers find it useful to target further phish spam at places where some phish spam has already worked; after all, suckers are suckers. On the other hand it certainly could be a coincidence. The compromise phish spam was specifically targeted against us (with specific organization names and so on), but the followup phish spam is very definitely not; it's targeting generic business services, not services that a university department would plausibly use or care about. At a minimum it suggests that the spammers behind the targeted phish spam were a different group than the people behind the followup.

What I would like in colour-specification interfaces

There are a lot of programs and systems and so on that let you specify what I'll call 'absolute colours'; this RGB value for the foreground, this RGB value for the background, and so on and so forth. My personal opinion is that this approach to specifying colours is too low-level for most uses.

We know a fairly large amount about how people perceive colours in relation to each other; some of it comes from scientific research and a great deal of it comes from the surprisingly pragmatic world of art. In practice, you almost always want to specify colours that follow the principles derived from this knowledge. Or to put it directly, you almost always want colours that work well together in whatever relation they're supposed to have.

This is why I say RGB-based colour specification is too low level. In practice you do not pick RGB values out of a hat with no reference to each other (at least not if you want the result to look decent); you go through some process of harmonizing the colours and deriving some colours from others, working out all of the RGB values in the process. What I really want for specifying colours is something that automates this; it would let me start with a base colour or perhaps a small set of colours and then derive other colours from them through perceptual operations like 'make a desaturated, less obvious but still readable version of the foreground colour'.

(I know, desaturation is a basic and sort of simple operation. I'd like much more ambitious features, such as automatically deriving complementary colours and avoiding colour pairings that cause problems for people with various sorts of colour blindness.)

This grump is brought to you today by xterm, where the common set of colours are specified as absolute values and are definitely not designed for black text on white backgrounds, red text on white backgrounds, or in fact any of the foreground and background colour combinations I use.