As illustrated in yesterday's entry , one of the problems of the (E)SMTPprotocol is that after a SMTP server has accepted all of the message'sdestination addresses and gets to see the actual message, it has noway to tell the client that the message was delivered to only some ofthose addresses. This decision made perfect sense at the time thatSMTP and then ESMTP were being created, because back then most of theplausible per-address problems could be detected at RCPT TO timeand if

Once upon a time it was acceptable for an Internet-facing mail systemto promiscuously accept all email during SMTP conversations withoutchecking to see if the destination user actually existed, and then sendout bounce messages if it found problems. Those halcyon days are over,killed by changing circumstances andspecifically by spam.

The problem spam causes for accept-then-bounce is simple:

• most email is spam
• a good chunk of it goes to incorrect or outright random local usernames
• almost all spam has forged origin addresses
• some amount of those

For those people who haven't heard, Red Hat recently suffered a security breach that allowed an attacker to get some bogus OpenSSH RPM packagessigned as valid Red Hat Enterprise Linux packages. Red Hat says thatthe packages were never added to RHN, the update system for Red HatEnterprise, but presumably the attacker has copies.

(That the package signing is separate from RHN makes sense to me, sinceI expect that Red Hat needs to sign various sorts of RPMs for testingpurposes well before they may get put into

There is an important proviso for the first principle of analyzingcompromised machines : in practice, mostattacks are not that good or that thorough. In real life, as opposed tomathematically correct security advice, there is a tradeoff between yourcaution level and the amount of work you have to do (either in analyzinga machine or in reinstalling it) and sometimes it is appropriate to takesome risk in exchange for doing less work.

The truly paranoid will reinstall machines from scratch (and never mindthe disruption) if there

Here is something important: regardless of what people in IT like tothink, we don't really control user desktop machines if the users feelstrongly about it. We can try to dictate hardware and software standardsand we can often get away with it for a while, but in the end if theusers want something badly enough they are going to win.

This has really been the case for quite a while, but it is especiallyacute these days with desktops; the ultimate issue is that the usersjust have

One of the things that the situation with security fixes and the Linuxkernel changelogs illustrates isthe difference between programs and products. With a program, what youget is the program; with a product, what you get is the program and awhole ecology of things surrounding it, ranging from documentation tobackporting security fixes into older versions.

(This is why it takes a significant amount of effortto turn a program into a product, as Fred Brooks and others have noted. Icredit Fred Brooks because I believe The

Here is a Python question I have been mulling over since a commenton a previous entry : does codeportability across different Python implementations matter verymuch at the moment?

My suspicion is that the answer is 'not really in practice', becauseI don't see much motivation for moving code between the differentimplementations:

• the three leading implementations ('CPython' (the normal Python),Jython, and IronPython) exist in significantly different environments;you cannot really drop in one as a replacement for another, so

Probably like many places, we weigh the potential or actual disruptionof things like kernel updates against the risks of not updating whendeciding how urgent applying them is. As part of this, I have developeda personal way of sorting security issues into different categories thatI care about, with an end result ranging from not so bad to really bad(and if we are lucky, 'no impact, we can ignore').

For various reasons I feel like writing out the things I care aboutand look at today

I have recently started thinking about the concept of what I will callthe 'error distance' of sysadmin commands: how much do you have tochange a perfectly normal command in order to do something undesirableor disastrous (instead of just failing with an error)?

(As an example, consider the ZFS command to expand a ZFS pool witha new pair of mirrored disks, which is ' zpool add POOL mirror DEV1DEV2 '. If you accidentally omit the ' mirror ', you will add twounmirrored