Consider this an alert from your TidBITS early warning system. Sometime in the next few weeks, we're going to move the TidBITS mailing list from the LISTSERV at Rice University to a Power Mac 7100/80 running ListSTAR/SMTP and FileMaker Pro 3.0 with some glue provided by other tools and applications. As with the Apple Workgroup Server that runs our Web server, mail server, and other Internet services, the new machine will physically live at the offices of our friends at Point of Presence Company and use their T1 line. We're hoping to have the new machine up and running within the next week, and we'll probably send out a short test message at that point. Shortly thereafter we'll distribute the first issue via ListSTAR.
We're eternally grateful to Rice University and Mark Williamson there for hosting our extremely large mailing list for so long. However, all things must pass, and Rice is moving their mailing lists off the IBM mainframe that runs the LISTSERV program so they can shut down that machine. In the process, they're also limiting the lists they run to local lists, which means that TidBITS and Info-Mac must find new homes (Info-Mac doesn't currently have a move plan in place).
We looked at a couple of options, but the problem with the TidBITS list is that it's at about 40,000 people and can grow by up to 1,500 people per month during busy times. Even though we only send one message a week, that's still a significant load. More significant, however, are the administrative tasks of handling subscription commands, bounces, and other errant mail; based on our experiences with the 6,400-person DealBITS list, we believe we'll receive bounced messages from 1 to 2 percent of our subscribers every week. With DealBITS that means 60 to 120 messages bounced each week; with TidBITS it means 400 to 800 bounces. Our hope is that we'll be able to automate much of the bounce handling; we already have some code to do this sort of thing for DealBITS bounces, and we plan to leverage that for TidBITS as well.
Bringing the list home and running it ourselves will certainly be more work, but it also provides an additional level of control and flexibility. For instance, last week's issue was a day late because an SMTP mailer at Rice ran out of resources. All we knew was that the issue hadn't gone out; it wasn't until late in the day on Tuesday that Mark Williamson managed to take a look and let us know that we needed to send the issue again. Being physically closer to the machine should remove some of that uncertainty.
In addition, the FileMaker database back-end that Geoff has written for ListSTAR should enable us to run more lists. We've had requests over the years for a variety of different lists, ranging from a short announcement of the availability of each issue to distribution lists for TidBITS translations issues. I can't promise that we'll have time to set all these up right away, but we've kept those additional lists (HTML in email has been another popular request) in mind while designing the system.
We will of course support the most common LISTSERV commands at the address <email@example.com>, but we plan to rely primarily on the technique we use for DealBITS, with the <firstname.lastname@example.org> and <email@example.com> addresses for subscribing and unsubscribing. We've found that those specialized addresses are far less prone to user error than subscription and unsubscription commands sent to the mailing list manager address. So, subscribing and unsubscribing to TidBITS (which is also what you do to change addresses) will be a matter of sending email to <firstname.lastname@example.org> and <email@example.com>.
Finally, I have a request for all of you. This is not going to be an easy technical task, and although we believe that we've covered our bases, there's no telling what could happen. The TidBITS list will be one of the largest mailing lists handled by ListSTAR, and we're relying on FileMaker and other tools as well. Being technically cynical people, we're sure that something will go wrong at some point. Here's where you come in: We'll know when something has gone wrong, so please don't send us mail asking if an issue's late, or telling us you got two copies of an issue, or anything along those lines. If something has blown up in our faces, we'll be very much aware of it and busy fixing the problem. Trying to answer basic status queries will only slow us down. Thanks for your understanding and patience!