Find Which Applications Phone Home with VirusBarrier X6
Worried about rogue applications or spyware "phoning home" with your private data? Turn on VirusBarrier's Anti-Spyware feature, and it will alert you to applications that attempt to connect to remote servers. Once you know which apps are phoning home, you can block or allow each individually, and you can even block or allow specific ports for each application, to ensure that your private data stays private.
Network administrators take note! Matt Deatherage looks at Mac OS X Server's new NetBoot feature for booting iMacs and recent Power Mac G3s via Ethernet. Also this week, Adam examines Fog City's excellent LetterRip Pro mailing list management program in depth. In the news, Apple releases MRJ 2.1.1 and StarNine announces WebSTAR Server Suite 4.0, which adds a mail capabilities and significant performance improvements to the popular server software.
by Geoff Duncan
StarNine Announces WebSTAR Server Suite 4.0 -- StarNine Technologies has announced WebSTAR Server Suite 4.0, the next version of its WebSTAR Internet server packageShow full article
StarNine Announces WebSTAR Server Suite 4.0 -- StarNine Technologies has announced WebSTAR Server Suite 4.0, the next version of its WebSTAR Internet server package. WebSTAR Server Suite 4.0 will include a new integrated email server (supporting SMTP, POP, and IMAP) and the capability to publish FileMaker and ODBC databases to the Web, in addition to WebSTAR's core suite of Web, FTP, and proxy servers. WebSTAR's database publishing capabilities are based on Blue World Communications' forthcoming Lasso Web Publisher 3.5, a subset of the full Lasso 3.5 Web Data Engine that enables turn-key publishing of database-driven Web resources. WebSTAR Server Suite 4.0 also integrates SSL encryption for sites conducting net commerce, supporting more certificate formats and encryption technologies (including Server Gated Cryptography). In addition, a redesigned intelligent caching system and other low-level enhancements should offer substantial performance improvements - according to StarNine, overall performance should be double that of current versions of WebSTAR, with data transfer rates as much as five times faster. WebSTAR Server Suite 4.0 should be available this June; pricing details haven't been finalized. [GD]
by Geoff Duncan
MRJ 2.1.1 Available -- Apple Computer has released version 2.1.1 of Macintosh Runtime for Java, a quick followup to last. month's MRJ 2.1. (See "MRJ 2.1 Runs Faster, Works with Explorer" in TidBITS-467.) MRJ 2.1.1 complies with Sun's Java 1.1.7 specification, offers better support for loading applets through proxy servers or firewalls, supports installation on localized versions of the Mac OS, and works with Java applications available from Yahoo GamesShow full article
MRJ 2.1.1 Available -- Apple Computer has released version 2.1.1 of Macintosh Runtime for Java, a quick followup to last. month's MRJ 2.1. (See "MRJ 2.1 Runs Faster, Works with Explorer" in TidBITS-467.) MRJ 2.1.1 complies with Sun's Java 1.1.7 specification, offers better support for loading applets through proxy servers or firewalls, supports installation on localized versions of the Mac OS, and works with Java applications available from Yahoo Games. MRJ 2.1.1 requires a PowerPC-based Mac with at least 32 MB of RAM and Mac OS 7.6.1 or later. QuickTime 3.0 is also helpful. MRJ 2.1.1 is a 7.8 MB download in MacBinary format. [GD]
Perhaps the most interesting part of Apple's just-released Mac OS X Server is NetBoot, which enables newer Macintosh clients to boot the Mac OS over an Ethernet network from a server machineShow full article
Perhaps the most interesting part of Apple's just-released Mac OS X Server is NetBoot, which enables newer Macintosh clients to boot the Mac OS over an Ethernet network from a server machine. Demonstrated at January's Macworld Expo, NetBoot simplifies the lives of system administrators by effectively turning a disk image file on the server machine into the startup disk for any reasonable number of Mac OS clients on an Ethernet network.
Inside the Image Machine -- With the release of Mac OS X Server, we know a bit more about how NetBoot actually works. The server holds two standard Mac OS disk image files - one with the system software, and one with applications available to NetBoot clients. When someone boots a Macintosh with the "New World" ROM-in-RAM architecture - currently only iMacs and blue and white Power Macintosh G3s - pressing the N key during startup forces the machine's Open Firmware to look on the local Ethernet network for a NetBoot server, using the industry-standard BootP protocol. The server responds by returning an IP address from a pre-assigned range (each IP address is matched to the requesting computer's hardware Ethernet address so the server can assign the same IP address to the same workstation each time). A separate part of BootP handles a request to boot from the server; that half of the protocol uses Trivial File Transfer Protocol (TFTP) to download the "Mac OS ROM" image file to the client machine, where booting can proceed somewhat normally. FTP is uses TCP/IP, a complex protocol for a computer that's not yet booted. TFTP is a simpler version that runs on UDP (User Datagram Protocol), a lower-level communication method than TCP.
Once the ROM file is on the client systems, they can initialize a IP stack from within the ROM image and log into the server, using AFP server information returned by BootP plus a username and password provided by you. Mac OS X Server responds with three disk images that look like two separate volumes - the applications disk (as mentioned); a read-only system startup disk containing a lightly modified Mac OS 8.5.1; and a shadow disk image of the same size. A major obstacle faced by NetBoot is that boatloads of Mac OS applications assume they can write to the startup disk. On a NetBooted machine, they can - but the changes are redirected to this shadow disk image. The real startup disk image is shared among all clients and doesn't change, but programs on each client machine can write to the disk with the changes being stored privately in a separate shadow file for each client.
For example, suppose you're using a NetBooted machine and you install a font you downloaded from the Internet. That involves writing to the Fonts folder inside the System Folder. The Finder allows it, and your font appears to be in the folder and is available to applications after that point. But behind the scenes, Mac OS X Server is showing your Mac client a "merged" disk with your changes layered on top of the real, unchanged, startup disk. It works because no client can change the startup disk. If the original disk image changed behind the shadow file's back, so to speak, the differences would be applied to data that wasn't where it should be, creating a huge mess.
When each NetBoot client restarts or shuts down, the shadow startup disk image file is discarded, so folks using lab machines can temporarily modify the startup disk any way they choose, because the changes only affect that particular Mac OS session. The Macintosh Manager, a software program illogically not named after Don Crabb, is the descendant of At Ease for Workgroups and provides client-level customizations like desktop patterns and Finder preferences for clients. The Macintosh Manager kicks in at the authentication level - once the server knows who is trying to boot, it knows what preferences you have set, so your customized desktop follows you from machine to machine. Each user has a folder on the AFP server for private files and preferences; the Mac OS that boots from the network maps the built-in location for the Preferences folder to this folder on the server instead of the standard location in the System Folder. As long as applications ask the Mac OS where the Preferences folder is instead of assuming its location, everything magically works, and each user's preferences are available from any client machine starting up from the same NetBoot server.
Easily Configured Piracy -- The startup and application disk images can be changed only by the Administrator (an alias for "root," to Unix partisans), presumably only when no other clients are logged in. That's how NetBoot delivers on its promise of centralized management - updates to either disk image automatically appear on all NetBoot clients during the next startup. Install an application once and all clients can access it. Similarly, changes to system configuration apply to all clients at once - alter the startup disk image to include the StuffIt Engine, and all clients have access to it. You can even prevent users from mucking up the internal hard disk on client machines by installing an included extension that unmounts the internal hard drive during startup, leaving it unavailable to the user.
NetBoot can raise licensing issues, though - if you boot 20 Mac OS clients with a commercial extension like Default Folder 3.0, you need twenty licenses for it. You may need to use a license management program like Sassafras Software's KeyServer to help manage licenses; KeyServer modifies applications to check in with a central server before launching, and only allows as many concurrent clients as you have licenses. Thus, a lab of thirty iMacs could all see Photoshop 5.0 on the Applications disk image, but if you've used KeyServer to permit only five clients, a sixth Photoshop user must wait until someone else quits Photoshop. The Mac OS X Server package includes a demo version of KeyServer.
No Miracle Cure -- NetBoot is not without significant limits. First, think about how often your Macintosh hits the startup disk during the normal boot process. Now imagine that over a slow network connection. Apple says NetBoot is intended only for use on 100Base-T networks, where transfers can meet or beat normal SCSI speed. It uses the BootP protocol, and BootP is designed to run on a single network segment, so you can't easily use NetBoot to start clients that are separated from the server by a router (some routers allow BootP extensions that bridge network segments, but that would likely impact performance). Mac OS X Server has robust networking, so adding more Ethernet cards can improve bandwidth for a range of BootP clients, but you need heaps of RAM to support lots of clients adequately. Apple recommends at least 128 MB of RAM for heavily loaded servers, and more than 200 MB if you want to run services like Apache or WebObjects in addition to NetBoot. Apple says that a Mac OS X Server machine running just the NetBoot service (not the Web or file servers) can accommodate about 50 clients; adding other services reduces that capacity.
Second, think about disk space requirements. If your startup disk image file occupies 50 MB, then you must have enough disk space for each concurrently booted client to have its own shadow copy of that file. A thirty-machine lab thus requires 1.5 GB of disk space (50 MB times 30 clients) for shadow files, in addition to space for the Mac OS X Server software, space for users' private folders, an applications volume, and other files. One recommendation from Apple advises at least 5 GB of storage space on the server machine.
Lastly, NetBoot requires support in Open Firmware for the BootP protocol. Machines older than the iMac don't have it. Open Firmware is burned into a ROM chip on older machines and can't realistically be patched to add such major new functionality. So, only iMacs and blue and white Power Macintosh G3 computers can be NetBoot clients. The Macintosh Manager program will be available for older Mac OS clients as a replacement for At Ease for Workgroups, but they'll still boot only from local hard drives, and you'll still have to configure them the same ways you do now.
Nothing like NetBoot was previously available for the Macintosh, so there's no "should I upgrade" decision. Instead, the questions for lab administrators are:
Do I have a lab of machines capable of networked booting?
Can my server handle the NetBoot clients on a single Ethernet segment per Ethernet port?
Do I want the easier configuration and trickier licensing entailed by sharing a single startup and applications volume?
In future technology purchases, I believe administrators will love NetBoot. Those with labs of older machines won't find it useful, but every time an institution or company installs a group of several iMac machines with a Mac OS X Server for any reason, NetBoot solves a ton of configuration problems. There will almost certainly be some compatibility issues at first, as there were when Apple II machines first acquired network booting capability in 1987 with a far simpler operating system. But in the long run, NetBoot will be worth the bumps, especially in educational settings.
[Matt Deatherage is the publisher of MWJ, an acclaimed subscription-only newsletter featuring in-depth information for serious Macintosh users. A free three-week trial subscription is available at the MWJ Web site.]
Sometimes a program wiggles into our lives in such a subtle way that it takes months before we realize we're dependent on it. We say "we're just testing it," and may even believe we could switch to something differentShow full article
Sometimes a program wiggles into our lives in such a subtle way that it takes months before we realize we're dependent on it. We say "we're just testing it," and may even believe we could switch to something different. For us, Fog City Software's LetterRip Pro mailing list management software has been one of those programs.
Since 1996, we've used ListSTAR from StarNine Technologies for the main TidBITS mailing list and a few low-volume lists. We liked ListSTAR, and since the Mac we run it on lives at Popco with shared a T1 connection, everything went swimmingly.
Then LetterRip Pro appeared. Moving a 50,000-person mailing list isn't trivial - especially since we manage it securely in a FileMaker Pro database. (See "Not Your Grampa's Mailing List" in TidBITS-420). So we thought we'd instead install LetterRip Pro on our elderly SE/30 and give it a few low-volume lists as a test. Since then, we've worked our way up to TidBITS Talk, which delivers about 20 messages daily to 1,300 subscribers. TidBITS Talk can flood our Internet connection, but LetterRip still hasn't blinked. The SE/30 now runs about 25 mailing lists that serve several thousand people. Why? Because we're confident that both software and hardware can handle the load, and because it's so easy to set up a list.
Parts & Pieces -- LetterRip Pro has two main parts: LetterRip Pro Server and LetterRip Pro Administrator. LetterRip Pro Server accepts incoming messages, processes them, and sends them back out. LetterRip Pro Administrator enables you to configure and work with mailing lists, either on the same machine as LetterRip Pro Server or remotely via the Internet. Each program requires 2.5 MB of RAM, and in general, LetterRip Pro at a minimum needs Open Transport 1.1, System 7.1 (Mac OS 8.0 or later recommended), a 68030 processor, and at least 10 MB of free disk space.
LetterRip Pro can use either full-time or part-time Internet connections. Full-time connections work best, since they allow LetterRip to receive messages via SMTP like a dedicated mail server. Relying on part-time dialup connections forces LetterRip to receive messages via POP, like an email client. The SMTP mode offers higher performance and is less trouble, but POP mode lets you run another SMTP server on the same Mac.
The final ingredients of LetterRip Pro are "processors," small programs (mainly written in AppleScript) that extend LetterRip's functionality. For instance, the Email Admin processor enables LetterRip to accept email messages containing batches of addresses to add and remove. LetterRip Pro ships with processors that confirm subscriptions, archive messages, and return subscriber lists. Users have contributed other processors.
Setup -- Starting out with LetterRip Pro is simple. The installer places all the files in the correct locations, after which you launch LetterRip Pro Server and then LetterRip Pro Administrator. In LetterRip Pro Administrator, you fill in a two-tabbed Server Settings dialog box with essential information such as server domain, requests account (a central account that accepts commands sent to LetterRip), administrator address, and password. The mail transfer defaults should be fine, but you can choose between sending outgoing messages directly (best for reducing bounces) or through another mail server.
LetterRip supports the -on and -off addresses for subscribing and unsubscribing that TidBITS has helped popularize, although it also creates a "requests" address to which users can send subscribe and unsubscribe commands. You can't use -on or -off addresses in POP mode.
Before continuing, I need to clarify some terminology. LetterRip's interface includes Mail Lists and Address Lists. A Mail List is the configuration for a given mailing list, whereas an Address List is the list of subscribers who receive messages sent to that mailing list. It can be confusing at first, but you pick up the terms quickly.
Mail Lists -- Once your server settings are correct, you create a mailing list by choosing Mail Lists from the Setup menu, then clicking the Add button to open the Mail List dialog box, which includes tabs for:
Basics: Here you set the list name and account, plus associate the mailing list with an address list. You can also restrict subscribing and unsubscribing.
Digest: LetterRip Pro can automatically generate digests; in this tab you set digest options such as the address list for digest subscribers, frequency, schedule, size, type (MIME or normal), and a variety of naming options.
Incoming: The Incoming tab lets you choose who can send messages to a list and what types of messages should be excluded from a list.
Outgoing: LetterRip lets you modify outgoing messages in one of three ways. You can insert a message banner at the top of messages, append a message footer, or prefix subject lines.
Responses: One of the hardest parts of setting up mailing lists is writing the generic text people receive when they subscribe, switch to digest mode, or unsubscribe. LetterRip Pro provides default responses, and you can customize each response or edit the default responses. Mail merge-like variables let the responses be list-specific.
Moderation: Most mailing lists accept messages from anyone, but with a moderated list, a moderator chooses which messages to redirect to the list. In the Moderation tab, you toggle list moderation and set who should receive incoming messages.
Headers: Here you find checkboxes for "Insert List Headers" and "Include Reply To Header." LetterRip's idea of list headers doesn't currently support many of those mentioned in "Explaining All Those List Headers" in TidBITS-472, but I anticipate seeing support for them soon. You can add custom headers manually. Whether you should include the Reply To header depends on the list. If you want to encourage discussion on the list, include it so replies go to the list by default; otherwise, leave it off so replies go to the original senders by default.
Admin: The Admin tab lets you specify a list administrator other than the person set in the Server Settings. This is useful if you're setting up a list for someone else and want them to receive the administration messages and bounces.
Address Lists -- You can create address lists while setting up a mail list, or you can create them manually in the Address Lists window. An address list window has two columns, one for email address and one for name (which isn't required). You can add, delete, and edit addresses here, or sort the lists by address, name, or subscribe order by clicking the column headers or via the Addresses menu. You can drag text containing email addresses (in a variety of formats) into an address list window to add an address, and you can drag addresses from one address list window to another.
The Addresses menu also includes a Remove Duplicates command (great when merging lists), plus Import and Export commands for transferring lists to and from other programs. A simple Find command in the Edit menu finds text in either an address or a name. Although you can select multiple addresses and delete them, it would be nice to have LetterRip find and select all addresses that match the search string.
LetterRip Pro's address lists are unfortunately little more than text files. In my mind, an address list should be a relational database that stores subscriber information. Failing that, I'd like to see tight integration with a database like FileMaker Pro. That's what we do with our main TidBITS list and duplicating that functionality with LetterRip wouldn't be easy.
Bounces -- The main place LetterRip Pro falls down is in bounce handling. Fog City chose to create "bounce digests" that list bounces LetterRip receives (minus most temporary failures). It may be better to receive a single bounce digest than 15 individual bounces, but simply cataloging bounces for manual processing is a mediocre and time-consuming solution to a serious problem.
Many mailing lists ignore bounces, which makes their lists seem larger while wasting bandwidth. We don't approve of ignoring bounces, so on our lists, if you bounce for a certain amount of time, you're off.
If LetterRip added database functionality underneath address lists, it would be easier to automate bounce processing and turn off bad addresses after a certain number of bounces. Even eliminating most bounces from well-behaved mail servers would be a step in the right direction. Unfortunately, some mail servers - BBS systems, Microsoft Exchange, and cc:Mail in particular - can generate inexplicable bounce messages; those would still require human attention.
Documentation & Support -- Since Fog City sells LetterRip Pro only electronically, its documentation is electronic and comes in multiple formats, including a stand-alone application (which lacks a Find feature) and PDF (which lacks bookmarks). I've found the documentation good but not great. It provides the basic information you need, but seldom progresses to information you don't know you need. An online FAQ also answers some common questions.
Not surprisingly, Fog City handles LetterRip support primarily via email. The folks at Fog City have been responsive and knowledgeable and are great at filling in gaps in the documentation. Other LetterRip users also provide useful information on the LetterRip-Talk mailing list, which Fog City monitors. I especially appreciate that the Fog City folks are straightforward when responding to requests on the list, explaining, for instance, why they feel it may not make sense to implement an unusual feature.
Quibbles -- There's much to like in LetterRip Pro, but aside from the major architectural change of a database beneath address lists and better bounce handling, I've found a few other annoyances.
Deleting an address list or mail list must be done via the Finder on the machine running LetterRip Pro Server. Plus, you must shut down LetterRip Pro Server first. Although this process is straightforward, it entails extra work on a machine you may not be able to access easily.
When you run LetterRip Pro Administrator, it automatically opens the Log Window, which displays current activity. However, although LetterRip Pro Administrator remembers window positions for the Address Lists and Mail Lists windows, it won't automatically open them. Since I run LetterRip Pro Administrator only to use those windows, it's annoying to open them manually each time.
LetterRip Pro automatically identifies bounces, but it can also prevent other messages from being posted. To accomplish this, it reads the contents of a text file called "Mailer Daemon Strings," which contains lines specifying text in the From, Precedence, or Subject headers, or in the body of the message. If a message contains that text, LetterRip won't process the message. I'd like to see an interface within LetterRip for modifying this information - editing a text file on a remote computer is often tricky.
Let's say you wanted to have a master list made up of the members of several address lists. In LetterRip Pro, you'd have to create and maintain that master list separately from its constituent lists, since a mail list only connects to a single address list. For instance, I have mailing lists for each TidBITS translation team, and I'd like to be able to have a single list that would send mail to everyone on each team. The only way to accomplish that in LetterRip is problematic. You can create the master list, along with an address list that contains the addresses for each translation list. But you must also remove the Precedence: Bulk header line from the Mailer Daemon Strings file, since that line prevents LetterRip from distributing a message from a mailing list to another mailing list (which helps avoid mail loops). Ideally, you should be able to associate a single mail list with multiple address lists.
Overall -- These quibbles aside, Fog City has done an incredible job with LetterRip Pro. You could even argue LetterRip Pro is so easy to use because Fog City has resisted some of the enhancements I've suggested. They're focused on keeping LetterRip Pro simple and fast, and adding flexibility often complicates an interface.
LetterRip Pro isn't cheap at $400 directly from Fog City, although Fog City has occasionally offered special deals for significantly less. Obviously, it's hard to recommend a $400 program for casual use, especially when there are freeware programs like AutoShare and Macjordomo that perform the same basic tasks as LetterRip Pro. Perhaps Fog City will someday create a less-capable and less-expensive version. Owners of ListSTAR can take advantage of a competitive upgrade offer, and you can download LetterRip Pro and try it for 30 days without a registration number.
If you're serious about your mailing lists, but you still want a simple solution that offers high performance, you won't go wrong with LetterRip Pro. Personally, I can't imagine running mailing lists without LetterRip Pro any more.