The Internet Message Transfer Agent (IMTA) routes, transports, and delivers Internet mail messages for SIMS.

Topics in this chapter include:

Overview of IMTA

IMTA structure

Email message structure

IMTA directory cache

Address rewrite rules

SMTP Authentication

Controlling SMTP email access

Distribution lists

Overview of IMTA

The Internet Mail Transport Agent (IMTA) is a general-purpose, store-and-forward system for distributing computer-based mail. The term store-and-forward means that the IMTA automatically handles the receiving of mail messages necessitated when network links or services are temporarily unavailable. In contrast to mail user agents (MUAs) such as Netscape Messenger or Microsoft Outlook, which are used to create and read electronic mail messages, IMTA is a mail transport agent (IMTA) responsible for directing messages to the appropriate network transport and ensuring reliable delivery over that transport.

The IMTA provides a uniform distribution environment that can be interfaced to multiple mail user agents (MUAs), networks, protocols, and transport mechanisms. As this interfacing, from the user's point of view, is accomplished transparently, the IMTA presents to the user a homogeneous mail network; that is, the IMTA blends heterogeneous mail networks into a single, coherent mail system.

IMTA Structure

One analogy for the IMTA is that it performs for email messages what a central transportation transfer station performs in a city. That is, passengers in a city may come in to a station by using different way of transportations--by foot, road, subway, railroad, by air. Over some of these transports there may be alternate protocol possibilities, for instance, taxi cabs, buses, and cars travel over roads. Another example is that commercial airlines and private airplanes provide variant forms of air travel. Depending on each passenger's destination, the passenger departs by way of an appropriate transport and protocol to get him to his next destination.

In the context of electronic mail, protocols are generally a high-level (not necessarily network specific) language spoken between two mailers. Transports are the low-level, network specific details used to implement a protocol on a given network.

Thus email messages may come in to the IMTA by any one of a variety of transports and protocols--submitted directly by a local user, via TCP/IP as an SMTP message from an Internet system, by using a dial-up modem using the PhoneNet protocol, DECnet as a MAIL-11 message, DECnet as an SMTP message, UUCP, an X.400 transport, SNA, and so on. The IMTA then routes the message out using a transport and protocol appropriate for the message's destination address.

Note that the IMTA not only serves as a mechanism for sending and receiving mail, but also serves as a centralized switching yard or gateway for routing and rerouting mail traffic between multiple network transports. The use of the IMTA as a mail gateway allows the IMTA host to provide electronic mail access through its network facilities for other, less capable machines.

The Transportation Methods--IMTA Channels

The IMTA uses what are called channels to implement specific combinations of transports and protocols. Each different transport and protocol combination has an associated IMTA channel. The IMTA postmaster initially configures the IMTA telling it what sorts of transports and protocols are in use at his site, and what sorts of destination addresses should be routed through which sorts of channels. For instance, at sites with an Internet connection, Internet addresses are normally routed through an SMTP over TCP/IP channel; but at sites with only a UUCP connection, Internet addresses would instead be routed through a UUCP channel. Once the IMTA is so configured, the IMTA handles message routing and delivery automatically--ordinary users need never be aware of this underlying transport and routing; that is, they simply address and send their messages and the IMTA automatically routes and delivers them appropriately.

The Layout of Transportation Routes--The IMTA Configuration File

The IMTA's main configuration file, the imta.cnf file, contains the fundamental IMTA configuration information for a site, the information about what sorts of transports and protocols are in use (the IMTA channel definitions), and the information about which destination addresses should be routed through which channels (the IMTA rewrite rules). The IMTA configuration file is discussed in the IMTA Configuration chapter of the Sun Internet Mail Server 4.0 Reference Manual.

The IMTA configuration file thus contains a site's layout in terms of transports and protocols and which destinations are reachable via what transports: akin to the physical layout of railroad tracks, bus lines, airline routes, and so on for a transportation transfer station in a city.

Arrivals Trigger Activity--IMTA Channels Run on Demand

There is also the issue of scheduling: when do messages arrive and when are they delivered (when do the trains, buses, airplanes, and so on arrive and depart)?

For incoming messages, in most cases, the underlying transport is simply configured to hand the messages over to the IMTA immediately whenever they come in. The IMTA is passive or data driven, waiting for the messages, which may come in at any time. For some protocol and transport combinations, the component of the IMTA that awaits incoming messages for that protocol and transport combination is implemented as a server; for instance, to listen for and receive incoming SMTP over TCP/IP messages, the IMTA includes an SMTP server. In other cases, for some transports where the transport itself is not able to actively hand the messages over to the IMTA, the IMTA is configured to periodically poll the sending side and ask for incoming messages.

Since the IMTA is data driven, when an external source submits a message into the IMTA, the receiving IMTA channel processes the message to check where the message is destined and then hands the message over to the appropriate outgoing channel and triggers the outgoing channel to itself run in turn. (In a message with multiple recipients, the receiving channel hands the message over to multiple outgoing channels and triggers each of the outgoing channels to run.) In particular, note that for outgoing messages, by default the IMTA normally always makes an immediate attempt to deliver each message.

To recapitulate, the physical transportation transfer station analogy above in the IMTA the normal scheduling of outgoing message deliveries is on-demand and immediate--it is rather as if each new passenger could get their own railcar or airplane with immediate departure.

Delivering the Passengers--The Execution of IMTA Channel Processing Jobs

The execution of the incoming direction of an IMTA channel may occur in a user's own process (as for messages submitted by local users on the IMTA system), as an IMTA server process running (as for incoming SMTP messages), or as an IMTA channel job triggered in some other way. The receiving channel immediately triggers the execution of a subsequent channel job to perform the next step of delivery of the message, and these subsequent jobs triggered by the IMTA itself run in the IMTA processing queues. The IMTA processing queues are controlled by the IMTA Job Controller, which has its own configuration options. Configuration of exactly how and when channels run in processing queues can be used to control characteristics of the IMTA operation.

The Waiting Room--The IMTA Queue Area on Disk

While messages are awaiting processing and delivery by the IMTA, they are stored as message files on disk in the IMTA queue area for the destination channel.

Delivery Retry Attempts

The IMTA is a store-and-forward message system. If the IMTA's attempt to deliver a message encounters a temporary failure condition, then the IMTA stores the message and later attempts another delivery. There are IMTA periodic jobs that run every so often re-attempting delivery of not yet delivered messages. Eventually, if a message still cannot be delivered after repeated attempts, the IMTA periodically returns (bounces) the message back to the sender. How long the IMTA keeps trying to deliver messages is of course configurable.

Types of Operations

IMTA performs five different operations:

Layout--The IMTA configuration describes how the IMTA should handle messages and addresses and message content.

Receiving Messages--IMTA servers or incoming channel jobs receive messages. In general, the IMTA is data driven. The IMTA waits, listening for external agents to submit messages whenever they wish.

Processing Outbound Messages--The IMTA channel jobs running in the IMTA processing queues deliver outbound messages. Note that a job in an IMTA processing queue may be either an immediate delivery job, or a periodic job re-attempting delivery of not-yet-delivered messages.

Scheduling of Delivery Retries and Polling--For messages that do not get delivered upon first attempt, a periodic delivery job periodically attempts another delivery. Note that periodic jobs are a backup to the normal immediate delivery attempts.

Message Storage--The IMTA queue area is where message files are stored while being processed and awaiting delivery.

Email Message Structure

Most IMTA messages are stored as text files. Messages with multiple parts (possibly containing different types of data) are represented as a series of text sections separated by special unique delimiter strings.

Briefly, the key items in each message file are:

The message envelope. The first records in the file contains message envelope (that is, transport) information.

The envelope is terminated either by a line containing a boundary marker, or by a line containing two CTRL/A characters.

The header lines of the message follow the envelope. Their format is mandated by RFC 822.

There may be any number of message header lines; the message header formed by this collection of header lines is terminated by a single blank line after which follows the message body.

The message is terminated by a boundary marker matching the boundary marker at the beginning of the message, (or by a sequence of five CTRL/As if the message start was indicated using CTRL/As).

For messages that had transient delivery failures information about retrial would go here.

---

Note - Sun reserves the right to change this format in future releases of the IMTA. User written applications that either read or write queued IMTA message files should make use of appropriate IMTA library routines. Use of the IMTA SDK will insulate user applications from any future message format changes. For complete information on message envelopes and headers, respectively, refer to RFCs 821 and 822.

---

Message Envelope

The IMTA uses the contents of the envelope to make routing decisions. It does not use the content of the message. The content of the envelope is primarily defined by RFC 821. It includes the originator address, the recipient(s) address(es), and envelope ID. The IMTA supports additional envelope information related to SMTP service extensions published after RFC 821 such as notary (the ability to specify requested Delivery Status Notification for each recipient, see RFC 1891) and original recipient addresses.

Message Headers and Contents

RFC 822 defines a message as headers and contents.

Message Headers

An Internet mail message starts with one or more headers. Each header is composed of a field name followed by a colon then a value. Values can be generated by the composer of a message, the mail client, and MTAs. Headers contain the following types of information about the message:

Delivery information (for example, TO, CC, BCC, From, reply-to, in-reply-to)

Summaries of the content (for example, subject, keywords, comments).

Information that enables tracing of a message if problems occur (for example, message-ID, references, received, return-path).

Information specific to the Multipurpose Internet Mail Extensions (MIME). For more information on MIME and MIME-specific headers, refer to Message Content/MIME.

RFC 822 defines several headers. Not all defined headers need to be present in a message. In fact, only a few headers are required for any type of message.

The administrator of a mail client can construct a template of desired headers that the composer of a new, forwarded, or replied-to message fills in. The following is an example of a simple template of headers for a new message:

To:
Subject:
Date:
Cc:

The mail client can automatically generate some headers (From, reply-to, message-ID, and references).

Before the message is submitted to the IMTA, the mail client can add a date header. If the From header contains multiple email addresses or if the email address is different than the submitting mail client, then the sender header is added.

An IMTA can also add headers to a message. Each IMTA that accepts a message adds a received header to that message. The last IMTA to accept the message and to actually deliver the message to the message store adds a return-path header. The received and return-path headers provides information that enables you to trace the routing path taken by the message if a problem occurs.

Message Content/MIME

A blank line separates the headers and the content or body of the message. The content or body of the message provides the data that the originator of the message intends to transmit to the recipient.

SIMS supports Multipurpose Internet Mail Extensions (MIME). Whereas RFC 822 is limited to handling text messages of a single body part, MIME extends RFC 822 to handle multiple body parts.

Therefore, the content of a message can include text as well as images, audio, video, and binary or application-specific files. The text included in the message content has the following characteristics:

Unstructured or structured

Unlimited line length or overall length

Non-ASCII character sets, which allows non-English language text

Multiple fonts

If included, the images, audio, video, and binary or application-specific files appear as attachments.

MIME defines the following headers that can appear at the start of an Internet mail message:

MIME-version--Specifies a version number to indicate that a message format conforms to the MIME standard.

Content-type--Specifies the type or subtype of data in the content or body of a message. Possible values include the following:

Text--Indicates data that is principally text.

Multi-part--Indicates a message consisting of multiple body parts, each having its own data type.

Application--Indicates either application or binary data.

Message--Indicates an encapsulated message.

Image--indicates still image (picture) data.

Audio--Indicates audio or voice data.

Video--Indicates video or moving image data, possibly with audio as part of the composite video data format.

Content-transfer-encoding--Specifies how the data is encoded so that the data can traverse Internet Message Transfer Agents (IMTAs) outside of the SIMS email system that may have data or character set limitations.

Content-ID--Specifies an ID for a message content or body.

Content-description--Text that provides descriptive information about the message content or body.

For complete information on MIME, refer to RFCs 1521, 2045, 2046, 2047, 2048, and 2049.

IMTA Directory Cache

The delivery and routing of messages by the Internet Message Transfer Agent (IMTA) is based on the user and group (distribution list) entries stored in the directory service. The IMTA needs to access the directory information for each message that it processes. Rather than querying the directory service each time it processes a message, the IMTA caches the directory information, or takes a snapshot of the directory information and stores it, and accesses directory information in the cache. The IMTA implements the cache for the following reasons:

Performance--Performing a directory query for each recipient of each message is time-consuming and puts a large load on the mail server.

Data formatting--The information stored in the directory service is not always in the format needed by the IMTA. When creating the cache, the IMTA reformats the directory information.

The directory information stored in the directory service is continuously updated. As a result, the directory information in the IMTA-directory cache must be updated periodically with the current directory information in the directory service or synchronized. Two types of synchronization are supported:

Full synchronization--The existing cache is replaced with a new cache, completely rebuilt with the current user and group entries from the directory service. After the synchronization occurs, the IMTA configuration file is rebuilt then the IMTA is automatically restarted.

Incremental synchronization--The existing cache is updated with user and group entries that were created or modified since the last full or incremental synchronization. The IMTA is not restarted.

TABLE 7-1 outlines the updates to the IMTA-directory cache that are and are not performed during a full synchronization and an incremental synchronization.

TABLE  7-1   Updates Performed During Full/Incremental Synchronizations 

IMTA-Directory Cache Update	Performed During Full Synchronization?	Performed During Incremental Synchronization?
New user entries added	Yes	Yes
Modified user entries updated	Yes	Yes
Deleted user entries removed	Yes	No
New members added to existing distribution lists	Yes	Yes
Deleted members removed from existing distribution lists	Yes	Yes
Modification of access control info	Yes	No
New distribution lists added	Yes	Yes
Deleted distribution lists removed	Yes	Yes

Address Rewrite Rules

When a message enters an Internet Message Transfer Agent (IMTA) channel, it must be placed in the correct channel queue and subsequently routed to the correct destination for delivery. The domain rewriting rules (from this point forward called the rewrite rules) are a set of tool that the IMTA uses to route messages to the correct host. Rewrite rules perform the following functions:

The following sections walk you through the rewrite rule process. They also discuss the following elements of the rewrite rule itself:

Pattern--A string composed of ASCII characters that the host/domain specification can potentially match

Domain template--A template that defines how the host/domain specification is rewritten

Routing system--The destination channel

Controls--Sequences that impose conditions to the applicability of a rewrite rule.

The address may be returned as one of the following:

If the address returned is jdoe@sims-ms.myhost.bridge.net, the domain part matches a rule whose routing system is that of the message store channel. The message is then queued to the sims-ms channel and delivered to the store by the channel's master program.

If the address returned is jdoe@myhost.bridge.net, the domain part matches a rule in the l (local) channel section. If the address matches the address previously looked up in the alias table, the destination channel is set to l (/var/mail) and the message is enqueued. If it does not match, the same operation is reiterated until it stabilizes on one address, the limit of the alias lookup is reached, or a self reference (a:b, b:c, c:a) is found. In the last two cases, the address is not resolved, which causes the messages to be bounced (unknown user error message). The alias lookup default is 10. This value can be changed by configuring the MAX_ALIAS_LEVELS option in the option file.

If the address returned is jdoe@host2.bridge.net, the domain part matches a rule in the Intranet SMTP channel section and the message is enqueued to the tcp_local channel (intranet channel), and so on.

If the string jdoe does not match anything in the alias cache, the message is returned to the originator with the "user unknown" error.

Extracting the Host/Domain Specification of An Address

When a message enters a channel, all addresses on the envelope and in the message header are examined and the host/domain specification of the address is extracted. The host/domain specification is the part of the address that is to the right of the at (@) sign. For example, in the address john@stream.bridge.net, stream.bridge.net is the host/domain specification.

Matching Host/Domain Specification with a Rewrite Rule Pattern

The channel scans for a match between the extracted host/domain specification and the pattern portion of the first rewrite rule in the list. (The channel scans the host/domain specification from left to right--for example, starting with corp, then bridge, then net--and the rewrite rules list from top to bottom.) If a match is not found in the first rule, the channel scans the next rule and so on. If a match is found, the host/domain specification is rewritten per the domain template of the rewrite rule. If a match is not found, the message is returned to the sender.

TABLE 7-2 outlines the types of rewrite rule patterns that your rewrite rule list can potentially contain and the order in which each type of pattern is scanned when the input address is joe@sc.cs.bridge.net. The rewrite rule pattern types are listed in the order in which the pattern is scanned.

TABLE  7-2   Rewrite Rules Pattern Types

Example of Pattern Scanned For	Explanation
sc.cs.bridge.net	matches sc.cs.bridge.net only
*.cs.bridge.net	matches <any one token>.cs.bridge.net only
.cs.bridge.net	matches <multiple tokens>.cs.bridge.net only
*.*.bridge.net	matches <any one token>.<any one token>.bridge.net only
.bridge.net	matches <multiple tokens>.bridge.net only
*.*.*.edu	matches <any one token>.<any one token>.<any one token>.edu only
.edu	matches <multiple tokens>.edu only
*.*.*.*	matches <any one token>.<any one token>.<any one token>.<any one token> only
.	matches anything

---

Note - Your channel does not necessarily contain a rewrite rule and, subsequently, a rewrite rule pattern for each of the patterns described in TABLE 7-2. However, if your channel does contain a rewrite rule for each of the described patterns, then TABLE 7-2 outlines the default order in which each pattern is scanned for until a match is found. That is, in whatever the order the rules are written, they are scanned from most specific to least specific.

---

The rewrite rule list for a channel can include multiple rewrite rules containing the same pattern but different domain templates and control sequences. You can reconfigure the order of these types of rewrite rules so that the channel scans these rules in the reconfigured order. This features enables you to fine-tune the rewrite rule list with your preference as to how the domain/host specification in these types of rules is rewritten. You cannot reconfigure the basic order in which the rewrite rules in TABLE 7-2 are scanned.

To illustrate how the host/domain specification and rewrite rule matching process works, if the extracted host/domain specification is zoo.bridge.net and the eng.bridge.net and *.bridge.net patterns are defined in the rewrite rules, then a match would result after the second scan with *.bridge.net.

Rewriting the Host/Domain Specification

If a match is made between the host/domain specification of an address and the pattern portion of a rewrite rule, the host/domain specification is rewritten according to the domain template portion of the rewrite rule.

The domain template defines how the host/domain specification is rewritten. The template defines how to rewrite the domain port. It does that either statically or dynamically depending on the domain.

Mapping a Rewritten Address to a Destination Channel

The last element of a host/domain rewrite rule is the routing system or destination channel in whose queue a message should be placed for delivery.

Rewrite Rule Controls

By default, a rewrite rule is scanned for all header and envelope addresses. It is possible to specify that a given rule applies to a subset of all the addresses. For example, a rule can search for some combination (AND) of the To:, From:, CC:, and Bcc: header addresses and the envelope recipient addresses (RCPT TO). Additional filters (control sequences) are available and are documented in the un Internet Mail Server 4.0 Reference Manual.

Default Channel Rewrite Rules

During installation of SIMS, the system generates default rewrite rules for each of the installed channels. You can modify some of the default rewrite rules or add new rewrite rules for each of the installed channels using the Rewrite Rules section in the IMTA property book of the Administration Console.

Adding and Reconfiguring Rewrite Rules

The Administration Console enables you to add a rewrite rule to an existing or newly created channel. It also enables you to delete or modify an existing rewrite rule associated with an existing channel.

SMTP Authentication

The SIMS SMTP authentication feature allows only password authenticated users to perform SMTP relaying. That is, only users with accounts and passwords in the SIMS directory can use the SMTP relaying mechanism. This prevents anonymous spammers from using the SMTP relay to send UBE.

RFC 2554 defines an extension of the SMTP protocol which provides the ability to authenticate clients and server. It uses the SASL (Simple Authentication and Security Layer) framework defined in RFC 2222. This functionality is commonly known as SMTP AUTH, owing to the AUTH command added to SMTP as part of this extension.

Background and Terminology

An authentication mechanism is a particular method for a client to prove its identity to a server. APOP, PLAIN and KERBEROS4 are examples of authentication mechanisms. SIMS initially supports only the PLAIN SASL mechanism. More mechanism are like likely to become supported ones in a near future. The PLAIN SALS mechanism is defined in

http://search.ietf.org/internet-drafts/draft-newman-tls-imappop-09.txt

An authentication verifier (for example, a password) is stored on the server and contains information used to verify a user's identity. The format of the authentication verifier may restrict which mechanisms can be used. The term authentication verifier is preferred in place of password, because while passwords are the most common instance of authentication verifiers, an authentication verifier could also be something like a certificate in an LDAP directory; usually, however, you may think password wherever you see authentication verifier.

An authentication source is a file, database, or interface to an LDAP directory, where the authentication verifiers for users are stored. The authentication source must be accessible to the server. SIMS uses the user passwords stored in the LDAP directory as its authentication source.

SASL is a framework for adding different authentication mechanisms to Internet protocols such as POP, IMAP, and SMTP. When the connection is opened, the POP, IMAP, or SMTP client may authenticate itself to the respective server.

Controlling SMTP Email Access

An individual can intentionally or inadvertently overwhelm your mail server by flooding it with messages. This type of act is called a denial of service attack. If a denial of service attack is perpetrated against your mail server, either there may be a substantial impact to the throughput of your mail server or your mail server will become overloaded and nonfunctional.

SIMS provides features that enable you to minimize the possibility of a denial of service attack as well as help you control spam (unwanted or unsolicited email):

Email access restrictions--Enables you to specify which incoming messages are accepted or denied based on recipient or originating domain, client IP address, server IP address, or originating email address.

Message size limits--Enables you impose a limit at which a message is deemed too large and rejected by a channel.

Distribution Lists

The directory service stores and manages distribution lists as group entries. Each group entry is composed of attributes, for example, distribution list name, members, and so on. For example, imagine that the widget team of the Bridge Corporation is:

Jane: jane@eng.bridge.net

Bernie: bernie@eng.bridge.net

Kevin: kevin@eng.bridge.net

Amy: amy@eng.bridge.net

Frank: frank@eng.bridge.net

You can configure a distribution list composed of each widget team member's email address along with the associated email address widget@eng.bridge.net. In addition to distribution list members, you must also configure a distribution list owner. An owner is an individual who is responsible for the distribution list. An owner can add or delete distribution list members.

You can optionally configure a distribution list moderator. A moderator is an individual, usually the distribution list owner, who initially receives a message addressed to a distribution list. Upon receipt of a message, the moderator can forward the message to the distribution list, edit the message and then forward it, or not forward the message.

You can specify distribution list Access Control; that is, what domains and users can or cannot distribute mail to the group. By default, if a moderator is created, only the moderator can send mail to the group and all other submissions go to the moderator. If no moderator is specified, then anyone can send mail to all the group members.

The Send Error Conditions To field enables you to specify an individual to receive a message if an error condition with a distribution list arises. An example of an error condition is when a message addressed to the distribution list cannot be delivered. Upon receipt of one of these messages, it is the specified individual's responsibility to notify the email administrator about the error. (You can specify the email administrator as the recipient of these messages.)

The Send Request Messages To field enables you to specify an individual to receive messages containing requests to be added as a distribution list member. Upon receipt of one of these messages, it is the specified individual's responsibility to notify the email administrator about adding the requestor as a distribution list member. Requests are sent to <list name>-request@domain. (As with the Send Error Conditions To field, you can specify the email administrator as the recipient of these messages.)

If you don't configure the Send Error Conditions To and Send Request Messages To fields, then by default, the individual who is configured as the owner of the distribution list will receive the respective messages.

Distribution List Process

The Internet Message Transfer Agent (IMTA) retrieves the group entry attributes from the directory service (via the IMTA-directory cache) when it processes a distribution list. The distribution list process is composed of the following phases:

Routing if necessary

Address processing

Message expansion

Routing or delivery

Imagine that the Bridge Corporation employee Steve, who is in the finance department, sends a message to distribution list widget@eng.bridge.net. The widget distribution list is composed of a group of fellow Bridge Corporation employees, who develop widgets in the engineering department.

The first phase in the distribution list process applies only to email systems that contain multiple mail servers and therefore IMTAs. If your email system has only one IMTA, then this phase does not apply. The IMTA that accepts Steve's message determines if the distribution list widget@eng.bridge.net is stored as a group entry on this particular mail server. If not, the IMTA checks its data base to determine which IMTA in the email system stores this particular group entry. If the IMTA finds this information in its data base, the message is routed to the appropriate IMTA. If the IMTA does not find the information in its data base, the message is routed to the IMTA configured as the router or smart host in that particular domain. Once the message is accepted by the mail server that stores the group entry for widget@eng.bridge.net, the IMTA processes each distribution list member's address (rewrite rules, access control, and so on).

The IMTA then expands the message or converts the message into enough copies for each distribution list member. Rather than converting the message into one copy per distribution list member, the IMTA converts the message into one copy per IMTA channel that will deliver or route the message to a distribution list member. For example, if two distribution list members have mailboxes in /var/mail and two in the Sun message store, the IMTA will convert the message into two copies: one for the /var/mail channel and one for the Sun message store channel.

The IMTA then places a copy of the message in the queue of each IMTA channel that will deliver or route the message to a distribution list member.

Distribution Lists can be configured to accept or reject messages from certain users or domains. The detailed access control for this is explained in the Sun Internet Mail Server 4.0 Reference Manual.

Access Control

The Sun Internet Mail Server supports a distribution list access control feature. If you do not implement the access control feature, any email user who knows the email address can send messages to a particular distribution list.

The access control feature enables you to configure who can send messages to a particular distribution list, thereby controlling the quantity of messages as well as the quality of information that can be sent to a distribution list. You can control access to a distribution list in the following ways:

Submitter--You can specify a list of submitters (users or groups) who are authorized to send messages to a particular distribution list and/or a list of submitters (users or groups) who are unauthorized.

Domain--Specify a list of domains authorized to send messages to a particular distribution list and/or a list of domains that are unauthorized to send messages to a particular distribution list.

You can specify submitters who are within the email system that you are configuring or in a different email system. The four possible configured access control lists are examined in the following order:

FIGURE 7-1 shows the access control process.

FIGURE  7-1 Distribution List Access Control Process

If a conflict arises between your configured unauthorized or authorized access control lists, the restriction configured in the submitter list will take precedence over the restriction configured in the domain list. For example, imagine that submitter steve@finance.bridge.net attempts to send a message to the distribution list widget@eng.bridge.net. If the domain finance.bridge.net is on the unauthorized domain list but user steve@finance.bridge.net is on the authorized submitter list, then the message will be delivered because of the precedence of the submitter lists over the domain lists.

TABLE 7-3 contains various ways that you may want to use the distribution list access control feature and the suggested way to achieve the results you want.

TABLE  7-3   Implementing Distribution List Access Control Feature

Restrictions/Allowances You Want to Impose	Suggested Method of Implementing*
Restrict all submitters from a particular domain from sending messages	Enter unwanted domain on unauthorized domain list.
Allow all submitters from a particular domain to send messages	Enter domain on authorized domain list.
Restrict one or more submitters from a particular domain from sending messages and allow all other submitters in the domain to send messages	Enter unwanted submitters on unauthorized submitter list. Enter the domain itself as authorized domain.
Allow one or more submitters from a particular domain to send messages and restrict all others from sending messages	Enter submitters in the authorized submitter list. Enter the domain itself in the unauthorized domain list.
Restrict one or more submitters regardless of domain from sending messages	Enter unwanted submitters in the unauthorized submitter list.
Allow one or more submitters regardless of domain to send messages	Enter submitters in the authorized submitter list.
Restrict submitters to distribution list members only.	Enter distribution list name in the authorized submitter list.

* Although each restriction/allowance outlined in this table can be handled in multiple ways, the documented suggested methods are the most efficient and require the least impact on performance. For example, you can restrict all submitters from a particular domain from sending messages by entering the unwanted domain on the unauthorized domain list or by not including the unwanted domain on the authorized list and having other authorized entries. However, if you restrict this domain by the latter method, the mail server has to go through two steps in the distribution list process rather than one. Therefore, the latter method is not suggested.