After all of my worrying and investigation of modules to handle protocols for me, I wound upwriting an encoder and a decoder for sendmail's milter protocol by hand because it was the simplest way. Thisis because the milter protocol is a sane binary protocol and it turns out that there's astraightforward way (at least in a dynamic language like Python) towrite a codec for such a protocol.

As a sane binary protocol, the milter protocol starts with a packetformat:

uint32  lenchar

We get a certain amount of email with envelope sender addresses thatlook like your typical modern mailing list software's bounce managementhandling. They have what looks like individualized addresses and oftenhave 'bounce' in either the local user part or the domain (such as anemail message from 'bounce.global.expediamail.com').

I don't particularly look at sender addresses of email to our users.I know about these messages and addresses because some of our usersautoreply to these messages, and those

I recently read yet another article on TDD, and one of the things thisarticle talked about was the benefit of reading tests in order tounderstand what the code was doing.

When I thought about someone doing this to my tests, I laughed hollowly.

One of the little dirty secrets about the tests I write is that theyare, well, slapped together. I almost invariably write tests in the mostexpedient and brute force way, and I don't particularly write commentsabout what the tests are testing and how

I recently stumbled over this comment on a LWN article about object oriented design patterns in the Linuxkernel . Quoting a bit from theoriginal article, Auders asked:

Though it seems obvious when put this way, it is useful to rememberthat a single object cannot have two reference counters - at leastnot two lifetime reference counters [...]. This means that multipleinheritance in the "data inheritance" style is not possible.

The standard CPython implementation of Python uses reference counting,and yet it supports multiple inheritance

One of the things that the challenge of disabling an account has made clear to me is that it's far fromclear just what disabling an account means to different people. I thinkwe can all agree that the user of a disabled account shouldn't be ableto use any of your authenticated services any more, but as alluded toin my first entry there are a number ofother things where it's not clear what should happen.

For example: should the disabled account still get email? Should their

A typical reaction on Reddit to my earlier entry on the complexity of disabling accounts is this:

Couldn't this be solved by moving to an LDAP based (or AD for windowsenvironments) login?

Unfortunately, the answer is no; a directory service doesn't makedisabling users much easier, not by itself. The problem is inherentlycomplex.

Let's imagine that we have some directory service; it stores userinformation, including multiple passwords, and it has a 'disabled'flag. What has to

In Wait, Not That Bit! ,Greg Wilson writes about the problem of making a bunch of unrelatedchanges to a single file and then having to commit a big bullet listof changes. A discussion of splitting existing changes into multiplecommits and how you test the resulting separate commits then ensuedin the rest of the entry and the comments.

However, I'd like to note that there is a fundamental conflict inherentin this workflow. We want VCS commits to be very easy and lightweightso that developers will actually

A commentator on the last entry asked:

Any particular reason you don't like NIS and/or LDAP?

The answer for NIS is relatively easy. Shorn of various bits and pieces,NIS is just a file distribution mechanism. Well we have one of those , and ours is simpler, far more flexible, morepowerful, and much more transparent and thus easier to understand andreason about. There is nothing particularly unique about our mechanism;these days there are a great many ways to distribute files around (and

Question 31 on Tom Limoncelli's sysadmin test is:

G.31 :Can a user's account be disabled on all systems in 1 hour?

This may be more complex than you think. I'll use our localenvironment as an illustration.

We have a central password distribution system .It'd take me about thirty seconds to edit the master /etc/shadow in order to lock someone's password in it (and then a couple ofminutes for this to get propagated around)