Month: May 2003

To skip ahead to what I’ve figured out is the best knot on the planet, go to the bottom of this blog entry.

On the bus, we had a discussion of how to properly tie a shoe. I’ve had problems with my shoes coming untied my whole life, and just assumed it would always be that way. Since I was about six I’ve double-knotted them to keep them from coming untied unexpectedly, and that’s worked great for the last twenty-three years.

Richard, my neighbor, noticed the double knot, and commented that the reason they were coming untied was that I was tying them wrong. He said this vital information came to him from a former Math major at the University of Utah, who in turn had claimed that was the most important piece of information he’d learned in college. The way Richard explained it, I was simply crossing the laces backwards in the very first step of making the knot.

Try out this much better explanation of the difference in knots, and how to keep your shoelaces from coming untied at all the worst times. This is definitely one of the most important pieces of information you’ll use in your life if you wear lace-up shoes. However, if you read to the end, you’ll find that properly tying your shoes in a square not is not the best way to keep them from coming untied! The ultimate solution is probably cowboy boots or loafers, but until then, the Freedom Knot link at the bottom of this page comes pretty close to the perfect knot.

Do you think you know all there is to know about lacing up shoes? Then check out the mathematical proof for the most efficient lace-up patterns. Spoiler: Turns out man has already selected the strongest patterns through trial and error.

And in case you really want to build the better bow, try this shoe-tying link.

Update 9 May 2003: Since I wrote this page, I’ve come across several more useful shoe-tying links. Since this seems to be the only page on my blog people come for, here is the link list!

• Zen Elightenment and the Art of Tying Your Shoes. Warning! Pop-ups! My take: I don’t entirely get Zen, but if you’re into it, now there’s a Zen reason for you to appreciate shoe-tying more.
• Shoe-tying poetry and stories. No, I’m not kidding. These are mostly poems and stories to remind you of the steps to tying your shoes.
• Understanding Robotic difficulty tying shoes. Yep, it’s hard for robots, too, and this page will help you understand why.
• The Freedom Knot. Now THIS is the best shoe-tying knot I’ve ever found. Period. This knot does not come undone!. No lie, no joke. This is a 7-step, amazing knot. Click the little feet images to get the step-by-step procedure. It looks confusing at first, and it’s really hard to do if your laces are too short, but man it rocks. This beats the "Build a Better Bow" knot because it is easier to do, particularly for small fingers, and it’s easy to remember which lace to pull — you just pull them both!

Unfortunately, I don’t have any links yet for one-armed shoe-tyers. I’m still looking for the perfect one-handed shoe bow. If you have suggestions, mail me at matthew at barnson dot org.

EDIT by matthew: Since the day I posted this on May 5, 2003, I finally received several links to one-handed shoe-tying information. The best one I’ve found is Jenny Stemack’s Guide to One-Armed Shoe-Tying (scroll to the bottom; she includes directions both for one-handed and one-armed shoe-tying). It’s really quite excellent, and based on the number of requests I’ve received via this site for one-armed shoe-tying information, will probably be helpful for those of us who find ourselves temporarily or permanently one-handed.

Well, after a good deal of toil and head-banging, I finally got the php “gallery” package up and running. This provides some pretty cool image viewing functionality that I really like. Unfortunately, there appear to be a few problems running Gallery in “embedded” mode like we’re doing.

• Non-authenticated users cannot add comments to pictures
• Sometimes the photo album stuff works weirdly on some browsers. Think that’s a problem between Gallery and the browsers, though.
• Navigation links sometimes take user out of Drupal framework. Grr.
• Can’t use the “Goofy” theme with it. This really bugs me, because I really liked that theme! But it prints out strange “\n” characters and form elements all over the screen when you use it — ugh.

That’s about it. Hopefully it’s convenient for family and friends coming to visit. If you’re a registered user (register using the link below the Log In link on the right-hand side), know me personally, and want some gallery space, then just email me (matthew at barnson dot org) and I will happily create an area for you to post your photos or drawings, too!

Peace, out, look like my Redhat 8 machine is almost finished an apt-get dist-upgrade to Redhat 9 here at work, so I can go home! Woo! It was a slight pain; I’ll talk about it more in my next weblog I think. However, apt-get has made it possible to easily upgrade my computer from one version of an operating system to the next without losing all my settings and files; this is a HUGE win in my book.

From my referrer logs, apparently my old articles on shoe-tying and other inanities were actually a bit of a hit on Google. Anyway, I was able to recover the archives from the crashed hard drive on the old site, and will be posting what I can. I only had a dozen articles or so, but I have had a LOT of people hitting the shoe-tying page! Go figure.

EDIT: This blog entry is quite old, in the world of Postfix. It’s easy to find RPMs for 2.0 experimental releases now, and the word “experimental” (as of August 2003) is starting to sound a little funny for what is becoming the mainstream release people are using day-to-day. If something doesn’t work for you, I suggest you hit the Postfix home page and see if you can figure out what’s up from the mailing list archives.

---

Yesterday evening (Saturday night. There are a whole lot more fun things to do on a Saturday night than this!) I upgraded the Postfix install on my firewall at work. The primary purpose of my upgrade was to enable “Sender Address Verification”. This stuff is pretty cool. Although the sample-smtpd.cf has wonderful examples of how to use this, I found other information on the ‘net totally lacking.

Now, some important information before you get excited about Sender Address Verification:

My environment

1. postfix-2.0.9-20030424. This is a "pre-release" or "experimenal" version of Postfix. That means you’re not going to currently get this functionality using some pre-packaged binary rpm or something.
2. db2/3/4-devel. This build of Postfix requires db2,3, or 4. So if you don’t have it installed, you’re not going to be able to build and install Postfix.
3. pcre.  This is the "Perl Compatible Regular Expressions" library.  They tell you which version of pcre is the minimum for building Postfix on the postfix download page.  I would have a lot of trouble handling all the strange addresses I use without the pcre package; quickly, pcre is becoming a requirement for using Postfix. Postfix has some standard regular expression functionality by itself, and I think that you can build it without pcre, but I didn’t try.
4. gcc and other building tools. If you’ve never compiled anything before, you’re probably out of your depth at this point.
5. A TEST SYSTEM. Yes, please, try this out on a test system before you get down and dirty with your production firewall. I did the install on two test systems two days before rolling it out on a production server, to make sure it works.

The basic process itself is pretty darn easy. After downloading postfix-2.0.9-20030424 (or whatever the current experimental release is), rather than the usual "./configure; make; make install" three-step you’ll find on most packages, Postfix follows its own standard.

The Upgrading Postfix Four-step

1. tar xzvf postfix-2.0.9-20030424.tar.gz
2. cd postfix-2.0.9-20030424
3. make
4. sudo make upgrade

Note that I use, and heartily recommend that everybody else does, too, "sudo" for all my root-privilege stuff. If you’re doing all the above as root, leave off the word "sudo" from the last step.

It’s unfortunate there’s no RPM for the experimental releases, but Postfix is pretty good about figuring out how your previous version is installed (by looking at your old .cf files) and putting its stuff there. One thing the "make upgrade" doesn’t do is copy over all the sample-foo.cf files. I heartily recommend figuring out where those sample files live on your system. On my FreeBSD test system, they live in /usr/local/etc/postfix/. On the RedHat 8 firewall, they live in /usr/share/doc/postfix-1.1.11/samples/.

On the FreeBSD test system, the install was flawless. Postfix worked exactly the same after "make upgrade" as it did before. Of course, that system runs barnson.org and is a slightly less complex install than the Red Hat 8 firewall at work. On my OpenBSD firewall at home, the results were similarly flawless.

However, when I reached my RedHat 8 install on the firewall, I immediately noticed some errors.

Problems with Postfix’s "make upgrade" on a complex Red Hat 8 firewall

• Postfix has no idea if you are running one instance of postfix, or more than one. We have two copies running at all times for historical reasons: one whos configuration files live in /etc/postfix, and the other lives in /etc/postfix-out. The postfix-out main.cf and master.cf were not updated with the change. I heartily recommend that you redirect output (stdout, put “>somefile.txt” at the end of the make upgrade line) from make upgrade to a file so that you can see what changes it has made (it’s quite verbose) and make the same changes to your secondary install.
• Postfix has changed the way it handles real-time blackhole lists. Instead of defining a "maps_rbl_domains" parameter and then calling "reject_maps_rbl" from within smtpd_recipient_restrictions, you define the rbls within smtpd_recipient_restrictions (or wherever you use them) itself. This, I think, can provide a great deal of flexibility with which real-time blackhole lists you use at different parts of your config file.

The reason we were running two Postfix instances on one box was because we were running Spam Assassin on mail, and didn’t want mail leaving our network with spamassassin headers attached. We’ve since reduced that to just Anomy, and rely on Bayesian filters for those that want them within the firewall. It works better, and the firewall isn’t pegged at 100% CPU usage 70% of the time anymore. So I turned off the secondary instance in my /etc/init.d/postfix script, and also added the localhost and internal interfaces to postfix’s main.cf. I’ll still have to see how that works.

OK, so you’ve read all this way, and you’re probably wondering about all this Sender Address Verification stuff. It’s really quite simple. In your "smtpd_recipient_restrictions" section, just add this one line:

reject_unverified_sender,

somewhere before your "permit" at the end of the section. Reload postfix, and try this sample mail session. Any line that begins with a number is a response from the remote server. Any line that begins with an all-caps command is what you type. Start by telnetting to port 25 on the remote mail server.

[matthew@localhost matthew]$ telnet some.internet.host 25 Trying 123.45.67.89... Connected to some.internet.host. Escape character is '^]'. 220 220 some.internet.host ESMTP Postfix HELO barnson.org 250 bubba.aib.com MAIL FROM: 

250 Ok RCPT TO:  550 : Sender address rejected: undeliverable address: host mail.barnson.org[209.237.255.54] said: 550 : User unknown in local recipient table (in reply to RCPT TO command) RSET 250 Ok QUIT 221 Bye Connection closed by foreign host.

In the following list, I use the terms “client”, “server”, and “verification host”. The client is the machine attempting to send mail to your Postfix server. The server is your Postfix server. The Verification Host is the first available MX (Mail exchanger) host based on the MAIL FROM: sent by the client. The basic process that just happened was this:

How Sender Address Validation works:

1. Client sends HELO, MAIL FROM, and RCPT TO commands.
2. On RCPT TO, Postfix server makes a connection to the MX host(s) for the domain listed in MAIL FROM by the client.
3. If Postfix is able to connect to that MX (if you’re talking about spammers, that’s always a dubious possibility at best), it then sends its own MAIL FROM: declaring that it is postmaster@some.internet.host, and puts a RCPT TO: of the MAIL FROM: address of the client attempting to mail to itself.
4. If the server responds with anything but an OK, Postfix sends a RSET and QUIT to the verification host, and then sends a rejection to the client saying "undeliverable address" and the response from the verification host.
5. If the verification host replies with OK, Postfix sends a RSET and QUIT and then sends an OK to the client. Alternatively, if you have additional rules after reject_unverified_sender, you can configure Postfix to default to DUNNO (meaning "passed this rule, but go on to the next") rather than sending an OK or a REJECT.

So far, reject_unverified_sender is really mostly catching the "corner cases" for me, rather than the majority of spam. However, it has almost eliminated a class of messages that occasionally kill our mail server: dictionary attacks. Often a spammer will send thousands of messages to random addresses in our domain in hopes that someone will read their pitch. Well, our Postfix gateway is configured to blindly relay any address in our domain on back to our Groupwise server behind the firewall. Yeah, I know, it’s not the best thing in the world, but at the moment it’s easier to do that than to enter several thousand email addresses by hand into the "virtual" table for Postfix. Nasty getting those out of Groupwise. Anyway, if a spammer dictionary-attacks us using an invalid return address, when Groupwise bounces the message, those bounces bounce because the return address won’t work. Basically, we’re just checking to see that there’s a real, live email address listed in the return. This prevents those thousands of “double bounces” from ever getting onto our network in the first place, and ending up in my inbox as postmaster of the domain. And that’s really what this is all about: lowering my frustration level with double-bounces.

We’re in the process of moving our organization from an ancient install of Groupwise 5.0 to Cyrus Mail. Yeah, we’re going to lose a little functionality here and there, but my hope is that it’s totally work-around-able for our users. Once that migration is complete, we can actually easily streamline this process by using reject_unverified_recipient, which makes a connection to the ultimate destination SMTP server, validates that a mail address exists and is deliverable, and does pretty much the same thing otherwise. This would still provide us with protection for our internal mail server by using an inbound mail gateway, yet dramatically reduce our double-bounces. Alternatively, we can just maintain a list of users in two places (one on the firewall), but I’m leery of storing any non-essential user names on a firewall, you know?

Eventually, I think the spammers will get wise to thise protection and begin always using valid email addresses as the return address of their promotions. Unfortunately, I think it’s most likely that they will use known-good mailing addresses as the forged source of their unsolicited commercial email. However, this will catch those who are slow to catch on, and at least force fraud to be more quickly exposed. If I were your average mail administrator, I’d certainly want to keep an eye on RCPT TO: requests to my mail server, and if I see too many to a certain individual, temporarily disable their mail account until the attack is over.

OK, now the last thing. I’d planned on getting this implemented by the time I wrote this article, but I just haven’t had the time yet. The final phase in my plan for anti-spam is to create a temporary rejection table called “five-fifties”. This Postfix table would store the IP addresses of clients who do not honor 55x rejection error codes and make multiple mail delivery attempts after receiving a 550/554/whatever. I realize that it’s not really going to be much of a help defending against spam (since I’m already rejecting them with a 55x anyway), but it would be a big help in tracking connection attempts from abusive IP addresses and setting up another daemon to automatically add repeat offenders to an iptables blacklist. Looks like you’ll have to wait for another article to read more about that though, after I have implemented it!

Hope this helps!

***NOTE: Please be aware that I’m still getting used to my chosen blogging software, Drupal, at this point. So there may be strange typographical issues here and there. Please let me know via comment if you see something that needs fixing.***

I’m going to be checking out Drupal CVS over the next few days. I’m really anti-excited about the whole “being online to blog” thing. Yeah, I know, I can vi a file or something and paste it, but I’d really prefer to be able to use mozblog or something so that I don’t have to be online, and that I can really tweak the heck out of links in my post before putting it up there. Wish me luck.