There is a decided tendency to create what I will call 'black-box'mailer configurations: you have a single mailer machine, and it is theonly thing that knows what is and isn't a valid local email address(and sometimes, what is and isn't a local host or domain name). In sucha configuration, the only way you can find out if a local address isgood is to feed it to your mailer and see if your mailer rejects it(hopefully at SMTP time

In PostfixVsExim I wrote that Exim is the better mailer if you want todo complex (even crazy) things, because it is more a mailer constructionkit than a mailer (with fixed, pre-existing features). For the benefitof people who haven't been exposed to Exim, I thought I'd illustratethis with one of the things we did in our local Exim configuration.

We have a long-standing system of simplemailing lists. These lists are nothing more than user-owned filesin

The usual case against backup MXes isthat they cause backscatter and they have less or no anti-spamprecautions. But these aren't inherent problems with the idea of backupMXes, just bad implementations; it's not particularly difficult to dobetter, and anything can be implemented badly. I think there's a morefundamental case against them.

Pretty much by definition, a backup MX exists in order to avoid losingincoming email if your primary MX is down for an extended period oftime. Outside machines

There's a potential confusion when one talks about 'backup MXes', soI'm going to throw some terminology around:

If an additional MX machine can accept inbound email and get itdelivered all the way to the user's inbox even when all other of yourMXes are down, you have a redundant MX .

If an additional MX machine can only accept inbound email but notactually get it delivered to your users (without the help of anotherMX), you have a backup MX .

Backup MXes

Yesterday, I noticed that Yahoo Pipes does a really irritating thing: ifsomeone has asked it to pull a syndication feed, it puts the Yahoo Pipesinfo page about the feed into the Referer header of its feed requests.

Wrong .

I feel very strongly that no automated web software should fill inthe Referer header, ever. In practice and custom (if not in thespec), Referer has a very well defined meaning; it is there to tellwebmasters where a real human visitor came from. If you do

(This story comes from my co-worker John Calvin, who told it to me someyears ago; I was reminded of it by some recent local events, so it seemslike a good time to put it here.)

One of the things that the central computing people here can do fordepartments is run their basic networking infrastructure, the switchesand wiring and so on. Once upon a time, such a managed departmentalswitch started lighting up the monitoring system with repeated, frequentcontact failures; when the monitoring

It is surprisingly challenging to get buffered IO completely correct onUnix, and one area that trips people up is correct handling of EOF. Yousee, there's an important different between EOF on files and EOF onterminals, as a consequence of how terminals generate and signal EOF : EOF on files is persistent, but EOF is onterminals is not.

If you read repeatedly from a file that has hit EOF, you will almostalways just get another EOF. But EOF on terminals is a transient thing,so

Here is at least a superficially appealing question: why is the endresult of giving your website an 'invite-your-friends' feature spamfrom you , as opposed to spam from your users andthus not your responsibility?

(For the moment, let's set aside WordsForWebmailProviders .)

There is clearly a continuum of email responsibility that runs from'email you send unprompted' (which is clearly your responsibility),through 'form letters that your users ask you to send' to 'you're an

There are two different (although overlapping) uses of conditionalGETs , especially the HTTP ETag header; reducing bandwidth, andreducing your computation. A successful conditional GET always reducesbandwidth usage, and it may let you skip doingexpensive operations to compute the request page.

Reducing bandwidth is useful in general because it improves the userexperience (although these days there is evidence that the big time hitcomes from the number of requests, not their size), but it probablydoesn't help your servers very much; most