Who's Who and Where
Aside from the basic functionality of an MTA, there are certain design decisions that can affect future expansion of your messaging system. Specifically, the addressing schemes that you employ may help or hinder your users' use of e-mail as well as affect your management of the system. Essentially, addressing schemes need to add to individual mail accounts rather than detract. For example, John Doe's e-mail address should either tell you more about John Doe or at least clearly indicate that the particular e-mail address is his. How to structure your addressing scheme also goes hand in hand with other elements of your network.
The most obvious information provided by an e-mail address is the first and last name of a person. Most often, addresses are composed of some portion of both the first and last names. John Doe's e-mail would be "jdoe@somewhere.com,""johnd@somewhere.com"
or perhaps "john.doe@somewhere.com."
In addition to setting up addresses, you will need to configure your DNS server. MX (Mail Exchange) records indicate which host on your network is the MTA. When a mail message is sent, the MTA looks up the MX record for the right half of the mailing address. For a message to 'jdoe@machine.somewhere.com' the MTA would look up the DNS information for 'machine.somewhere.com.' If that host name has no MX portion of its DNS record, then the MTA will attempt to deliver the message directly to that address. For an administrator, the thought of having one MTA at every client machine is unacceptable. By using an MX record for 'machine.somwhere.com,' incoming messages for 'jdoe@machine.somwhere.com' can be redirected to the appropriate machine.
Instead of having many heterogeneous host names, we can have one single domain server for all e-mail accounts at a site. For example, 'jdoe@machine1.somwhere.com' and 'gyerxa@machine2.somwhere.com' would become 'jdoe@somwhere.com' and 'gyerxa@somwhere.com.' Instead of each DNS record having its own MX portion, we can provide the entire domain with only one MX record indicating the appropriate host for all incoming mail. This idea can be expanded to incorporate many smaller domains instead of one larger companywide "virtual" domain.
Virtual domains are used to hide the machine information of the server hosting the mail services. If my main mail server's name was "badname.corp.com", I may not want all corporate email addresses to contain the domain "badname.corp.com". To avoid this I could create a virtual domain such as "corp.com" and direct mail traffic to the "badname.corp.com" machine. This is accomplished by using a combination of DNS and MX records or multihoming IPs and associated domain names to a single machine. The basic idea is the same, to hide information about the mail server from the end user.
For example, company A has four different 100-user departments large enough to have their own e-mail
domains. Domains could be created for each department indicating the department each person worked in. Of course, to make use of virtual domains, your MTA or mail server must support them. Eudora WorldMail, ISOCOR N-Plex and Control Data Systems Rialto servers each support multiple virtual domains for e-mail users. When considering a larger corporatewide messaging solution, the use of virtual domains can make management a snap.
Gregory Yerxa is an assistant NetWare administrator for the Computer-Aided Engineering Laboratory at the University of Wisconsin-Madison. He can be reached at yerxa@cae.wisc.edu.
Print This Page
E-mail this URL
|