Hotmail spam stats revised
It turns out I made a mistake in my Hotmail stats for this week that missed some Hotmail rejections that were for @sympatico.ca addresses. There were actually 11 messages refused due to their IP origin, from six different IP addresses:
|Gilat Satcom (Israel)
|October 4th, 2005
|Gilat Satcom (Israel)
|December 2nd, 2005
|KPN Internet / 'Comminication Center Osdorp' (Netherlands)
As you might expect from the name, Gilat Satcom's customers are actually located all over; they appear to resell satellite Internet access widely, especially across Africa, and as a result are the source of a lot of advance fee fraud. Unfortunately they don't show any sub-delegations.
'Comminication Center Osdorp' [sic] is a /29 subnet under KPN Internet (and thus completely listed by the SBL). According to the RIPE WHOIS information, its admin and technical contacts are a Hotmail address (which at least still exists). The whole thing doesn't exactly inspire confidence that they're going to deal with the problems any time soon; at the worst, they may be part of the problem.
Other interesting things:
- five of the six IP addresses (everything except 18.104.22.168) are
- the three Versatel IP addresses are also in SPEWS. 22.214.171.124 is additionally in the AHBL (since April 8th 2004), the NJABL (since November 2002, listed for advance fee fraud), and SORBS's 'spam' subzone (since April 26th 2004).
- 126.96.36.199 is in SORBS's spam subzone (since October 16th 2005).
SBL34115 has nasty things to say about Versatel's continued tolerance of advance fee fraud spammers. I'm actually surprised that so many of our problems come from Versatel; it had not previously made my list of places to watch out for. Live and learn, apparently.
Using threading to implement a 'busy' cursor (a tale from long ago)
A very long time ago, I spent a year being an Amiga programmer as part of a small team writing an application. We wanted it to have a busy mouse cursor (the general hourglass 'this is going to take a while' cursor good apps put up during long operations), but what with one thing and another, we wound up with two problems:
- we weren't actually sure what user actions would take a long time.
- we got to 'implement a busy cursor' rather late in the whole process.
This left us in a kind of pickle; we couldn't just mark all of the slow operations, and there was no central place to flip to a busy cursor if things were taking too long. In fact, the application didn't even process events during long actions. But the Amiga was a novelty at the time: a personal computer with a preemptive multitasking environment. This led us to a semi-ugly hack: put the busy cursor handling in a second thread.
We added a little 'I am not busy' spot in memory that got flipped on every time we went through the main event loop. A second thread periodically checked the flag and flipped it off; if the flag was already off, it changed the cursor into the 'busy' cursor. Later, the main event loop flipped the cursor back to normal if necessary. The preemptive multitasking took care of everything else.
(The actual implementation was slightly more complicated than this.)
I call this 'semi-ugly' because of the time lag between a long operation starting and the cursor turning into the busy cursor. In the worst case your operation would finish just after the cursor had gone busy, giving the cursor a kind of a time-lag stutter. However, the thread-based implementation was small and really simple, requiring basically no changes to the main application, which meant that we at least got some sort of busy cursor into the program.
I've always had a fondness for this hack; it was the first time where I really used multitasking, and it could only have been done on the Amiga.