Make It an Internet Server, Part II |
|
Setting up more expensive web servers would be easy. You could wait for Apple's newest file server for a few thousand dollars, buying AppleShare IP or OS X for around $1,399, and hook it to the web through a commercial firewall for around $450. You could use an older Power Mac and buy the well-reviewed, commercial product, WebSTAR for a mere $599 more. WebSTAR needs a PowerPC chip, so that'd send my old reliable Centris on the road to the scrap heap. Alternatively, you could create a serviceable multihosted web server for between $25 shareware fee and $129 for a cheap commercial product.
The first part of this trick is performed by a piece of freeware named Quid Pro Quo 2.1.2 from Social Engineering. You can download it from http://www.socialeng.com/. The freeware version, QPQ, needs a small shareware product to perform multihosting. Even with that shareware, QPQ is limited to virtual multihosting. If you choose this route, you won't need the single-line multihosting abilities of Mac OS 8.1 or Open Transport 1.3, and you can probably use a much older computer than a Quadra or Centris. You will not be able to provide secure SSL connections, because reverse lookups of your virtual sites will get incorrect results.
Alternatively, the commercial version, Quid Pro Quo Plus 2.1.3 (QPQ Plus), does everything you need to finish this part of the project by itself for a cost of $129. It's the "cheat" I used to get my "freeware" single-line multihosted server to work, but buying Quid Pro Quo Plus required a bit of an unexpected effort. See the sidebar, "Hacking for the Sale." If you don't need any form of multihosting, or virtual multihosting is sufficient, the freeware version of Quid Pro Quo works fine, and it downloads without a whimper.
If you want multihosting, but you can't get a copy of Quid Pro Quo Plus, or are hesitant to buy a copy that comes with absolutely no technical support, you can use a wonderful $25 shareware plug-in called Welcome. Welcome is written by a responsive and bright European named Andreas Pardeike who responded to my anonymous email inquiry within 12 hours with complete, honest, and accurate information. Not only is his plug-in simple to install, but it is remarkably cheap. It provides extensive functionality in providing server statistics and routing rules in addition to its principal purpose of providing single-line multihosting for web servers other than Quid Pro Quo and virtual multihosting for the rest. Best, you can put yourself on (and take yourself off of) a listserver of active webmasters running Welcome, and both Mr. Pardeike and they provide the kind of technical support that will not be available from Social Engineering -- or anyone else. Though I have decided to single-line multihost using Quid Pro Quo Plus, which, in my opinion, undercuts the principal purpose for using Welcome, I will probably install Pardeike's new Welcome 3.0 and download his just released version 3.0 of his manual just to get the technical support and the access to extra statistics on my sites. Pardeike's Welcome can be downloaded for a seven day test run at http://welcome.pardeike.net.
Unfortunately, the freeware version of Quid Pro Quo is crippleware -- not only is access to Open Transport's built-in single-line multihosting not implemented, but Social Engineering decided not to implement the type of plug-ins that would allow other software to access the multiple IP addresses arriving from the Internet. As a result, Welcome cannot provide single-line multihosting on Quid Pro Quo. Even if you use IPNetRouter to pass the secondary IP addresses through to the user interface, I could not find a way to make Quid Pro Quo recognize multiple addresses. Of course, one possibility is to run multiple copies of Quid Pro Quo, but that sounded too complex, and very likely to run into memory problems when hosting multiple domains, just to save $129. For that amount, Quid Pro Quo Plus provides both single-line and virtual multihosting, as well, if you can manage to download it.
Welcome can provide virtual multihosting on Quid Pro Quo, Quid Pro Quo Plus, or, for that matter, WebSTAR, AppleShare IP, or any other WSAPI compliant web server. You cannot operate a secure site from a virtual multihost, since the SSL standard is inconsistent with a domain name that does not match a specific IP address in a reverse lookup. It would seem that you could assign a generic secure site domain name, such as "securecheck123.com" to be your primary site associated with the IP address, and put you regular, http sites in virtual hosts, but I haven't tried this.
While setting up virtual multihosting with Welcome is difficult, Andrew Pardeike's manual is so good that I won't try to repeat it here. The manual for Quid Pro Quo Plus is awful compared with Pardeike's manual, but setting up single-line multihosting with Quid Pro Quo Plus is so easy -- once you have the hosts defined correctly in Open Transport -- that I'll just leave the rest for your creativity.
The mail server
The mail server is even better news than the web server. There are two freeware products from which to choose, Apple's Internet Mail Server, AIMS, which has since been sold to Qualcomm and renamed Eudora Internet Mail Server, EIMS, and Stalker Internet Mail Server, SIMS. The pundits prefer SIMS for stability and other reasons, but I never tested AIMS. SIMS, which can be downloaded free along with its control application, CommuniGator, at http://stalker.com, are as easy as they are free, and their extensive manuals come in two versions: a downloaded short version, and extensive on-line documentation. Both manuals are written in HTML with hyperlinks and are designed to be read with your browser. You'll need the on-line manual to use the routing tables to set up multihosting, but once you discover the format for the routing table and follow it, the mail server will spring to life. SIMS is my hands-down, five mouse favorite without giving AIMS a fair test drive, because, in addition to the documentation, it has immense power and flexibility, particularly in controlling Spam and defining routing for email accounts.
In order to understand what you are doing and why things are named as they are, it is important to correct another set of misnomers in Internet linguistics. You will frequently hear and read references to POP and SMTP "servers," and it will often seem that ISPs have set up separate POP and SMTP servers to send and receive your mail at addresses like smtp.wap.org or mailroom.wap.org. Your internet server can act as host to multiple services, however, including POP and SMTP mail service and web page services, because these services are carried on different logical "ports" on the same host machine. Web pages are customarily found through port 80, and when your computer asks my web server for a page in http: format, such as the request http://www.SternbergLaw.Net/index.html, my domain name service knows that the host www.SternbergLaw.Net is located at the IP address 216.50.13.165 and sends the request to that address. My Web server is set by default to listen to web requests (http service) on port 80, and to look to the folder SternbergLaw. I've programmed the web server to answer requests for www.SternbergLaw.Net by selecting the folder SternbergLaw in the Folder preferences under Quid Pro Quo. The server looks for a file named index.html, and, sends the page back to you.
Your email inquiries are routed similarly. Sending or receiving email for Richard@DCMdVaLaw.com eventually sends a request to my domain name service, which associates the domain DCMdVaLaw.com with the host located at 216.50.13.167, and your email request, which is more accurately called Simple Mail Transfer Protocol (SMTP) request, is routed to the default ports 25 and 150. Because of multihosting, this is all actually occurring on the same host machine as requests for multiple other hosts and for multiple difference services provided on different ports.
Armed with this knowledge, you won't make the only major time consuming mistake I made -- trying to understand how to name the servers. Quite simply, SIMS will be your Internet mail server, and, as long as you have correctly set up the multihosting in Open Transport, it will monitor the proper ports for each of the IP addresses coming into your machine. If you tell it in the routing table to which folder it should route mail coming into each account name in each active mail domain, it will happily route and deliver mail to those folders. There is no need to create separate host names like pop.domainname.com or smtp.domainname.com, but you can use just your domainname.com.
Having control over your own mail server has some wonderful benefits. First, you can get a bit creative with the SIMS routing table. I have account names under multiple domains, so some people send me email at Richard@WashingtonLawGroup.com, others send email to me at Richard@SternbergLaw.Net; still others will use Richard@DCMdVaLaw.com, and my personal email will either continue arriving at my Washington Apple Pi account, or will use Richard@RSSternberg.org. I could, if I wished, route these to separate mailboxes, but I prefer to have my personal email placed in a separate folder, and all other emails checked together, with the account name of each identified by my mail reader. My routing table is therefore set to send all requests for "Richard" at any of the addresses, except RSSternberg.org, to the same folder named "Richard." And, when I want to use a separate box, mail to "Sternberg" and any of these (or other) multiple addresses goes to a folder named "Sternberg."
<*@RSSternberg.org<= Personal-*
<*@WashingtonLawGroup.com<= *
<*@SternbergLaw.Net<= *
<*@DCMdVaLaw.com<= *
<*@twlg.com<= *
<*@svg-law.com<= *A partial routing table in SIMS.
SIMS allows special controls over each email account name. For example, when email arrives to Richard@RSSternberg.org, SIMS sends a notice to me at Richard@SternbergLaw.Net. To maintain optimal client communications, email sent to Richard@WashingtonLawGroup.com is immediately acknowledged with an automatic reply written by me, but issued by the server as a return receipt for all incoming letters. I use that form letter to remind my less Internet-savvy clients about some legal and practical differences between email and snail mail communications in a law office.
Another major benefit involves Spam control. Before setting up this server, I tried using a commercial name at AOL. Less than a year later, the account receives 90% Spam email. I tried a commercial email account through my shared T-1 provider. Within two months, the account is 10-20% Spam. Though I use reasonably hygienic practices in disseminating my email addresses, the reason for having a commercial email address is to have clients or customers find it. By registering email addresses in standard, free directories, or by merely using the email addresses in some contexts, you become a target for unreasonable quantities of Spam.
With the SIMS mail server, you can control or eliminate Spam to the extent appropriate to your business or personal use.
|
|
|
The SMTP services settings in SIMS, as shown in the manual. |
To prevent use of your mail server as a launching point for foreign Spam, you'll want to prevent the server from relaying mail. Failure to do so will get your IP address identified as a Spam source and may block your access to other protected sites. But, you can also list privileged IP addresses which will be allowed to use your server to relay mail under your hosted account names. I find the verify return path option particularly attractive as a Spam preventative, since most of my Spam comes from anonymous or masquerading sources, and one quick click has eliminated all of them. Finally, not only can you manually blacklist spammers or other hackers whose IP addresses show up too frequently in your logs without suitable explanation, but you can use a published list of spammers to screen your email. The list used by both the Pi and me, frequently called a "reliable" or "rbl" server, is located at http://maps.vix.com/rbl/.
|
|
|
SIMS SMTP settings running on top of the Quid Pro Quo Plus web server. |
Do you want a domain name server?
The last part of my project is, sadly, not complete as of this writing. You will need to run a DNS if you wish to be your own responsible party reporting your domain to the InterNIC. Without this, you will continue to require some sort of secondary hosting service from an ISP, and your ISP will act as the responsible party for your site. While they are "responsible" for almost nothing, this means that you have to put in your requests to create new host names on your domains through the ISP, and, for me, this service costs $50 per year per domain. It's not an overly large sum, but the function of a DNS would seem too easy to be omitted from my server. Let's review what I know so far about setting up a freeware or cheap shareware DNS.
First, there is at least one freeware DNS widely available. Apple has produced four versions of MacDNS resulting in the current version 1.0.4 revised in February 1999. Sadly, the reviews of the freeware by network managers who are members of the Washington Apple Pi are uniform -- MacDNS is unstable. It is alleged to be particularly unstable if run on a Mac running any other Internet service, so I decided I would not take a run at this unless I did it on a second, cheap machine. Apparently, an old Mac SE might be sufficient, but I have no other scrap machines which are Ethernet capable to test this. Further, MacDNS is reported to be sufficiently at risk for collapsing under a load of bad packets that it should have a firewall to reject such packets.
I don't have another Ethernet-capable scrap Mac; I'm unwilling to put any publicly available service behind our secure office firewall; and I have no intention of learning how to program my Cisco router (bringing the T-1 service into the office) as a firewall. I therefore have no safe way to test MacDNS as a freeware DNS. Other low-end DNS products, like QuickDNS, seem to cost about $290 to $390, which is almost two years of the cost of secondary hosting services for all of my sites together. And the other freeware DNS which received much better reviews, QuickDNSLite, seems to have been pulled from the market.
I have an answer for my office, but the answer is beyond the scope of this article. On a Linux platform, a freeware DNS named BIND will run just fine, receives good reviews, and is reputed to be tolerable to set up. We have our firewall and our main file server both running Linux, and one will, before the annual renewal of my secondary hosting services, be running BIND and providing DNS service for my Internet servers. I hope, before then, to find a Macintosh solution, and you can follow any discussions about this, or ask your own follow-up questions, on the Pi's TeleCommunications System bulletin board on Conference 3, Board 21, "Bithead." To a lesser extent, I'll answer email about this directed to Richard@SternbergLaw.Net.
There are a number of DNS solutions, but, even absent a good Macintosh solution for domain name service, running your own small office or personal shareware web and mail servers on a multihosted Mac may be a fun, environmentally friendly, and a sensible project for you.
