Wandering Thoughts archives

A limitation of Python properties

A periodically annoying limitation of Python properties on instances is that you cannot remove or replace a property. (You can implement del in your property, but this is not the same thing.)

This restriction exists because properties are actually attributes on the class, not attributes on the instances. Because of how attribute lookup works, you can't even sneak a replacement in through the instance's __dict__.

This means that you can't use properties to implement a highly efficient 'generate once and then cache the answer' instance attribute, where the first time you access obj.x the value gets generated and thereafter access to it goes at plain instance attribute speeds. This matters, because property access is about three times slower than accessing a simple attribute (and a plain function call to a lambda is about twice as slow).

If you need this, the best way is to make a __getattr__ function that creates the variable the first time it's accessed. This is somewhat less elegant and more monolithic than a property approach, and has the other downside that pychecker will probably complain about access to those magically created variables.

Sidebar: an interesting gotcha in timing attribute access

I did my timing of various attribute access cases using single-letter variable names. To my surprise, there were significant performance differences between the same access method based on what letter I used for the variable name. I suspect that this is because of dictionary hash collisions.

I also accidentally discovered that accessing class attributes is slightly faster than accessing instance attributes (and I don't think this one is dependent on variable names).

Weekly spam summary on April 7th, 2007

This week, we:

• got 13,022 messages from 240 different IP addresses.
• handled 18,021 sessions from 1,234 different IP addresses.
• received 169,572 connections from at least 5,382 different IP addresses.
• hit a highwater of 43 connections being checked at once.

Volume is about the same as last week, although evidently we got a big burst of connections some time this week.

This is surprisingly flat, with the exception of Thursday; I'm used to more day to day fluctuations.

Kernel level packet filtering top ten:

Host/Mask           Packets   Bytes
68.230.241.0/24       26291   1277K cox.net
68.230.240.0/24       18222    885K cox.net
205.152.59.0/24       14045    637K bellsouth.net
68.168.78.0/24        13151    631K adelphia.net
213.29.7.0/24         10280    617K centrum.cz
213.4.149.12          10174    529K
216.40.35.71           9019    433K
72.249.13.82           8135    447K
216.40.35.67           4854    233K
216.40.35.70           3966    254K

This is about the same as last week, although this week all of the top five spots were claimed by advance fee fraud spam webmail senders; as with last week, I put them in the kernel level blocks early on.

• 213.4.149.12 and 72.249.13.82 return from last week. I note with interest that 72.249.13.82 is now in SBL53250, attributed to a 'Mesa Media'; I always like having my suspicions confirmed about blocks.
• 216.40.35.71, 216.40.35.67, and 216.40.35.70 are all part of 'webmaillogin.com', which we no longer accept email from after it sent us advance fee fraud spam (just like pretty much every other free webmail provider out there).

This is a rather depressing set of top ten IP addresses, and I think it illustrates the degree to which advance fee fraud spam has risen to be a serious problem.

Connection time rejection stats:

  45752 total
  24453 dynamic IP
  15061 bad or no reverse DNS
   4610 class bl-cbl
    261 class bl-pbl
    182 class bl-dsbl
    131 class bl-njabl
     82 cuttingedgemedia.com
     73 class bl-sdul
     69 reliablehosting.com
     64 midtowndeals.com
     54 acceleratebiz.com
     50 class bl-sbl

The highest SBL source this week was SBL52928 with 14 rejections (a hijacked server used to send spam), then SBL51080 with 8 rejections (a phish source).

Fourteen of the top 30 most rejected IP addresses were rejected 100 times or more this week; the leader was 76.176.53.227 (216 times, a rr.com cablemodem). Seven of the top 30 are currently in the CBL, only two are currently in bl.spamcop.net, 8 are in the PBL, and a grand total of 15 are in zen.spamhaus.org.

(Locally, 15 were rejected as 'dynamic IP', 11 were rejected for bad or missing reverse DNS, one was a cuttingedgemedia.com machine, one was a reliablehosting.com machine, and there was a smattering of other reasons.)

This week, Hotmail managed:

• 1 message accepted, probably not spam (but then, it wasn't from Hotmail itself).
• 1 message rejected because it came from a non-Hotmail email address (a msn.com one, in this case).
• 33 messages sent to our spamtraps.
• no messages refused because their sender addresses had already hit our spamtraps.
• 6 messages refused due to their origin IP address (three in the CBL, one from SBL38278, a listing from February 22nd 2006, one from Nigeria, and one from saix.net).

And the final numbers:

The most active source of bad HELOs was 69.15.68.98 (70 rejections), followed by 70.19.117.14 (56 rejections). The bad HELO numbers are up compared to last week, but not hugely.

Bad bounces were sent to 25 different bad usernames this week; the most popular destinations at two attempts each were noreply and the made up username bridgetteswanson. About half the total bounces went to usernames like ShannonMueller, followed by a number of previously existing local usernames, and finally a few things like sandychampion.

Earthlink.net was the largest source of bad bounces, sending to both sorts of the firstname plus lastname bad usernames. The remaining bad bounces came from all over, with no particular pattern.

(I am sort of puzzled that we didn't get more bad bounces. While the spammers are clearly forging our domain on MAIL FROM addresses, they apparently aren't doing it on very much of their spam.)