In my Exim logs this morning I noticed a new tactic spammers have started using.

2006-06-14 14:19:24 SMTP protocol violation: synchronization error (next input sent too soon: pipelining was not advertised): rejected "To: tensai@joanna.zmonkey.org" H=(tensai) [202.1.206.213] next input="..."

I get these every now and again because I don't support pipelining and I have a 4 second delay on my SMTP greeting, but that's not what I'm showing you. The curious part is "H=(tensai)". For quite a while spammers have been using a strange technique of passing a HELO name of the host they connect to. The logic of that really is beyond me, but I really don't care since the way to defeat it is easy. Now they've mutated and the solution to this one is just as simple:

acl_check_rcpt:
  ...
  drop    message = but that's my name
          condition = ${if eq {$sender_helo_name}{$local_part} {yes}{no}}

That config will drop any message where the sender identifies itself as one of my users. There's a small danger that some server's name will actually have the same name as me, but I'm kinda doubtful. Most hosts will use fully qualified names, I would think.

I just ran into this problem, and it almost became a disaster but I luckily noticed the missing files in time, and I figured I should blog it so that nobody else repeats this mistake.

Did you know that the default behavior of 'find' is to not follow symlinks? Well I sure didn't. Yesterday I was tarring up a whole slew of files, some of which were in symlinked directories. Those ones were ignored. I ended up with about 2/3 of the number I expected, but for some reason I ignored my gut and continued on (never ignore your gut, especially if it's hungry!). By some saving grace I noticed the missing files just a few minutes ago and recovered.

So, the option is '-L' to follow symlinks. Remember that. 'find -L'. Perhaps a bash alias is in order...

Relational databases are powerful beasts. Rightly so they've replaced heirarchical databases for most types of data, directories being the notable exception. But things go wrong when someone who doesn't know jack squat about them is in charge. You'd like an example? Well, it just so happens that I have one. How convenient.

Head on over to americastestkitchen.com and take a look. See if you can find the error before you finish reading this post. Go ahead, I'll wait. Be careful if you sign up for an account as they'll seriously spam your email address. Make sure you uncheck the box that says "send me tons of crap", or whatever it was. Rotten liars. You know, they never did respond to my scathing email.

Anyway, their gimmick is simple. Recipes from the current episode are online, but previous episodes are only for subscribers to Cooks Illustrated magazine. Fair enough. How's it accomplished? Very poorly. A typical URL looks like this (trimmed for brevity): "/recipe.asp?recipeids=26&iSeason=6". The current season is 6, so any link to say "Season=4" will give you a "please pay us $$$ to access this content". Think about that for a second. What's to keep you from changing "4" to "6"? I'll tell you. Absolutely nothing. Try it out and you'll see.

The proper way to do this is to use a relational database (getting back to our topic) to link RecipeId #26 to Season #6. Since a recipe would only be in one season, you'd actually just need a single column added to the table. It doesn't get any simpler than that, and would prevent unauthorized access.

Well, until the incompetent webmasters over at America's Test Kitchen catch wind of this blog you may want to scoop up all their recipes. Considering the popularity of my site, I wouldn't worry about hurrying.

Disney is trying something new. During May and June they'll be offering some shows on their website, including Lost and Desperate Housewives. I can guarantee I won't watch the latter, but I might try out Lost. Well, actually I've kinda lost interest, but my wife really loves the show and once in a while misses it. A TiVo (or MythTV preferably) would be much better, of course.

Here's what they have to overcome. Right now you can download HDTV versions on P2P networks, with no commercials. They're not instant, but with enough seeders they're not too slow. These versions apparently are only 700x394 which is a widescreen version of standard TV quality. The tradeoff there is that the bandwidth is low enough to deliver in real time.

But speaking of that, they have to deliver the video without any jitter, and I mean none. One of those infamous "buffering..." messages that RealPlayer was known for, will be killer.

It has to Just Work(tm). They're using a Flash media player, so that should work pretty well I think. I'm sure they'll wrap it in all sorts of DRM, which will almost certainly lead to problems (and DRM is just plain wrong anyway).

They're not going to eliminate the P2P TV show swapping, but I hope they realize that's not supposed to be the goal. It's nice to see that they're finally waking up to the fact that people want media on their terms, not on the networks. Hopefully this leads to the next step which will actually be worth using.

I saw a link on Bruce Schneier's blog about musicians who are opposed to Digital Rights Management (DRM) being applied to their music. I've written about this before, but it was nice to see it in print by a major news outlet.

Some of my favorite quotes: