Author: matthew

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.

So much for my plans of hacking; I’ve spent all day so far working on my in-law’s computer. Not only did they have the usual Gator, Comet Cursor, and other spyware/adware programs installed, they also were infected by three different virusses. I F-PROT’d their computer, but I still suspect there’s something amiss there. Eh, well, I didn’t bring any of my software to be able to reinstall.

This seems to be a growing trend; I recently used the Windows XP laptop of a computer-literate (heck, awesome programmer!) friend of mine. I was appalled to find multiple “toolbar” programs installed (spyware deals that change your IE toolbars to gather marketing data), Gator (ugh, I hate that program, the programs that use it should be given the death penalty), and other assorted annoyances. And he thought it was a good, productive PC! This alarming trend towards laziness in personal PC administration appals me as a sysadmin, yet it seems to be the norm. Far more the norm, in fact, than systems that have good pop-up blocking in place, a decent firewall, virus protection, and lack of spyware/adware/malware.

Well, I did my small part. I installed Promoxitron, F-Prot eval version (with a suggestion to buy the full version), and cleaned up a bunch of nastiness on their PC, including manually uninstalling the uninstallable Gator program. They come up with more aliases for that little thing! And then they stick it in your startup folder, registry run keys, and (I’ve heard) win.ini, though I didn’t find it there. Here’s hoping their little Win ME install holds together until they can buy a new PC. I keep trying to convince them to go with GNU/Linux, but I haven’t verified that Personal Ancestral File runs under Wine yet, and there don’t seem to be any free software competitors to PAF3.

This means, though, that I’ve gotten in no Docbook hacking. Dangit.

Next weblog, I hope to try more “linky” posting…

So I’m heading to Idaho to hang out with my in-laws in a few hours. The usual weekend routine is that we pull in some time around 11 PM (it’s 5 hours from home to there), unpack, sit around and talk until 2 AM, and then go to sleep. Well, usually, it’s my wife Christy that stays up and talks till 2 AM; I’m usually sacked out in a sleeping back upstairs in the over-garage family room by 17 minutes after we walk in.

Anyway, that may change a little bit this time. Christy’s planning on driving there, and I plan on hacking Drupal and my Docbook stuff on the trip up if we can. Before we left on our Spring Break vacation last week, we purchased a 75-watt power inverter for our car lighter so that we can use the laptop as long as we like. It was a life-saver on the trip up to Klamath Falls, Oregon, which is a 13-hour drive from our home in Tooele, Utah.

If I can manage to make dialup work while I’m up there (Sisna is a nationwide provider, thank goodness!), I’ll update the site with code and Guide-Goodness. If not, well, I’ll be back Sunday anyway. In case any of you ever need to access a local SISNA phone number while you’re near Idaho Falls or Rexburg, Idaho, here’s the info:

1.208.552-1843

Points to ponder while I’m gone:

• Do I really need a new computer for home-studio recording? My 933MHz does OK, but I can’t enable as many real-time effects as I’d like, and playback skips once I’m running about 12-13 stereo 16-bit, 44.1KHz tracks. A dual-processor rig with a ton of RAM would be nice, but pricey. And am I going to spend time recording or playing games? Or even hacking PHP, which I can do on my ancient Vaio 300MHz laptop?
• I’m spread a bit thin with family duties, job (that it’s tough to get motivated for, knowing they are just planning on closing the place down anyway), and my hobbies (mostly hacking together web stuff and recording music). If I spend my evenings recording music, then dishes & laundry don’t get done and I go arond smelling funny with a sink full of dishes and a not-entirely-happy spouse. If I don’t record or hack, I feel as if I’ve lost a hand and am not using my natural talents to their utmost ability. Maybe I can cut down on recording to twice a week, or otherwise just do two or three chores when I get home, stay up for only an hour to record or hack, then exercise and go to bed.
• Though there’s not enough time in the day, I really need to allocate one hour for exercise every day. I’d planned on finding that time first thing in the morning, but recording, programming, or hacking keeps me up until late in the night. And seeing that it takes me 45 minutes or so to get into the “groove” with a project, only spending an hour a night seems a waste of time as well.

Maybe I’ll just go back to the way I did it when I was growing up: head out to the studio in some out-of-the-way place three times a year for a 3-day weekend of 24-hour recording. You can produce an album in a year that way. Admittedly, the quality will suck because you can’t spend enough time on each track, but at least you’ll get it done.

Here’s hoping.

I realize nobody’s reading this again yet, except for a few lonely search engines casting about for interesting stuff late at night. I’ve spent the last several hours working on my Bugzilla documentation conversion. It’s not as easy as it looks! I’m trying to model it after the way php.net does their annotated docs, but Drupal uses a totally different type of organization than I’m used to dealing with. Drupal assigns each node an “id”, which is really just a number. It makes it so that a particular node never changes its reference (which is really convenient for links sticking around forever-ish), but Bugzilla and other documentation is orgnanized around a heirarchy of pages.

It’s a real bear to figure out, I assure you. It’s looking more and more like I should go ahead and do the reorganization work on the docs first and then put them up as editable nodes. Or else, actually put up the docs in their original, Docbook XML format, and run them through a custom converter which I’d end up writing so that they would format correctly in the Bugzilla tarball as well as on this site.

What fun! I’ll be chewing on this problem much of tomorrow while I drive up to Idaho with my family. I’ll try to enter a blog or two while I’m there.

I’ve just added the Annotations, Title, Trackback, and htmltidy modules. Here’s what they do and why I’m using them:

• Annotations: This module enables pop-up descriptions of text items to be added by users. This is compelling for my vision of the Annotated Bugzilla Guide. In-Place annotations, instead of after-the-article comments, can be a very powerful tool. Comments by themselves are great, too!
• Title: This module allows one to link to other nodes by the title of the node, rather than node number. This can be very useful in migrating the Guide over, because as we go through subsequent revisions, node numbers are guaranteed to change, and it’s proving very painful to convert all the links within the document to this alternative presentation method.
• Trackback: OK, this is purely for the geek factor. It allows me to send Trackback notifications to other blogs, and receive them as well. I just dig the functionality, and initially fell in love with it using Movable Type a few months ago. Now that the HD crashed that held my old Movable Type install, and I’m on Drupal, I missed it.
• htmltidy: Another "geek factor" toy. This one cleans up the HTML and gives warnings to the reader if the HTML is broken. I just like keeping things W3C-compliant wherever possible to keep the display clean. If you’re using IE, you’ve probably already noticed that BARNSON.org in the title bar has a black background due to being a transparent PNG; I’d like to avoid as many cross-browser issues as possible.

Dang, I write a lot of nothing.

After about two months of no updates due to flaky hardware, BARNSON.org is back in action. My first goal is to create an interactive version of The Bugzilla Guide and related documentation so that we can create the new and improved version of the Guide. The changes to the Guide from this forum will be incorporated in the next release of the Guide.

Unfortunately, the online edition is HTML, while the print edition is maintained in DocBook XML. I think it won’t be too big a deal to incorporate comments and annotations into the XML version from the HTML, but we’ll see after this initial trial. What this means for you is that you are welcome to make changes, comments, and annotations to the Guide, but the eventual commital of those changes to the actual Guide will have to wait until we have time to integrate it. Time will tell, I suppose.

Traffic to this site is VERY light at the moment, and I expect it to remain so with the other niche documentation that I maintain.