Previous Issue | Search TidBITS | TidBITS Home Page | Next Issue
After writing several articles about data security and the importance of a good backup system, Adam and Tonya find themselves putting that information to the test after thieves break into their house and abscond with a PowerBook. Also in this issue, Geoff explains in detail how to respond to spam, WebSTAR 3.0.1 ships, Qualcomm sells Now Utilities to Power On Software, Connectix updates RAM Doubler 8, and we announce a Chinese TidBITS mailing list.
Copyright 1998 TidBITS Electronic Publishing. All rights reserved.
Information: <email@example.com> Comments: <firstname.lastname@example.org>
This issue of TidBITS sponsored in part by:
Northwest Nexus -- 1 888-NWNEXUS -- <http://www.nwnexus.com/>
Internet business solutions throughout the Pacific Northwest.
Small Dog Electronics -- Special Deal for TidBITS Readers!
MS Office 98 & 4.2.1, Grolier's, Blockbuster, and Dogs: $299!
UMAX Astra 610s (refurb) flatbed scanner (Mac/PC software): $79
For Details: <http://www.smalldog.com/> -- 802/496-7171
Cyberian Outpost -- the Cool Place to Shop for Computer Stuff!
Kensington security products to safeguard all your hardware!
Order online or call 860/927-2050 x228
TERRY MORSE MYRMIDON
Turns any Mac file into a Web page with one click!
QuarkXPress, PageMaker, FreeHand, FileMaker Pro -- anything.
FREE DEMO --> <http://www.terrymorse.com/> <-- FREE DEMO
Eudora Pro Security Hole for Windows Only -- After last week's CIAC advisory regarding possible security problems in primarily Windows email clients, a different security issue has been revealed in Windows versions of Eudora Pro. Eudora Pro 4.0, 4.01, and 4.1 betas for Windows can utilize Microsoft's HTML viewer when displaying messages, and that viewer can permit automatic execution of items included in the message, such as Java applets. In theory, other Windows applications that use Microsoft's HTML viewer could also be vulnerable. Qualcomm has released an updater to 4.0.2 that makes Eudora Pro ask for permission before executing programs automatically. As a workaround, disable Microsoft's HTML viewer in the Viewing Mail settings panel of Eudora's Options dialog box. Eudora Light is not vulnerable, and Macintosh versions of Eudora have been safe for years because they encapsulate any attached applications so users must specifically choose to execute them. However, the bottom line remains unchanged: don't launch any attachments unless you're sure they're safe. [GD]
Chinese Mailing List Available -- Thanks to renewed efforts on the part of our Chinese translation team, a separate mailing list is now available for people who want to receive TidBITS via email in Chinese, using the Big-5 character encoding standard. To subscribe, send email to <email@example.com>, and please tell friends who might like reading TidBITS in Chinese. (Chinese versions of TidBITS are also available via the Web.) As always, our thanks to the Chinese translation team along with all the polyglot folks who translate TidBITS into other languages for their outstanding work and for making TidBITS available to a much wider audience. [ACE]
WebSTAR 3.0.1 Update Ships -- StarNine Technologies last week released WebSTAR 3.0.1, a free update to the company's popular $499 Web server. Along with bug fixes, enhancements include improved compatibility with FTP clients, enhanced HTTP support, and better site indexing and searching capabilities. The download is a beefy 15.3 MB. [ACE]
Now Utilities Powers On -- Qualcomm announced that it is selling Now Utilities to Power On Software, creators of ACTION Files. Like Now Super Boomerang, Action FILES enhances file access within Open and Save dialog boxes (see "Get a Piece of the ACTION Files" in TidBITS-434). Power On will continue to sell and provide support for Now Utilities, and it's likely that components of Now Utilities will be rolled into Power On's upcoming ACTION Utilities. Owners of Now Super Boomerang, which hasn't been updated to work under Mac OS 8, will be directed to ACTION Files. Terms of the purchase were not disclosed. [JLC]
RAM Doubler 8 Upgrade Adds Speed, Stability -- Connectix Corporation released a free upgrade to its memory optimization tool RAM Doubler last week, tweaking the utility's speed and offering greater stability. This release follows on the heels of the RAM Doubler 8 upgrade, free to registered users of RAM Doubler 2.x (see "Free RAM Doubler 8 Update" in TidBITS-439). Version 8.0.1 resolves problems using the RAM Doubler control panel with older versions of the Finder in low-memory situations, speeds up application launches on PowerPC-based Macs with large amounts of memory, and fixes a rare problem where a write-protection fault by other applications could freeze the computer. The updater is a 390K download. [JLC]
by Geoff Duncan <firstname.lastname@example.org>
Nearly two years ago, I wrote an article in TidBITS-347 called "Those Bulk Email Blues," which outlined issues surrounding unsolicited commercial email ("spam"), and how to respond to those messages.
Although much of that article remains relevant, times have changed. Spam continues to increase: since 01-Jun-98, I've received nearly 800 spams, an average of more than 11 per day. Further, spammers frequently probe my network looking for mail servers to exploit - my servers are locked down, but occasionally I run a dummy server that reports attempted spamming back to the originating network (and laughs gleefully when it does so). I'm also a party in the TidBITS lawsuit to test Washington's anti-spam legislation.
Don't Be Complacent -- During the last two years, I've become convinced that failing to report spam responsibly contributes to the wider spam problem. By failing to report spam, Internet users send an implied message to network providers, and hence to spammers: "This message didn't bother me enough to report; therefore, it is acceptable." If Internet users want spamming to stop, they must send a consistent, explicit message: spamming is unacceptable. Users can send that message by working toward effective legislative and technological solutions, and by reporting spamming incidents.
The problem is how to report spam. Most spammers try to cover their tracks: they use bogus return addresses, insert false headers, and relay messages through unsecured mail servers. Nonetheless, it is possible to figure out where you should report most incidents. Doing so requires time and some knowledge - but, as with all things, the more you do it, the easier it gets.
Identifying the Server -- To report a spamming incident, you must determine what Internet server sent the spam message to you, which means looking through the message's Received headers. Ignore return addresses or From lines: they're easily forged. Received headers are typically grouped near the top of a raw email message and appear in a particular order: the topmost header is the most recent, and (in theory) the bottommost indicates the message's origin. Email messages always have at least one Received header.
The bottommost Received header may not always identify the originating system. Spammers often forge one or more Received headers to throw you off the trail, but they can't forge them all. Forged Received headers appear beneath any legitimate Received headers and are often obviously different.
The only guaranteed way to figure things out is to start from the topmost Received header and work down. Look for the first Received header that claims to have sent the message to the domain where you receive email. If you have an account with EarthLink, for example, look for the first header that mentions an EarthLink system. Here's a fictional header that points to a location on my network:
Received: from Fred (pointless.quibble.com [126.96.36.199]) by smtp100.earthlink.net (8.8.8/8.8.8) with SMTP id MAA17789 for <email@example.com>; Sun, 9 Aug 1998 12:55:13 -0700
You can see the system smtp100.earthlink.net received a message from a machine calling itself "Fred," a name probably supplied by the spammer. However, EarthLink's mail server didn't blindly accept Fred's statement of identity and performed a DNS lookup, discovering that Fred's canonical name is pointless.quibble.com. (All Internet machines have at least one unique IP number; machines don't require any assigned name, but can have many names, only one of which is canonical.) EarthLink's mail server inserted pointless.quibble.com in the Received header along with the machine's IP number to make it easier to track the origin of the message. This is good - these days, mail servers at many responsible Internet providers tag messages in this manner. Now you know the message came to EarthLink from quibble.com, and that's probably where you want to send your spam report. Let's look at a more complex example:
Received: from pointless.quibble.com (pointless.quibble.com [188.8.131.52]) by smtp100.earthlink.net (8.8.8/8.8.8) with SMTP id MAA17789 for <firstname.lastname@example.org>; Sun, 9 Aug 1998 12:55:13 -0700 Received: from Fred by pointless.quibble.com id QQfbjb05104 Sun, 9 Aug 1998 12:54:34 -0700 (PDT)
Here we can see that a machine calling itself Fred connected to a machine calling itself pointless.quibble.com, which didn't do any checking on Fred. Then, pointless.quibble.com connected to EarthLink, which confirmed the machine's name and delivered the message to you.
This second instance is probably a case of "relaying," where a spammer found an exploitable mail server in the quibble.com domain. This particular server would be a spammer's dream because it doesn't identify the machine that sent the message in the first place. The administrators of quibble.com may not be involved with the spammer and may not even be aware their system was used to distribute spam. You still want to report the incident to quibble.com and strongly encourage them to disable relaying on their mail server. Unfortunately, there isn't enough information to track the spammer further; hopefully, quibble.com's mail server keeps logs that would enable its administrators to determine the spam's origin.
If any of your mail is forwarded to you from another address, you may need to ignore one or more topmost Received headers. For instance, all mail to <email@example.com> is forwarded to me at quibble.com. The topmost Received line in spam to <firstname.lastname@example.org> always says that quibble.com received the message from tidbits.com. But the TidBITS server didn't originate the spam; I need to look at subsequent Received headers to see what machine sent the message to the TidBITS server.
IP Numbers & Ranges -- Sometimes even a well-configured email server won't be able to look up a canonical name for the machine giving it an email message. A Received header might look like this:
Received: from 184.108.40.206 ([220.127.116.11]) by smtp100.earthlink.net (8.8.8/8.8.8) with SMTP id MAA17789 for <email@example.com>; Sun, 9 Aug 1998 12:55:13 -0700
To report this incident, you need to figure out who's responsible for the IP number 18.104.22.168. First, try a DNS lookup yourself to see if the number has an assigned name. Many utilities will perform a DNS lookup. For the Mac, I recommend Peter Lewis's $10 Mac TCP Watcher or Peter Sichel's $20 IPNetMonitor, both of which also include traceroute tools.
Looking up 22.214.171.124 should reveal pointless.quibble.com, which indicates that you should report the incident to quibble.com. But let's say no name turned up. Your next best bet is to use a Whois server to determine who's responsible for that IP number. The Whois protocol enables you to ask a network authority for information about domains, systems, and points of contact for Internet sites. Unfortunately, there is no central network authority for the entire Internet. The American Registry for Internet Numbers (ARIN) maintains a good Whois database for domains registered in the U.S.; I always try ARIN first. Other network authorities include the InterNIC, RIPE (for European domains), and APNIC (Asia Pacific). Services like Allwhois.com try to be comprehensive but are more useful for determining if a particular domain is available, rather than figuring out IP number assignments.
You may have to check with several authorities before you find who's responsible for an IP number. You may also have better luck searching for a range of IP numbers using an asterisk ("204.57.207.*") than looking for a single IP number, although you'll need to be careful interpreting the results. Multiple searches are awkward via the Web; you can also use a dedicated Whois client to query the databases directly. On the Mac, try IPNetMonitor or Peter Lewis's $10 Finger, which can query Whois servers.
If you look up 126.96.36.199 or 204.57.207.* via appropriate Whois servers, you find Northwest Nexus, which is my upstream ISP. If you were to report a spam incident from my domain to Northwest Nexus, I'd be taken to task quickly. Not all providers are that responsible, however; if spamming persists from a domain or an IP number after you've reported a few incidents, you can use a Whois server to figure out who's upstream from the responsible party - usually AT&T, Sprint, UUNET, or another large network provider. Most high-level network providers have a low tolerance for spam, but may only be able to forward complaints to their customers, such as regional ISPs. In my experience, reporting spam to upper-level network providers is only moderately effective.
If you can't use Whois to figure out who controls an IP number, your last option is a traceroute utility. Traceroute essentially figures out the path that packets are taking between two Internet machines. This path should show you what sites are "closest" to the IP number that sent the spam. You could send spam reports to the domain indicated as "closest" to the IP number that sent the spam message. However, be aware that Internet routing is dynamic: although the specific path between two machines usually doesn't change from moment to moment, it can change at any moment. Machines near your target IP number may have nothing to do with the spammer or the organization responsible for the IP number. If you report a spam incident using data obtained from traceroute, do so politely.
How to Report Spam -- When reporting a spam incident, include the complete text and headers of the message you received: administrators need this information to verify the incident. A courteous, professional message is always more effective than a vitriolic rant. I begin my reports with this boilerplate text:
I received the following unsolicited commercial email ("spam") that was either sent directly by one of your users, relayed through a mail server on your site or network, or sent from a dialup pool or downstream network administered by your organization. I've enclosed the complete message below with full headers; please ensure this doesn't happen again.
Since I live in Washington State, my messages also point to information about Washington's anti-spam legislation and mention the per-incident damages Washington residents can try to collect.
Send spam reports to the username "postmaster" and, optionally, "abuse" at the domain you've determined is responsible for the spam. The postmaster address is almost universally valid for a domain; the abuse address is less common but is often set up as a reporting address for spamming incidents.
For best results, always report spam to an address at a domain, not to a specific machine. In the examples above, you would use <firstname.lastname@example.org> rather than <email@example.com>. If the spam originated from a site using a two-letter country code (such as .us) rather than a three-letter top-level domain (such as .com or .edu), the domain will contain at least three parts (reno.nv.us) rather than two (quibble.com).
Removal Services -- What about removal services listed in spam messages, or sites purporting to be "global remove" lists? Two years ago, I recommended these removal services, figuring that responsible bulk mailers (there are a few) will remove your name from their lists and irresponsible ones have your address anyway, so there's no harm in trying.
Today, I can't recommend any removal services. Although a few are legitimate, far too many are either non-existent or simply address-collection clearing houses. One instance I chased down turned out to be a sophisticated operation used by several spammers: they collected the removal requests, then sold the senders' addresses to other spammers as "fresh addresses."
Don't Just Take My Word for It -- The issues surrounding spam are often the subject of debate. Although this article contains technical information and tips, in the end it's just my opinion. If you're interested in learning more - including other opinions about responding to spam or current legislative and technology initiatives - some of the links Adam has collected regarding TidBITS's anti-spam lawsuit are a good place to start.
Will the techniques outlined here stop the flow of spam into your mailbox? No. Is reporting spam simple? No. But at least reporting spam appropriately is an alternative to complacency, and you'll have the satisfaction of hearing from providers who have shut down spammers thanks to your reports. For that alone, many people will thank you.
by Adam C. Engst <firstname.lastname@example.org>
Let me tell you a story that highlights the importance of some of the issues surrounding backups and information security that I've been harping on in TidBITS lately.
A Weekend Away -- Two weekends ago, on Saturday morning, Tonya and I were getting ready to visit friends for the weekend. I was finishing an Indian dish for dinner and checking the weather forecast on our "kitchen Mac" - a PowerBook 5300 connected via Ethernet to the rest of our network and to the Internet. Suddenly, the PowerBook beeped and displayed a dialog from Retrospect Client telling me that it hadn't backed up for a while. I tried to use Timbuktu to connect to our backup Mac, a Centris 660AV, realized that the machine had crashed, and went downstairs to restart it. A while later I remembered to check on it again. Curses! The crash had messed up Retrospect's catalog file, and Retrospect wanted me to verify it before proceeding. I started the verification, but Retrospect's log claimed the tape drive needed its heads cleaned. Muttering about the universe being after me, I popped in the cleaning tape, then replaced the backup tape and started the verify process again. About this time, Tonya was giving me those "We should have left ten minutes ago and you're messing around with the computer" looks, so I decided the verify process could work on its own, closed the PowerBook, locked the door, and left.
The weekend was marked primarily by aquatic sports and sunburns courtesy of defective sunscreen. Our time was relatively Macintosh-free, aside from maintenance on a PowerBook 165 used by our friends's son to communicate via voice synthesis and typing with head switches (he has cerebral palsy and is confined to a wheelchair). Sunday evening on the way home, we had dinner with Geoff Duncan, who mentioned our 56K frame relay connection was down. I checked from his place, and while the router responded to pings no other machine on our network responded. Weird.
Arriving Home -- When we returned home, the mystery resolved itself in an ugly fashion. The door was unlocked, and on the kitchen floor were the boxes that the PowerBook 5300 had sat on, with the 10-Base2 Ethernet cable pulled out of the wall. The PowerBook was gone. I checked the rest of the computers, but nothing else had been touched, aside from a broken window pane at the back of the house.
Slowly, we pieced together what must have happened. The thief probably rang the doorbell, noticed that no lights came on (our other car was there, so we could have been home), and decided to case the joint. Looking in the kitchen window, the thief saw the PowerBook and our alarm system sticker, and decided on a fast job. Slinking around back, the thief picked a window without an alarm sticker, broke it in, and immediately went to the kitchen (passing by Tonya's Mac). Once there, the thief grabbed the PowerBook and all the cables attached to it, and then took a wooden stamp box Tonya gave me years ago from a drawer beneath the PowerBook (though not the stamps - go figure). That done, the thief unlocked the door and fled.
The burglary took place about 1:45 AM Sunday morning, since the thief's clumsy efforts to disconnect the PowerBook caused our Ethernet network to go down at exactly 1:48 AM. That explained why the router answered pings, but all other machines were dead to the world. Later, the police came, took down the details, and said they'd keep an eye out for the PowerBook at pawn shops. The next day, I started the claim process with the insurance company, which has been reasonable so far. Although we have a $1,000 deductible, I should be able to get a PowerBook G3 to replace the 5300.
Backup Lessons Hammered Home -- After I picked up the pieces and restored the network, I went to check on the backup. Retrospect's verification had finished but had prevented backups from running Saturday night. When I dismissed the verify completion dialog and started the backup server, Retrospect started reporting errors with the current tape. In short, although I might be able to recover some data from that tape, there's no telling.
Remember all those articles I wrote about backup? Here are some real-world examples of what did and could have gone wrong.
Always make multiple backup sets. Thanks to the dubious tape I was fighting with on Saturday, I'll probably have to return to the previous week's set to recover the PowerBook's files.
Off-site backups are essential. I've recently made a point of rotating a backup set to an off-site location each week. Although the backup tapes weren't stolen, they could have been.
Fight backup complacency. The universe has a twisted sense of humor and an unknown agenda, which means that something will go wrong just when you least expect it. We seldom go away for the weekend, the backup Mac seldom crashes, tapes seldom develop errors, and we've never been burglarized before. The entire point of a backup strategy is to prevent unhappy coincidences from mutating into catastrophes.
Security Musings -- In situations like this, you immediately start obsessing about security and what you could have done. Here are a few of my more realistic thoughts (i.e., those that don't involve automated gun turrets on the roof).
I'm planning to enable password protection in Retrospect for my backup sets. It's unlikely a thief would steal the backup tapes and know what to do with them, but if the backup Mac was also stolen, there's no telling what could happen. We don't have much sensitive information, but we still don't want miscreants poking through personal email and financial records.
Situations like this are a great example of why Web Confidential (see TidBITS-441) can be useful. I didn't keep confidential data on that PowerBook, but many people do, especially heavy travellers. And, even if you kept that information on paper in a safe deposit box, it's still vulnerable en route to the bank, and even safe deposit boxes aren't completely safe.
On the back of many of Apple's hardware devices, there's a security slot (sometimes two, in different sizes). Metal clips plug into that slot and provide an anchor point for lockable cables. The larger slot seems to be older, and folks on TidBITS Talk report that Apple used to sell security kits. Nowadays you get them from Byte Brothers, Security Solutions, or University Accessories. The smaller slot is the Kensington Security Standard, and Kensington and other companies offer security products to fit. TidBITS sponsor Cyberian Outpost sells the Kensington MicroSaver products; check the sponsorship area above for details. I'm contemplating investing in one of these solutions for all my Macs.
I keep thinking there should be a way to have our computers watch the house more carefully. I have an analog-to-digital converter (the EnviroMac from Remote Measurement Systems, which I plan to write more about soon). I could check light level changes and play sounds or control lights, for instance. Email or telephone alerts are also possible, but false alarms are too likely, so I'd settle for scaring away robbers.
This isn't a topic I've thought much about before, so I'd like to open it up to discussion on TidBITS Talk. If you've set up a security system involving Macs (perhaps via a Connectix QuickCam and DigitalRadar) send your story to <email@example.com> and I'll post the best ones. To subscribe to TidBITS Talk, visit the second URL below.
Stolen PowerBook Registry -- I found a new service offered by the good folks at O'Grady's PowerPage. O'Grady's Stolen PowerBook Registry is a Web database with which you can register stolen PowerBooks by serial number and check to see if a PowerBook you're thinking of buying was stolen. I've already registered my PowerBook, and I encourage other victims of PowerBook theft to do so as well.
Laptops are an increasingly common target, since they're expensive and small. I've seen numbers claiming as many as 1 in 14 laptops are stolen, and Safeware Insurance said recently that companies it insures filed $1 billion worth of claims for almost 310,000 stolen laptops in 1997, up 28 percent from 1996. Laptops are simply too attractive as theft targets, as evidenced by the fact that our thief stole little else. Ironically, the claims coordinator I've been working with said that Macs are far more commonly stolen than PCs - perhaps we aren't giving thieves sufficient credit. In the end, the moral of the story would seem to be that you should do as much as is reasonable without succumbing to paranoia that would have you afraid to leave your possessions for even a few moments.
Non-profit, non-commercial publications and Web sites may reprint or link to articles if full credit is given. Others please contact us. We do not guarantee accuracy of articles. Caveat lector. Publication, product, and company names may be registered trademarks of their companies. TidBITS ISSN 1090-7017.
Previous Issue | Search TidBITS | TidBITS Home Page | Next Issue