Wandering Thoughts archives


Some quick CBL stats

Last night I shuffled our antispam rules to put checking the CBL before everything, including our per-IP-address greylisting.

Since 3:20am this morning, 83% of the connect-time SMTP rejections were due to the CBL, for 88% of the IP addresses (4,180 out of 5,000 rejections from 3,038 different IP addresses out of 3,455).

So the simple recommendation seems to be: if you can only deploy one DNS blocklist, use the CBL. (Better yet, use the XBL, since that includes the CBL as well as a few others.)

It's also a depressing testament to just how much of our SMTP load is from compromised zombie machines. Over roughly the same time period, we had successful SMTP connections from only 271 different IP addresses, which means that around 82% of the IP addresses that tried to talk to us were zombies. (And probably still are zombies.)

Some of the zombies were pretty persistent about it; the top honors goes to, with 22 connection attempts refused.

spam/CBLStats-2005-06-27 written at 23:52:44; Add Comment

Dangerously over-broad error catching

One of the stock pieces of advice about writing Python code is that basic error checks should be handled by catching the exception that trying to do the operation generates, instead of through explicit checks beforehand. For example, if you are getting the value for a key from a dictionary (what some other languages call a hash), you don't bother checking to see if the key is in the dictionary beforehand; you just try to get the value.

This code might be written like this (especially in examples):

    result = some_func(dict[key])
except KeyError:
    # key isn't in dict.
    result = None

Unfortunately, this code has a serious, somewhat subtle problem; the try: ... except clause is too broad.

You probably wanted result set to None just if dict[key] didn't exist. But with this code, it will also happen if some_func or anything it calls raises an otherwise uncaught KeyError exception. Such uncaught KeyError exceptions are probably real bugs that you want to fix, but this code is hiding them.

You should be doing as little as possible in try/except blocks that catch general errors, because that way you minimize the risk that you're accidentally sweeping unrelated errors under the carpet.

It follows that the worst version of this is to write a try/except block using 'except:' so that it catches all exceptions. Please don't be that lazy.

python/BroadTrys written at 00:18:11; Add Comment

By day for June 2005: 11 12 14 16 17 18 20 21 22 23 24 26 27 28 29; after June.

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.