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
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
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
If you need this, the best way is to make a
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 18.104.22.168/24 26291 1277K cox.net 22.214.171.124/24 18222 885K cox.net 126.96.36.199/24 14045 637K bellsouth.net 188.8.131.52/24 13151 631K adelphia.net 184.108.40.206/24 10280 617K centrum.cz 220.127.116.11 10174 529K 18.104.22.168 9019 433K 22.214.171.124 8135 447K 126.96.36.199 4854 233K 188.8.131.52 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.
- 184.108.40.206 and 220.127.116.11 return from last week. I note with interest that 18.104.22.168 is now in SBL53250, attributed to a 'Mesa Media'; I always like having my suspicions confirmed about blocks.
- 22.214.171.124, 126.96.36.199, and 188.8.131.52 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
Fourteen of the top 30 most rejected IP addresses were rejected 100
times or more this week; the leader was 184.108.40.206 (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:
|what||# this week||(distinct IPs)||# last week||(distinct IPs)|
The most active source of bad
HELOs was 220.127.116.11 (70 rejections),
followed by 18.104.22.168 (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
bridgetteswanson. About half the total bounces went to
ShannonMueller, followed by a number of previously
existing local usernames, and finally a few things like
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.)