The spam forwarding problem is that when usersforward their email to somewhere else, they forward their spam too.Since we have a spam tagging system , we'd likeour users to not forward spam-tagged email; at the same time, we can'tmandate this as an absolute requirement (and thus implement it centrallyin the mailer).

You can certainly do this with procmail; selective forwarding is oneof the things that procmail is good at. But there's two problems, onesmallish and

I've written before about my desire that Unix mailers would allow moreforgery of outgoing email addresses, back in PleaseAllowForgery . At thetime I was thinking of direct usage for sending email yourself, but I'verecently realized that there's another important use for this: remailingthings from forwarding setups.

If you just want simple forwarding, you can do that in .forward .But if you want more sophisticated conditional forwarding, aroundhere the tradition approach is to use procmail with a suitablycomplex .procmailrc that

In part 1 , I casually tossed off that our newspares handling system 'reads out the state of all of the pools [and]sees if any disks need replacement', as if it's a trivial thing to do.In fact, it's not; one of ZFS's problems is that it doesn't exportthis information in any way that's particularlyuseful for other programs. As a result, my quick summary papered overwhat is in many ways the most complex part of

As I really should have expected, a number of people showed up in theUbuntu bug for their PAM versioning failure to say that thiswas no big deal and other people should relax about it. I disagree.

This PAM ABI incompatibility was not introduced by the upstream package(in a patch or a minor version update); it was introduced by Ubuntu'sown patching. Ubuntu makes a big deal out of doing only minimal changesin their LTS releases (so minimal that they generally will not fix bugs,only

From the logs of a SMTP server here:

32301#  remote from [66.249.67.36]32301r  GET /robots.txt HTTP/1.132301w  550 Syntax error32301r  Host: 128.100.3.51:2532301w  550 Unknown command 'Host'32301

Suppose that you are designing a protocol where the two ends (let uscall them the initiator and the target) must agree on a joint set ofoptions, actions, or whatever that they both support, will use, orwhatever. If you are doing this, I have a small request: please make theoption negotiation process symmetric, where the initiator and the targetdo the same operations (with slightly different data).

In a symmetric option negotiation process, the initiator says somethinglike 'I support the following

Suppose that you have a program that can run other programs, andyou want to find out if it securely runs the other programs . In an ideal world, the program'sdocumentation would tell you, and you could trust it. Sadly we do notlive in an ideal world.

First you need a test environment where you can control what externalprogram your program runs and force it to actually run the program. Inmany cases (such as testing daemons, web servers, MTAs, and so on),

I've mentioned before that we replaced ZFS's normalspares handling with our own system, but I've never actually describedthat system. For background, see my earlier entry onour issues with ZFS's normal spares handling and the challenges we havewith spares in our ZFS fileserver environment .

There are two ways to implement a spares system. Let us call themevent driven and state driven. In an event driven spares systemyou activate spares in response to fault events, and one of yourchallenges is

Every so often, people feel that their program needs to be able to runanother program under some circumstances; for instance, you're writinga mailer and you want to be able to run an external virus scanner tosee if a newly received message has a virus. A certain amount of thesepeople decide to use system() or popen() for this; as the sayinggoes, now they have two problems.

(The only time it's ever okay to use these routines is if the entire