20 August 2003
Spent a bit of time writing a reply to kiko‘s proto-PEP about fixing Python’s handling of LC_NUMERIC.
As it stands at the moment, Python requires LC_NUMERIC to be set to C in order to function correctly (important things like parsing of floats in source code break if it is set to a locale that uses a comma as the decimal point). They then have some hacks that allow you to parse and format floats according to locale conventions. This all works great in a pure Python environment.
However if you have another library that want to display or parse floats in a locale sensitive fashion and want to use it with Python, things start to break down. If the library isn’t Python specific, it is unlikely to change (after all, it is just using standard C library functions according to the specification). One such library that falls into this category is GTK+, which is where kiko first ran into the problem.
I think most of the Python developers realise that the current code is a problem now, which is good because it is the first step to getting it fixed.
Like most people, I woke up today with about 50 or so bounce messages in my inbox. I have a set of header_checks rules in my postfix configuration that reject windows executable attachments, so I never actually received a copy of the actual worm, but I received many many rejection messages from other servers, since the Sobig.F worm forges the From: address.
I quickly modified the mail filters to discard rather than reject Sobig.F messages, to make sure we aren’t adding to the problem.
I am surprised that none of the major server side anti-virus products correctly discard these virus messages with forged senders. They all seem to identify the type of virus, so they should be able to control what action is performed based on the virus type (for mail viruses that don’t forge the sender, rejection still seems like the best option).