++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++ sendmail-virtuals-FAQ.txt ++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Some ramblings on the subject of E-Mail Virtual Domains... Date: Thu, 2 May 1996 19:08:44 +0200 (MET DST) From: Leif Erlingsson To: Mark Subject: Have been `hiding my head in the sand' a couple of days ... and not even fetched my mail for two days! Practically unheard of! :-) I just looked to see if there was anything urgent, and as there isn't, I'll go back to what I was doing, which is serious sendmail hacking! I'm working in parallel for all sendmail environments I'm concerned with. I'm updating the general status of all config files, with Virtual Domans (already in there) and full support for reverse aliasing together with Virtual Domans AND normal masquerading for domains not xaliased to by anyone. This requires some slight enhancements of the m4 source, to /usr/site/mail/cf/m4/proto.m4, as well as to the site-specific configuration files ( /usr/site/mail/cf/domain/dispatch.m4 and /usr/site/mail/cf/cf/ dispatch.mc for dispatch ). Plus a new version of my xaliases(8) script. You will not see these updates on dispatch until it's all good and ready, as well as well tested. What I am implementing is everything documented in the Virtual Domains mail I sent You, this is already a fact, but more: I will support, using xaliases, individual masquerading for users with reverse aliases in the /etc/xaliases file (that's those entries that end up in /etc/generics when xaliases is run). When all this is used in combination with a few Unix special accounts using procmail recepies to work mailbot's, the result is that ONE SINGLE COMPUTER - dispatch - or a Pentium maybe - can act as any number of domains on the Internet that it is MX'ing and receiving and/or forwarding mail for and each of these domains can have their own mailbot's, masquerading as that domain. You can have, info@company.a.com info@company.b.com info@company.c.com info@company.d.com that each reply automatically to the person sending the mail with a menu + forwarding the original mail to different people, like nfo@company.a.com --> forward to eric@some.com nfo@company.b.com --> forward to 1234@aol.com nfo@company.c.com --> forward to 5678@aol.com nfo@company.d.com --> forward to 9012@aol.com or something different. Each recepie can be custom tailored. That would be a source of income, right? One recepie might just log the E-Mail addresses of those who mailed, mailing the result once a week to the responsible person somewhere. The possibilities will be infinite. __________________________________________________________________ Leif Erlingsson Tel +46 8 604-0995 DATA LEGE Fax +46 8 605-2551 Glavagatan 33 URL http://www.lege.com 123 71 Farsta, Sweden Email mailto:leif@lege.com __________________________________________________________________ I remember the past. I am not doomed to buy Microsoft products. Mon Nov 17 1997 comment: http://www.lege.com/proto.html links to current patches, making cf/m4/proto.m4 generate sendmail.cf's with better virtual domain support than the latest sendmail-8.8.8 does as standard. As of this writing, the following versions of sendmail are supported: sendmail-8.8.8, sendmail-8.8.7, sendmail-8.8.6, sendmail-8.8.5, sendmail-8.8.4 and sendmail-8.7.3. It is also highly recommended that you obtain http://www.lege.com/xaliases-2.0.tar.gz.bin for the xalparse and xaliases programs and configuration files. / Leif Erlingsson The Virtual Domains document: __________________________________________________________________ Date: 13 Nov 1995 14:39:15 -0500 From: "Homer W. Smith" Newsgroups: comp.mail.sendmail Subject: Sendmail V8 Virtual Domains ART MATRIX - LIGHTLINK PO 880 Ithaca, NY 14851-0880 (607) 277-0959 Voice (607) 277-8913 Fax (607) 277-5026 Modems homer@lightlink.com E-mail jes@lightlink.com E-mail 09/07/95 8:12pm Copyright (C) 1995 Homer Wilson Smith Redistribution rights granted for non commercial purposes. I want to thank Robert Sanders 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/providers where the patch lives along with some great other patches. 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 One can (and probably should) instead place this line in one's original sendmail.mc file like so near the bottom. LOCAL_CONFIG Kmaildomains hash /etc/out.db Once can place any options there one wishes to be part of the final sendmail.cf file. For example, Thomer <-- Trusted user Opauthwarnings,noexpn,novrfy 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)dnl LOCAL_CONFIG Kmaildomains hash /etc/out.db Thomer Opauthwarnings,noexpn,novrfy LOCAL_RULE_0 R$+ < @ $+ . > $: $1 < @ $2 > . R$+ < @ $+ > $* $: $(maildomains $1@$2 $: $1 < @ $2 > $3 $) R$+ < @ $+ > $* $: $(maildomains $2 $: $1 < @ $2 > $3 $) R$+ < @ $+ > . $: $1 < @ $2 . > MAKE SURE THE LEFT HAND SIDE AND THE RIGHT HAND SIDE ARE SEPARATED BY AT LEAST ONE TAB!!!! SPACES ALONE WON'T WORK! OK, so do it in this order. Add the K line into your sendmail.mc file. Add the rule lines to your sendmail.mc file, and then m4 it 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 -- ------------------------------------------------------------------------------ Homer Wilson Smith ART MATRIX FRACTALS homer@lightlink.com Posters, T-shirts, Videos (607) 277-0959 http://www.lightlink.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++ END OF sendmail-virtuals-FAQ.txt ++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++