09/07/95 8:12pm
Copyright (C) 1995 Homer Wilson Smith Redistribution rights granted for non commercial purposes.
I want to thank Robert Sanders [rsanders@interbev.mindspring.com] from whom this material derives.
I also want to thank Christopher X. Candreva (chris@westnet.com), who saved my butt when I needed it most. Check out his home page at http://www.westnet.com/providerswhere the patch lives.
SENDMAIL VIRTUAL DOMAINS
Sendmail version 8.x allows the creation of virtual domains with an unlimited number of userids for each domain, and userids do NOT have to be unique to the system, simply unique to the virtual domain.
You do NOT have to assign an IP number to this virtual domain, the way you do with web virtuals.
First you need to be primary name service for the domain. Say the requested domain is artmatrix.com, and you are lightlink.com.
You will have various files in your /etc directory for doing primary name service. The examples that follow are pretty straight forward, but the file names may not be identical to yours.
In /etc/named.boot you will have your own primary name files listed. At the end you will have a listing for the file that defines artmatrix.com. It will look something like this,
directory /etc/named
primary artmatrix.com /light/artmatrix.com
That means the file defining artmatrix.com is contained in /etc/named/light/artmatrix.com.
That file looks like so,
@ IN SOA light.lightlink.com. root.light.lightlink.com. (
95082600
10800
3600
604800
86400 )
;Domain lightlink.com is served by Name Server light.lightlink.com
IN NS light.lightlink.com.
IN NS secondary name servers go here.
IN NS "
IN NS "
artmatrix.com. IN MX 100 light.lightlink.com.
*.artmatrix.com. IN MX 100 light.lightlink.com.
ftp.artmatrix.com. IN CNAME ftp.lightlink.com.
www.artmatrix.com. IN CNAME www.lightlink.com.
This file provides a simple aliasing between artmatrix.com and lightlink.com.
Under normal circumstances you will have artmatrix.com in your sendmail.cw file which allows sendmail to accept mail for that domain.
Mail sent to homer@artmatrix.com will go to homer@lightlink.com. The problem is that mail sent to anybody@artmatrix.com will also go to anybody@lightlink.com and this is undesirable.
Worse most companies want info@artmatrix.com, sales@artmatrix.com and tech-support@artmatrix.com, but these are already taken by lightlink itself! So what do you do?
THE SENDMAIL ALIAS FILE
The usual sendmail alias file allows for simple aliases. For example you can redirect 'sales' to any particular account, but that means sales@artmatrix.com, sales@lightlink.com and sales@other.domain will all go to the same account what ever it is. You need a way to make sales@artmatrix.com go to one account, and sales@other.domain go to another account, so working with a simple alias file will not work.
SENDMAIL VIRTUAL DOMAINS
The way sendmail handles this is with a more complex alias file called a db file, or database file. You create a file called /etc/sendmail.db which has lines in it like this,
artmatrix.com homer
sales@artmatrix.com jes@netcom.com
info@artmatrix.com info
other.domain.com joe
sales@other.domain.com susan@crl.com
info@other.domain.com info
The lines with domains on them alone define a default account that ALL mail for that domain goes to that is not other wise defined. Thus if someone sends mail to fred@artmatrix.com it will go to homer, and NOT to fred@lightlink.com even if fred exists on lightlink.
The second line shows that mail can be redirected anywhere, the people receiving the mail don't have to have accounts on your machine. That allows a company that already has many employees with many different providers to have a common virtual domain name, and your system will distribute the mail transparently to each person.
The fifth line shows that someone else on your system can also have sales@their.domain as a userid, and it won't conflict with the earlier sales@your.domain and neither will conflict with sales@lightlink.com.
The third and sixth line are interesting in that both addresses point to a common receiver, namely info@lightlink.com. This is because we are running a 'virtual infobot', that looks at the address of the incoming To: line, and decides what information to send out according to the domain it came in for. That way everyone on our system can have an info bot automatically handling out material for them.
The info bot has a central data base that 'registers' the home directories that are authoritative for each domain. Artmatrix.com points to /home/homer, that's me. In /home/homer/info there is a file called 'info.info' that lists all the files that I want the info bot to send out. The outgoing mail goes out with From: info@artmatrix.com.
The nice thing about the infobot is it is not limited to just one address per domain. I could also have the following lines in our sendmail.db file,
info@artmatrix.com info
info-stamps@artmatrix.com info
The infobot, seeing mail coming into it with info-stamps@artmatrix.com would go to my home directory and look for the file called info-stamps.info, and send out the files listed in that file instead.
So there is no limit to how many sets of info files a single customer can have, and of course all of his info names do not conflict with anyone else's info names even if they are identical, because the domain names are different.
The infobot can also handle customers who do not have virtual domains with us. It will handle joe-stamps@lightlink.com by going to joe's directory and finding his info file called joe-stamps.info. In this case 'joe-stamps' is a simple alias stored in the /etc/aliases file, and must be unique to the system. The alias as before simply points to info@lightlink.com.
Although this program is in alpha testing, it is free to the internet community. It's a perl script.
OK, SO HOW DO WE MAKE SENDMAIL WORK ALL THIS MAGIC?
In order for sendmail to utilize the sendmail.db file, it needs two things. First the sendmail.db file itself needs to be converted into a database file using the following shell script called 'makesend'.
#!/bin/csh /etc/makemap hash /etc/out < /etc/sendmail.db
Makemap is a part of the sendmail v8 distribution, and I simply moved it over to /etc after compiling it. There is a man page for it in the sendmail v8 distribution.
The result of makesend is the creation of a file called /etc/out.db that contains the data in sendmail.db in a form that sendmail can use.
The next change that needs to be made is sendmail needs to be told what the name of its database file is, namely /etc/out.db. This is done with the 'K' line in sendmail.cf.
Here is a relevant section from my own sendmail.cf. The 'dequoting map' is put in there by sendmail itself and is not relevant, the next line I put in there.
# dequoting map Kdequote dequote Kmaildomains hash /etc/out.db
OK, now here is the hard part, and in fact this should be done first before all of the above! You will need to stick 4 'LOCAL_RULE_0' lines into your sendmail.mc file before you m4 it into a sendmail.cf. I have included my sendmail.mc file in toto below so you can see what I did. These 4 rule lines go into your sendmail.cf file under Local Rule S98. Do a look through your sendmail.cf after you have m4'd the .mc file and you will see them there. You will notice they use the term 'maildomains' which is where the K command above gets it from.
divert(-1) include(`../m4/cf.m4') VERSIONID(`@(#)sunos4.1-cs-hidden.mc 8.1 (Berkeley) 6/7/93') OSTYPE(sunos4.1)dnl DOMAIN(light)dnl MAILER(local)dnl MAILER(smtp)dnl MAILER(usenet)dnl MAILER(pop)dnl FEATURE(use_cw_file)dnl FEATURE(redirect)dnl FEATURE(always_add_domain)dnl FEATURE(allmasquerade)dnlLOCAL_RULE_0 R$+ < @ $+ . > $: $1 < @ $2 > . R$+ < @ $+ > $* $: $(maildomains $1@$2 $: $1 < @ $2 > $3 $) R$+ < @ $+ > $* $: $(maildomains $2 $: $1 < @ $2 > $3 $) R$+ < @ $+ > . $: $1 < @ $2 . >
OK, so do it in this order.
Add the rule lines to your sendmail.mc file, and then m4 it into your sendmail.cf file.
Add the K line into your sendmail.cf file.
Create the sendmail.db file, and makesend it into an out.db file.
Kill sendmail and restart it. DON'T use kill -9. Kill it dead. You can and should create a little shell script that will kill and restart sendmail, named, and httpd, as you will need to be doing this alot. Named and httpd only need a kill -9.
Here's a simple shell script for killing and restarting sendmail. It depends on the location of sendmail.pid which I arbitrarily put in /etc when I compiled it.
#!/bin/csh set a = `cat /etc/sendmail.pid` echo $a kill -9 $a[1] $a[2] $a[3] $a[4]
So that's it. You can now create entire virtual domains for your customers. You can even allow them to keep a personal sendmail.db file in their home directories and write a perl script that seeks them out every night, incorporates them into the system wide /etc/sendmail.db file, and creates a new database automatically. That way your customers can change their virtual sendmail domain names without ever bothering you.
Homer
ART MATRIX - LIGHTLINK PO 880 Ithaca, NY 14851-0880 (607) 277-0959 Voice (607) 277-8913 Fax homer@lightlink.com E-mail
08/26/95 3:47pm
Dear Lightlinker,
We will be moving everyone who has a domain name registered with us as primary name server, to the new Sendmail Virtual Domain System. Please take the time to read the following carefully so that you understand it. This will go a long ways towards making sure that your mail works smoothly and as you expect it to.
If you have a registered domain with us, you will be given an entry in our sendmail.db (db = database) file that looks like this (using myself as an example):
artmatrix.com homer
This means that ALL mail sent to anybody@artmatrix.com will get sent directly to homer@lightlink.com. This effectively locks out the possible use by unauthorized people of your domain name with out you knowing about it.
Prior to this your domain was a simple alias for lightlink.com. That means that jes@artmatrix.com would go to jes@lightlink.com, and fred@artmatrix.com would go to fred@lightlink.com (who has no idea what artmatrix is!) and so forth. The only addresses that would bounce would be userid's that did not exist on lightlink at all. This was clearly unsatisfactory.
With the new arrangement all of the above go to homer@artmatrix.com.
This is a disadvantage for jes@artmatrix.com who really needs to get her own mail (Jane) but its an advantage for fred who certainly doesn't want it.
Your entry in the sendmail.db file can be expanded to look like this:
artmatrix.com homer
homer@artmatrix.com homer
jes@artmatrix.com jes
joe@artmatrix.com joseph@netcom.com
tech-support@artmatrix.com homer@rahul.net
sales@artmatrix.com 72214,2770@compuserve.com
info@artmatrix.com info
(The info bot does not yet work for other domains, when it does you can include it in your sendmail.db file. The info bot is a whole other story.)
Each address on the left will be forwarded to the address on the right.
A USER DOES NOT HAVE TO HAVE AN ACCOUNT ON THIS SYSTEM FOR THIS TO WORK. Mail coming in for joe@artmatrix.com can be sent to joseph@netcom.com even if joseph does not have an account on lightlink.
There is no limitation on the userid that exists on the right, the userid on the left must be a valid e-mail address somewhere in the world. If there is no domain name mentioned it is assumed to be lightlink.com.
This arrangement gives you total control over your own address space for your domain. We will be automating the process in due time so that you do not have to go through me to update your userid's. Presently you need to submit your userid's to me and I have to hand update them in our system wide sendmail.db file.
In the future, barring security concerns, you will have your own sendmail.db file in your home/vdp directory (vdp = virtual domain package), and each night the system will scan your vdp directory and add your file to the system wide file. This will allow you to seamlessly make changes to your address space without ever having to notify anyone except the people whose mail it involves.
Please take some time to think through what you wish, and mail your present requests to me.
OUT GOING MAIL
If you wish your outgoing mail to also show your private domain name, you can adjust your mailer settings to do this.
For example, if I want my mail to go out as:
Tech Support
In Eurdora I would set my name and e-mail fields accordingly.
In pine on a shell account, I would change user-domain and
personal-name in my .pinerc file. Remember though this applies to ALL
mail you send from that account until you change it back.
CAN OUTGOING HEADERS BE A FUNCTION OF INCOMING HEADERS?
No.
There is presently no EASY way to make outgoing mail change its
headers according to the addressee of the incoming mail.
For those of you who wish to pursue this on your own, there are
various complicated work arounds that might be able to get you this
result if you really need it.
You can set up multiple copies of Eudora with multiple copies of
config files to contain different outgoing names and addresses for
different purposes. But you will have to be careful to use the right
version when responding to any particular mail.
You can do the same for pine, by switching the .pinerc used for
any particular mail session with a csh script prior to calling pine
itself. If you want this explained in detail we can talk more about
it on the phone.
There are also more advanced options in pine and procmail that
allow you to filter your incoming mail into different folders
according to headers in the mail, this would allow you to segregate
different incoming mail for later anwering from different .pinerc
setups or whatever. However you are on your own with this.
CAN WE MIX THE OLD ALIAS SYSTEM WITH THE NEW VIRTUAL DOMAIN
SYSTEM?
No.
Once any single entry is made under the virtual domain system,
the simple alias system ceases to function for that domain.
Therefore if you have more than one person in your virtual
domain, I can not make the change for just one of you without
effecting everyone else's mail.
The minute I create one userid in your domain under the new
system, ALL userid's will be redirected to the primary account or
bounced, unless an explicit entry is there for each person too.
Please get me your company wide aliases as fast as possible.
Those of you who have more than one person in your virtual domain
will not be moved over to the new system until I get your new alias
list. That way your mail will continue to work as is.
Homer
Subject: WWW Virtual Domains
08/31/95 4:45pm
Dear Lightlinkers,
We have recently installed the web virtual domain patch that
allows our system to use virtual domains of the form
rather than the form
http://www.artmatrix.com/homer
Those of you who have registered domains with us, and would like
to take advantage of this patch, please get in touch with me.
Below follows a rather long and technical description of the
solution and the problem that the patch solves.
Homer
IP ADDRESSES, DOMAIN NAME SERVERS AND ALIASES
The internet runs on a protocol called IP (Internet Protocol)
which consists mainly of a way of giving everyone on the internet an
address (205.232.34.1) and encapsulating data that is destined for
that address with a header that contains that addresess so that router
machines know where to hand packets off to to get them where they are
going.
Each host machine on the internet has a port, usually an ethernet
port, that is programmed to respond to a single IP address. In
general you don't want a port to respond to someone else's IP address,
so these ports only respond to their own IP address.
To facilitate the use of IP addresses, there is a world wide
system of name servers, that convert names like lightlink.com to IP
addresses like 205.232.34.1.
The recent rise of ISP's and the high demand for domain names on
the part of people who do not have server host machines of their own,
has made the situation a little more complicated.
For example, say I want the domain artmatrix.com but I don't have
a server on the internet to service that domain. I have to find a
provider that is willing to 'host' that domain for me, so that SOME
server somewhere is servicing that name. The internic will no longer
allow domain names that are not hosted by someone.
This virtual hosting is very easy to do. In the machines called
domain name servers (DNS) there are two records, one for lightlink.com
and one for artmatrix.com and they both point to the same IP address.
For example the DNS might have records looking like this.
The IN means INTERNET PROTOCOL and the A means its an ADDRESS
record as opposed to a mail exchanger (MX) record or other type.
So if I 'telnet artmatrix.com', the domain server looks up
artmatrix.com and finds 205.232.34.1 and connects me to that machine.
Of course that machine is really lightlink.com, but at least
artmatrix.com is virtually hosted somewhere which is better than
nowhere.
This effectively creates an alias for lightlink.com called
artmatrix.com.
This means any requests destined for artmatrix.com go to
lightlink.com instead.
There is no limit to how many such alises can be created all with
the same IP address pointing to the same machine, and in fact we are
already hosting about 10 such domains which you can check for yourself
by looking at the publically readable file called /etc/named.boot.
Look for lines of the form
primary artmatrix.com light/artmatrix.com
This means lightlink.com is primary name server for
artmatrix.com, we hold the authoritative records for what real or
virtual machines are on domain artmatrix.com, and that the file that
lays this all out in detail is in /etc/named/light/artmatrix.com,
which you may also look at.
These aliases are very convenient. For example I have an account
called homer@lightlink.com, so I can send mail to homer@artmatrix.com
and it will get here just fine. It's all a matter of vanity of
course, but as sales person for Art Matrix I want people to send mail
to artmatrix.com and not lightlink.com, and besides its easier for
them to remember. All mail to artmatrix.com really comes to
lightlink.com but no one ever has to know the difference.
FTP AND WEB ALIASES
These aliases of course work for ftp addresses and web addresses
as well.
I can ftp to ftp.artmatrix.com and it will come directly to
ftp.lightlink.com, or I can web to www.artmatrix.com and it will come
directly to www.lightlink.com.
This is sligthly more problemsome than mail. The reason is as
follows.
The web server (httpd) has a concept of what its root directory
is, usually /home/www, and when you go to http://www.lightlink.comit
goes to /home/www which has our main system wide home page in it.
Since these domain names are simple aliases, when you go to
http://www.artmatrix.comit also goes to this same home page which is
not necessarily what you wanted it to do. You probably wanted it to
go to your personal home page directly.
The Art Matrix Fractal home page is stored in my personal www
directory called 'homer', so my usual URL would be something like
http://www.lightlink.com/homer
Since artmatrix.com is an alias for lightlink.com I can also use
http://www.artmatrix.com/homer
and that is pretty cool.
The problem is that anyone looking at that URL immediately knows
that I don't have my own server for artmatrix.com, because the Art
Matrix home page is at least one directory in. This is a dead give
away that Art Matrix is a small and insignificant little company using
the resources of someone who is rich enough to have their own server.
I know this is all vanity, but these things count in the business
world. Also its much easier to remember or even just plain old guess
and figure out
than the longer form with /homer at the end of it.
So these true virtual domains are in big demand, particularly by
businesses that want to put up a good front and be easy to reach and
have memorable and guessable net names etc.
The point is that the company name is guessable, like
www.coke.com, but the person whose directory it will be in is not.
Ok, so what's the problem then?
THE PROBLEM
The problem is that artmatrix.com is a simple alias for
lightlink.com. When a client in California uses netscape to access
http://www.artmatrix.com,the domain name servers resolve the name
into http://205.232.34.1and send it on to that address, namely us.
When the request gets here there is NO INFORMATION in the packet
that the person used artmatrix.com rather than lightlink.com in his
request. It comes in as 205.232.34.1, not as artmatrix.com or even
lightlink.com
Our ether port on light sees the 205.232.34.1, knows it is for
us, grabs it, and puts the person in the root home page of our system
which is NOT the root home page for Art Matrix Fractals!
If the person uses http://www.artmatrix.com/homer,our ether port
sees http://205.232.34.1/homer,grabs it because the address is right,
and then knows to go to 'homer' and plops the person in the Art Matrix
Fractals home page which is what he wanted. But that /homer is an
anathema, so something has to be done about it.
So that's the problem. Now what is the solution?
THE SOLUTION
Since the name artmatrix.com is lost in the process of converting
it to 205.232.34.1 it makes sense to assign artmatrix.com to ANOTHER
IP number that is not equal to light's, maybe something like
205.232.34.2. Thus the DNS servers will have records looking like
this:
This depends of course on 205.232.34.2 not being in use anywhere
else on the internet, and once it is used for artmatrix.com it can no
longer be used for anything else anywhere else on the internet, so this
uses up one more IP number in the scheme of things.
So now when someone makes a request of http://www.artmatrix.comit gets converted to http://205.232.234.2and sent on its merry way.
The problem is that light's ether port is programmed to respond only
to 205.232.34.1 and there ARE NO MACHINES on our net or any net
anywhere that are set to respond to 205.232.34.2! So the packet will
get lost, or else Art Matrix has to set up its own server of its own
with the new IP address, which is something we have been trying to
avoid all along anyhow.
The trick then is to get light's ether port to respond to BOTH IP
numbers as if it were its own.
SunOS 4.1.4 was not originally designed to do this, so this is
where the kernel patch comes in. Once installed, the patch allows
SunOS to assign multiple IP numbers to its ether port, so that light
will respond to multiple IP addresses as its own.
This is called 'virtual hosting', light as a real host on
205.232.34.1 is virtually acting as a separate host on 205.232.34.2.
When the request for http://205.232.34.2comes into light,
light's ether port grabs it because the IP number is one of light's
now many valid IP numbers, and the httpd server sees that the request
is for 205.232.34.2 and not 205.232.34.1 and it can discriminate that
this request is for http://www.lightlink.com/homerand not the root
page, and so it puts the client in the /homer page which is what the
client wanted.
SO WHAT'S THE BOTTOM LINE HOMER, HOW MUCH IS THIS GOING TO COST
US?
Well it costs me one IP number out of a very limited supply.
There are thousands of people coming on line every day around the world,
all of them are
going to eventually want to start a home business, with domain names
and the works.
For lightlink, there is no limit to how many domain names can be
aliased to lightlink.com on a simple aliasing basis because that does
not use up any precious resources. However a true virtual domain uses
up at least one IP number.
When I was granted my Class C address, I was given 205.232.34.xxx
where xxx goes from 0 to 255. So I have 256 IP numbers to give out,
actually 254 because 0 and 255 are not available for use.
I need an IP number for each of my own machines, light, harmony,
tangelo, electra, jes and others that may come in the future.
I need one IP number for each modem port that is available,
that's 72 right there, and more to come.
I need entire chunks of my IP address space to put various
cutomer lans on our dedicated modems, this can use up 16 IP's at a
time.
As you can see, eventually I am going to run out of my IP space,
and that means I have to go to Nysernet and ask for another Class C.
Getting IP numbers out of the internic is becoming harder and harder
because IP numbers are getting really scarce.
Another problem is that if I offer the service for free now, and
people get their URL's printed up all over kingdom come, and then one
day I decide to charge for it, but they feel its too expensive, they
will be trapped in all the printed advertising that they have invested
in. That's real unfair to them. So if I am going to charge for this,
I should decide now what to charge for it and forever more hold my
peace on the matter.
The next question is how much is this service really worth to
people? For example is it worth a $100 setup fee? Is it worth
$20/month on top of their other charges?
In the end it is merely vanity and convenience that people want
this service anyhow, is it really going to increase their sales any to
have it, and to not have to put the silly little /homer at the end of
their URL?
If people are not willing to pay for it, I have to look at how
much time and resources of my own that it takes up. I don't mind
giving value added services for free, it keeps me ahead of the
competition, but this matter of dwindling IP numbers has me a bit
worried.
Charging people a stiff up front free or a monthly charge would
chase off the frivolous users, who are quite happy to simply have an
aliased domain with the /homer at the end of their URl, and leave
those who really think it will enchance their sales enough to justify
the costs. That would certainly go a long ways towards increasing the
longevity of my IP address space.
For the moment the service is free while we work on the rest of
our Virtual Domain Package, but buyer beware.
Homer
lightlink.com IN A 205.232.34.1
artmatrix.com IN A 205.232.34.1
lightlink.com IN A 205.232.34.1
artmatrix.com IN A 205.232.34.2