How spammers seem to be coping with greylisting

I have a machine (my Debian Woody machine) that has far less aggressiveantispam defenses than anything else (as a result of an old andincapable mailer that is the Debian Woody default). As a result, I getto see an interesting view of some current spammer methods, more or lesslive and unfiltered.

One of the interesting things is that when email addresses on thismachine get spammed, they usually get several copies of the samemessage, all from the same origin address and the same machine.

My


Doing DNS queries in Python

Every now and then, there comes a time when you need to make DNSqueries more complicated than gethostbyname and gethostbyaddr . Orat least, that's what happens to me.

When this happens, my best Python tool is the dnspython module , a pure Python modulefor doing all sorts of DNS manipulation. But dnspython is alittle bit obscure to use, so here's a sample program.

This program looks up IP addresses on the command line that are in the SBL and reports the URLs to their SBL


Spam Storm, July 26th 2005

There's a spam storm blowing strong this week and it's irritating me,because it's pretty much all coming from compromised zombiemachines. Again. Zombies are clearly the number one general spamproblem, and it's probably only going to get worse as more and more ofthe world gets more and more broadband.

The biggest indicator I have of the storm is simple: since 6am onSunday, we've had 233,000 SMTP connections. As mentioned recently,


What ASNs are most actively spamming us

In this context, 'ASN' stands for 'Autonomous System Number' ;broadly speaking, this tells us who is responsible for a particular IPaddress (or, technically speaking, who is ultimately responsible forgetting IP packets to it).

There's a number of who other ways to tell who owns an IP address(querying whois.arin.net and then other registrars, for example), butthere are two attractions of ASNs for this purpose:

  • there are comprehensive IP to ASN databases that are easily

Reliably archiving things

Reliably archiving things is a troublesome issue. There are a numberof places to find numbers for how long CD-Rs, DVD-Rs, and varioussorts of tapes all last, and lots of debate, and lots of people whowill sell you solutions, and so on. I don't have much to add to theirnumbers and marketing information.

But I have been around for long enough to have burnt my fingers andseen other people's fingers burnt, and thus I have arrived at what I


The necessary evolution of mail servers

In a comment on my Legend of Debian post,Chris Wage wrote in part:

Most of the servers I run are: webservers, mailservers, CVS servers,etc. These are things for which well-established stable software hasexisted for years. I don't need bleeding-edge software to do them. Ineed stable representatives of that software that are supported bysecurity updates but don't otherwise change.

I have to disagree with this in the case of mail servers.

Unless you actively enjoy getting spammed


Spam summary for July 23rd 2005

It looks like the hope from last week that spammers had stoppedforging University of Toronto subdomains as the origin of their spamwas in fact just a hope. 'Nonexistent local user' rejections are backup like clockwork. Oh well; it would have been nice.

IP level rejections:

Host/Mask           Packets   Bytes212.216.176.0/24       6663    339K213.4.149.11           6659

The Myth of Support (Part 2)

There's a story about vendor support people like to tell: if you payenough money, a lot of money, you'll get excellent support; but if youaren't willing to pay lots of money for support, clearly it's not really that important to you.

I don't know if paying lots of money gets you excellent support; I'venever worked for an organization that was in a position to pay thatsort of money. (I think you are unlikely to get


The Myth of Support (Part 1)

There is a story that salesmen like to tell you: if you buy everypiece of your system from them, you'll get excellent support becausethere's only one vendor involved. One set of people who knoweverything, one place to contact, and there'll never be finger-pointback and forth about whose fault something going wrong is.

This is a myth. Let's look at the reality.

Let's say that you want some front-end servers all talking to a big


Please produce useful error messages

I just helped someone whose Fedora Core 3 installation was producingthe following error message:

# yum check-updateSetting up repositoriesCannot find a valid baseurl for repo: updates-released

This is a beautiful example of a Unix tendency that people gripeabout: technically correct but completely useless error messages.While yum is correctly complaining that it cannot generate a valid URLfor the 'updates-released' RPM repository, it would be much moreuseful if it told us why, with an error message such as:

Cannot fetch