For my sins, I am on one of the aliases here that gets a certain amountof reports of spamming theoretically committed by UofT IP addresses. (Iam not one of the people who has to deal with them, fortunately; it isa thankless job). This exposes me to a certain amount of good examplesof how not to report spam.

Today's example comes to us from an official government organizationin a large Southern American country. All the information they gaveus was:

• the date (with

This week, we:

• got 13,681 messages from 253 different IP addresses.
• handled 18,870 sessions from 835 different IP addresses.
• received 303,478 connections from at least 47,309 different IPaddresses.
• hit a highwater of 7 connections being checked at once.

Connection volume is majorly up from last week ; other numbers are up slightly,except the highwater (which is down). The per day table:

As a followup to what I wrote yesterday about prompt signal handlingin programs , it's worthwhile to pointout a little problem in Python with signal handling.

As I've noted before , Python normally turnsmany signals into exceptions. It turns out that this has an importantconsequence: it delays processing of signals , because Python onlyprocesses signal exceptions in the interpreter, ie when you're runningPython bytecodes.

(Contrary to the documentation, sys.setcheckinterval does not appearto control how often signal handlers are