FIGURE  5-1 Internet Mail Transport Agent (IMTA) Property Book

Each section displays configurable attributes of a particular IMTA property. The IMTA pull-down menu allows you to start or stop the IMTA as well as save or restore IMTA configuration. The Create pulldown menu allows you to create new channels. The Selected pull-down menu allows you to view a channel's properties; start, stop and delete channels; and monitor the message queue.

IMTA Topics and Tasks

TABLE  5-1   Message Transport Topics and Tasks 

Topic/Task	Description	Page
IMTA Maintenance Tasks	Stop, start, and restart the IMTA. Also backup and restore of IMTA configuration.	83
Monitoring Channel Status	View the operating status of the SIMS channels	85
Alternative Delivery Programs	Provide user access to alternative delivery programs.	86
Alias Synchronization Schedule	Schedule when the IMTA directory cache is incrementally or fully updated with the latest directory information in the directory service.	87
SMTP Access and Relay Restrictions	Restrict/limit access or delivery of messages from specified email and IP addresses. Unsolicited bulk email control, limiting email access, and so forth.	123
IMTA Location Relative to Public Internet	Specify location of the IMTA relative to the internet, that is, does outbound mail for external addresses have to be forwarded to a smart host?	90
Routability Scope	Specify to whom IMTA can route messages--users, domains etc.	92
Channels	This section and its subsections below describe channel configuration.	93
Configuring Channels	Create channels, channel descriptions; configure SMTP router hosts, set character set labels.	94
Message Limitation	Set message size limitations.	101
Delivery Status Notification	Specify how delivery failure message is handled. Configure language of message.	102
Diagnostics Output	Write master/slave diagnostic output to a log file.	105
To Set Recipient Limitation	Specify the maximum number of recipients for a single message at which message processing is deferred on the SMTP channel.	106
Message Logging	Configure channel so that it logs as each message enters and is removed from the queue.	107
Reassembling MIME Messages	Enable the Sun Message Store channel, /var/mail channel, and pipe channel to reassemble MIME fragmented messages.	108
Rewrite Rules	Add, delete, or modify channel rewrite rules.	109
Monitoring Channel Queues	Monitor accumulated message traffic statistics for each IMTA channel queue.	112
Viewing Enqueued Messages	View a list of the messages currently stored in the channel queue.	116
DNS-based Canonicalization	Using DNS to canonicalize addresses	118
IMTA Error Messages	Appendix D, "Error Messages	331

IMTA Maintenance Tasks

To Stop And Start the IMTA	83
To Restart the IMTA	84
To BackUp and Restore the IMTA Configuration	84

Stopping, Starting, and Restarting a Channel or the IMTA

You may need to stop and start, or restart a channel if you reconfigure an attribute of a channel, so that the reconfiguration takes effect. (Typically, when you reconfigure a channel attribute using the Admin Console, you are prompted to restart the channel.)

The interruption of service incurred when issuing an imta restart is minimal and rarely experienced by user. However, to minimize the probability of affecting users, it is preferable to plan an imta restart during light traffic periods. In general, IMTA channels cannot be restarted, stopped, and started independently. However, IMTA components can be restarted in a selective way.

If the configuration change affects only dequeue operations, use the command
imta restart job_controller so that the enqueue operations are not affected. If the configuration change affects SMTP channel configuration only, the command imta restart smtp should be run. If the configuration change only affects the dispatcher, the command imta restart dispatcher should be run.

To Stop And Start the IMTA

Command: imta-start & imta-stop

AdminConsole>IMTA>IMTA pulldown>Start IMTA

To Restart the IMTA

Command: imta-restart

AdminConsole>IMTA>IMTA pulldown>Restart IMTA

Backing Up and Restoring the IMTA Configuration

After the SIMS is installed, the server saves, or backs up, the IMTA, the Sun Message Store, and the directory service configuration. This configuration version is known as the default configuration. Subsequently, you can back up the latest IMTA configuration (also called the current configuration) at any time. The saved configuration is known as the backup configuration. Doing a backup overwrites the existing backup.

If for some reason you wish to use a previous configuration, you can restore one of the following configuration versions:

Default configuration

Backup configuration (provided that this exists)

To BackUp and Restore the IMTA Configuration

AdminConsole>IMTA>IMTA pulldown>Save Current Config

Monitoring Channel Status

To Monitor Channel Status

85

All channels can be monitored by SIMS. This feature can be helpful in diagnosing various problems.

To Monitor Channel Status

AdminConsole>IMTA>Channels

FIGURE  5-2 Channels Section

Alternative Delivery Programs

Users might want incoming mail passed to a program instead of to their mailbox. For example, users might want their incoming mail sent to a mail sorting program or to an autoreply agent like Vacation Notice. These alternative delivery programs can added to delivery options (see "Optional: Enable the delivery of email to UNIX programs by clicking the Program check box." on page 47) by using the
imta program command (see "To Modify a User Entry" on page 41, Step 7). Alternative delivery programs must, however, conform to the following exit code and command- line argument restrictions:

Exit codes: If the subprocess exits with an exit code of 0 (EX_OK), the message is presumed to have been delivered successfully and is removed from IMTA's queues. If it exits with an exit code of 71, 74, 75, or 79 (EX_OSERR, EX_IOERR, EX_TEMPFAIL, or EX_DB), a temporary error is presumed to have occurred, and delivery of the message is deferred. If any other exit code is returned, then the message will be returned to its originator as undeliverable. These exit codes are defined in the system header file /usr/include/sysexits.h.

Command Line Arguments: Delivery programs can have any number of fixed arguments as well as the variable argument, %s, representing the user name for programs executed by the user or username+domain for programs executed by the postmaster, "inetmail." For example, the following command line delivers a recipient's mail using the program procmail:

/usr/lib/procmail -d %s

To Make Delivery Programs Available to Users

Command: imta-program

These procedures add a delivery program to the User Profile described in "Optional: Enable the delivery of email to UNIX programs by clicking the Program check box." on page 47.

Alias Synchronization Schedule

To Reconfigure the Alias Synchronization Schedule	89
To Disable Full and Incremental Synchronization	90

Rather than performing a directory query for each message that it processes, the IMTA caches directory information that is needed for processing a message. The directory information stored in the directory database is continuously updated. As a result, the directory information in the IMTA-directory cache must be synchronized periodically with the directory information in the directory service. This is called a alias synchronization or dirsync (directory cache synchronization) and can be done with the imta-dirsync command or it can be set up automatically on the Admin Console. (Note that the cache persists and is updated through an incremental or full dirsync.)

The IMTA supports full and incremental synchronizations.

Full synchronization - The existing cache is replaced with a new cache completely rebuilt from information in the directory. After the synchronization occurs, the IMTA configuration file is rebuilt and 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.

User entries - New user entries and modifications to existing user entries. The cache is not updated with deleted user entries.

Group entries - New and deleted members of existing distribution lists and new distribution lists. The cache is not updated with deleted distribution lists or new rules for existing distribution lists. The new distribution list is also updated.

---

Note - Important! You must schedule each IMTA-directory cache in your mail system (master and replicas) to be fully or incrementally resynchronized at the same time. Not doing so could cause routing loops to occur.

---

Cache Synchronization Schedule Planning

By default, the IMTA-directory cache is fully synchronized every day at 2:00 am and incrementally synchronized every ten minutes.

The Admin Console enables you to reconfigure the synchronization schedule. Before reconfiguring this schedule, you must consider the following:

A full synchronization requires that the IMTA be restarted, an operation that is performed automatically. Since restarting the IMTA is a CPU-intensive operation and will temporarily affect the overall mail server performance, Sun recommends scheduling full synchronizations at times when you anticipate that the mail server load is light, for example, during lunch hour or in the middle of the night.

An incremental synchronization does not burden the CPU to the degree that a full synchronization does; in fact, the more often incremental synchronizations are performed, the less it burdens the CPU. However, an incremental synchronization does use CPU cycles and you do not want to schedule this operation more than necessary.

Depending on the number of users (mailboxes) your mail server services, scheduling one to six full synchronizations per day and incremental synchronizations every 5 to 30 minutes is sufficient.

To Reconfigure the Alias Synchronization Schedule

Command: imta-dirsync

AdminConsole>IMTA>Full Alias Synchronization (also Incremental Alias Synchronization)

FIGURE  5-3 Schedule for Synchronizing Aliases Section

To Disable Full and Incremental Synchronization

AdminConsole>IMTA>Full Alias Synchronization (or Incremental Alias Synchronization)>Inactive

IMTA Location Relative to Public Internet

To Configure IMTA Position Relative to the Internet

91

If the IMTA is directly connected to the public Internet (such as on a firewall system), it delivers outbound mail by using the domain part (right-hand side) of the envelope recipient in the DNS and routes accordingly. Conversely, if the IMTA is not connected to the public Internet, outbound mail for external addresses has to be forwarded to a smart host--an SMTP host that can resolve addresses that the current IMTA cannot resolve.

This section describes how to specify the position of the IMTA relative to the public Internet, and how to specify a fully qualified smart host name if the IMTA is not directly connected to the Internet. The routing configuration will differ depending on whether the IMTA is or is not connected to the Internet. Depending on the position you select, the Admin Server will modify the IMTA rewrite rules to reflect that position.

---

Note - Use this option only when the IMTA location relative to the public Internet changes. If the IMTA is connected to the Internet, but you want it to forward outbound mail to a dedicated outbound system, create an additional SMTP router channel to forward mail to this machine, then edit the configuration file imta.cnf to make the "." rule point to the newly created channel. See SIMS Reference Guide for more details.

---

To Configure IMTA Position Relative to the Internet

AdminConsole>IMTA>Position Vs. Internet

FIGURE  5-4 Position versus Internet Section

Routability Scope

To Configure Routability Scope

93

By default, the IMTA is expected to be able to resolve an address of the form user@xzy.com, where xzy.com is the mail domain name. To resolve addresses, the IMTA constructs an alias cache containing all users in the domain xzy.com via alias synchronization.

It might be useful to change the routability scope of the alias cache in the following cases:

When the directory is not populated with the entire domain.

To limit the size of the alias cache.

To enforce routing policies. For example, if all mail going outside of the domain must be forwarded by a specific set of IMTAs.

The routability scope is the group of addresses to which the IMTA can route directly (send directly to the user's delivery mail store) or to which it can deliver locally.

This section explains how to set the routability scope to one of the following:

Mail Server domains - This is the default scope for the IMTA. The IMTA is responsible for everyone in all the domains in the directory for which this IMTA is the mail host.

Nobody - Indicates that the mail server does not support a user community. This setup is typical if your mail server is a backbone IMTA that routes messages between domains. It does not know of each mail user, but uses the host or domain specifications to forward the message to the appropriate mail server for delivery. For example, if a message is sent to user@eng.stream.com, the IMTA knows to forward this message to mailhost.eng.stream.com. Similarly, it can forward a message addressed to user@qa.eng.stream.com to mailhost.qa.eng.stream.com.

Local system users only - The IMTA can deliver messages to local users only. The IMTA cannot deliver to nonlocal users. If a message arrives that is not addressed to a local user (that is, a user whose message store is on this particular server), the IMTA forwards it to a specified smart host without doing an alias table lookup.

---

Note - This option is supported for non-hosted domains only.

---

Modifying the routability scope modifies the way the IMTA persistent alias cache is created and modifies the IMTA rewrite rules.

To Configure Routability Scope

AdminConsole>IMTA>Routability Scope

FIGURE  5-5 Routability Scope Section

Channels

The Channels section enables you to view the status of the IMTA channels. For more information, refer to "Monitoring Channel Status" on page 85. In addition, you can modify the properties of specific channels by double-clicking on the desired channel and bringing up the property book associated with that channel.

Configuring Channels

To Create a Channel	96
To Delete a Channel	97
To Access a Channel's Property Book	97
To Configure a Channel Description	98
To Configure a Router Host	99
To Configure Character Set Labels	100
To Configure Message Limitation	101
To Configure Delivery Status Notification	102
To Configure Report Failures to the Postmaster	104
To Change the Notary Message Locale	103
To Configure Diagnostics Output	105
To Set Recipient Limitation	106
Message Logging	107
Reassembling MIME Messages	108
Rewrite Rules	109
Monitoring Channel Queues	112
Viewing Enqueued Messages	116

This section describes how to configure channel attributes. The IMTA includes the following configurable channels:

Internet SMTP channel

Intranet SMTP channel

Router SMTP channel

Sun Message Store channel

/var/mail channel

Pipe channel

Deleted channel

Inactive channel

Hold channel

You can also add new channels as needed. Note that the number of SMTP channels will depend on the mail server's position versus the Internet.

Channel configuration can also be done by editing the imta.cnf file. Editing the file allows you to add channel keywords that are not supported by the Admin Console. Refer to channels section in the SIMS Reference Manual (IMTA Configuration Chapter). Use extreme care when editing the configuration file as errors could result in IMTA malfunction.

---

Note - SIMS does not support the configuration of the UNIX to UNIX Copy Program (UUCP) channel using the Admin Console. You can configure the UUCP channel by editing the imta.cnf file. For more information on imta.cnf, refer to the SIMS Reference Manual.

---

TABLE 5-2 summarizes the configurable attributes of these channels, specifically which channels to which each attribute applies.

TABLE  5-2   Configuring Channels   

Configurable Aspect	Channel Applies To	Description
Channel description	Applies to all channels	You can generate a description of a channel for administrative purposes only.
Router	Applies only to SMTP router channels	In the event that an IMTA cannot resolve a particular message address, you must configure a host to which the IMTA can route the message.
Character set labels	All channels	Determines the label for 7-bit character sets and for 8-bit character sets to be used in plain text messages.
Message Limitation	Some attributes apply to SMTP channels only	Determines how the channels handle large messages and messages with many recipients.
Delivery Status Notification	Applies to all channels	Determines how a channel handles the messages that warn of or return undelivered mail.
Report Problems to Postmaster	Applies to all channels	Determines how a channel handles the sending of warning messages to the postmaster.
Diagnostics Output	Applies to all channels	Determines whether a channel produces diagnostic output for its master program, slave program, or both.
Performance Tuning	Applies to all channels	Determines how the IMTA delivers messages and defers the processing of messages, thereby tuning its performance.
Logging	Applies to all channels	When selected, provides logging information to the global log.
Multiple Internet Mail Extensions (MIME) Fragmentation	Further applies to Sun Message Store, /var/mail, and pipe channels only.	You can enable a channel to reassemble message fragments into one message upon receipt.
Rewrite rules	Applies to all channels	You can add a new rewrite rule to an existing or newly created channel, or delete or modify an existing rewrite rule.

To Create a Channel

You can create channels of the type SMTP explicit router only through the Admin Console. No limitations exist for the overall number of channels that you can create and the number of specific types of channel that you can create.

AdminConsole>IMTA>Create pulldown>Channel

FIGURE  5-6 New Channel Property Book

To Delete a Channel

You can delete the router SMTP channel (explicit route) that you created.

AdminConsole>IMTA>Channels>Selected pulldown>Delete Channel

To Access a Channel's Property Book

AdminConsole>IMTA>Channels

FIGURE  5-7 Sample Channel Property Book

To Configure a Channel Description

By default, the IMTA generates a channel description. You can update this description with any desired notes or details. This description is for administrative purposes only and does not affect the behavior of the channel.

AdminConsole>IMTA>Channels>double-click desired channel>Channel Description

FIGURE  5-8 Channel Description Section

To Configure a Router Host

---

Note - This section applies to SMTP router channels only.

---

In order to route messages to a particular domain, the IMTA may rely on the DNS and deliver mail through the SMTP intranet/SMTP Internet channels. An alternative is to specify the domain host to which to route mail. The messages are then delivered through an SMTP router channel

Note that if the IMTA is not connected to the Internet, mail to all external domains is forwarded to a smart host by the default SMTP router channel. The smart host is the host to route to for the default SMTP router channel.

AdminConsole>IMTA>Channels>selected channel>Selected Menu>Properties>Router

FIGURE  5-9 Router Section

To Configure Character Set Labels

The MIME standard provides a means of labeling or naming the character set used in a plain text message. The character set labels are inserted in the Content-type header of a message, indicating what type of characters are used in the message.

AdminConsole>IMTA>Channels>selected channel>Selected Menu>Properties

FIGURE  5-10 Select Character Set Section

Message Limitation

To Configure Message Limitation

101

Some email systems and IMTAs encounter problems when handling large messages. You can control how the channels handle large messages (measured in bytes and number of lines) for the SMTP intranet/Internet channels, SMTP explicit route channels, and local or message store channels (for other channels, this feature has no effect). You can specify that messages be limited by size or number of recipients, or that they be fragmented if they exceed a certain size.

To Configure Message Limitation

Utilities: imadmin-modify-msglimits
imadmin-search-msglimits

AdminConsole>IMTA>Channels>selected channel>Selected Menu>Properties>Message Limitation

FIGURE  5-11 Message Limitation Section

To set local user to local user mail message limitations, configure the local (Solaris Message Store) or message Store (Sun Message Store) channel depending on the recipient's channel. Note that the local and message Store channels do not support either of the Fragmented submitted msgs parameters or the Max. # of recipients per msg parameter.

You can specify a limit at which a message should be fragmented into smaller messages and a limit at which a message should be deemed too large and rejected. The default is unlimited.

Delivery Status Notification

To Configure Delivery Status Notification	102
To Configure Report Failures to the Postmaster	104

Occasionally, a channel may not be able to process an incoming message (for example, a remote MTA may go down, which is considered a transient failure, or a user is unknown, which is a permanent failure). When this happens, SIMS sends a delivery status notification or notary message to the postmaster and the sender.

For a permanent failure, the message is bounced and a notification is sent to the postmaster.

For a transient failure, by default, the channel will send up to three notary messages to the originator of the message at the following intervals: 1 day, 2 days, 4 days, and 7 days after the original message was sent. Each notary message will inform the originator that the original message is undeliverable, why the message is undeliverable, and how long delivery attempts will continue. By default, 12 days after the original message was sent, the original message will be returned to the originator. If the failure is corrected before the 12 days, the messages will be delivered. You can reconfigure the interval at which the notary messages are sent and the original message is returned.

To Configure Delivery Status Notification

Utility(s): imadmin-modify-notary & imadmin-search-notary

AdminConsole>IMTA>Channels>selected channel>Selected Menu>Properties>Delivery Status Notification

This option is not supported for the SIMS Message Store Channel.

FIGURE  5-12 Deliver Status Notification Section

Notary Message Locale

To change the default locale (C) so that notary messages (text messages sent by the IMTA to an email sender indicating delivery or nondelivery status of a sent message) appear in a different character set, you will need to create a separate locale directory under the IMTA configuration directory and edit imta_tailor file such that the IMTA_LANG points to the new locale directory.

To Change the Notary Message Locale

For example, if you want the notary messages to appear in Japanese, do the following:

To Configure Report Failures to the Postmaster

Utility: imadmin-modify-postmaster
imadmin-search-postmaster

By default, the local postmaster receives a copy of all notary messages for transient and permanent failures except those undelivered messages that do not have an originator address. You can reconfigure the channel to send a copy of all or no notary messages to the local postmaster. Although receiving a copy of each of the notary messages may help you monitor the state of the channel queue, you will have to weigh this benefit against the increase in traffic that the channel will need to handle. To configure what part of the message is sent to the postmaster, you can add additional channel keywords in imta.cnf (see the SIMS Reference Manual).

AdminConsole>IMTA>Channels>selected channel>Selected Menu>Properties>Report Problems to Postmaster

FIGURE  5-13 Report Problems to Postmaster Section

Diagnostics Output

To Configure Diagnostics Output

105

By default, a channel does not produce diagnostics output for its master and slave programs. You can reconfigure the channel so that it produces diagnostics output for either its master program, its slave program, or both.

When enabled, diagnostic output is written to the log file associated with the channel program. For more information on diagnosis using log files refer to the SIMS Reference Manual.

To Configure Diagnostics Output

AdminConsole>IMTA>Channels>selected channel>Selected Menu>Properties>Diagnostics Output

FIGURE  5-14 Diagnostics Output Section

To generate diagnostic output for the channel's master or slave program, click the corresponding check box.

To Set Recipient Limitation

By default, the SMTP channel allows an unlimited number of recipients for a message without deferring processing. Too many recipient addresses can result in a delay in message processing. If the delay is long enough, network timeouts can occur and this in turn can lead to repeated message submission attempts and other problems. You can specify a limit of recipients for a single message at which message processing is deferred. When the specified number is exceeded, the message is enqueued and the remaining recipients are not verified on-line. Nondelivery receipts are generated for recipients later found undeliverable.

AdminConsole>IMTA>Channels>double-click channel>Properties>Performance Tuning

FIGURE  5-15 Performance Tuning Section

Message Logging

To Configure Message Logging

107

By default, a channel logs in each message in
/var/opt/SUNWmail/imta/log/mail.log_current. You can reconfigure the channel so that it logs in each message as it enters and is removed from the queue.

By default a log entry consists of the following fields:

Date and time that entry was made

Name of the source channel (channel that message originated from)

Name of the destination channel (channel that message needs to be delivered to)

Type of entry:

E = message was entered into the channel queue

D = message was removed from the channel queue

Q = an unsuccessful attempt was made to remove the message from the channel queue

Size of the message in kilobytes

Address in the From envelope after rewriting

Address in the To header

For more information refer to Chapter 12, "SIMS Monitoring and Logging and to the SIMS Reference Manual.

To Configure Message Logging

AdminConsole>IMTA>Channels>double-click channel>Properties>Logging

The Logging section appears as shown in FIGURE 5-16.

FIGURE  5-16 Logging Section

Reassembling MIME Messages

To Enable Reassembly of Message Fragments

109

---

Note - This section applies to the UNIX to UNIX Copy Program (UUCP) channel, Sun Message Store channel, /var/mail channel, and pipe channel only.

---

Occasionally a large message must traverse email systems that impose message size limitations. MIME allows the breaking up of a large message into smaller messages, a process known as fragmentation. A Message/Partial Content-Type header field that appears in each of the smaller messages or fragments contains information that helps reassemble the fragments into one message, a process known as defragmentation.

By default, the Sun Message Store channel, /var/mail channel, and pipe channel do not defragment a message. You can configure each of these channels to reassemble a fragmented message upon receipt.

For complete information on message fragmentation and defragmentation, and the Message/Partial Content-Type header field, refer to RFC 1521.

To Enable Reassembly of Message Fragments

AdminConsole>IMTA>Channels>double-click channel>Properties>MIME Fragmentation

The MIME Fragmentation section appears as shown in FIGURE 5-17.

FIGURE  5-17 MIME Fragmentation Section

To enable the reassembly of message fragments, click Yes.

To disable the reassembly of messages, click No.

Rewrite Rules

To Add, Delete, or Modify a Rewrite Rule

110

The Admin Console enables you to add or modify a rewrite rule for the following type of channel: SMTP Intranet, SMTP Internet, SMTP explicit route (i.e SMTP ROUTER), Address lookup (the LOCAL channel). If you want to add Rewrite rules for other channels, you need to modify the configuration files directly (see SIMS Reference Manual). The Admin Console also enables you to delete or modify an existing rewrite rule associated with an existing channel.

Before adding or modifying a rewrite rule for a particular channel, read the associated conceptual information in the SIMS Concepts Guide and SIMS Reference Manual (IMTA Configuration chapter). When adding or modifying a rewrite rule, you might need to configure the following elements:

Pattern

Domain template

Element to which rule applies

Address direction

Order of rewrite rules

A pattern is a string composed of ASCII text, which might include wildcard characters that can potentially match the host/domain specification of an incoming email address. The host/domain specification is the portion that is to the right of the at (@) sign; for example, in the address john.smith@eng.acme.com, the host/domain specification of the address is eng.acme.com. The wild card character that you can specify is an asterisk (*). An example of a pattern entry is

*.acme.com

A domain template defines how the host/domain specification of the address is rewritten. A template can be composed of one or both of the following elements:

A full static host/domain specification, for example, corp.acme.com, or a portion of a host/domain specification (a portion of the address tokens), for example, .com.

A single field substitution string that dynamically rewrites one address token of the host/domain specification represented by a wild card character (*). The address token to be rewritten can be the portion of the address that did not match the rewrite rule pattern or the portion that matched the wild card character. The rewriting of a host/domain specification is based on the contents of the specification itself. The template can include multiple field substitution strings.

The syntax of the field substitution string is as follows:

$&n

where n is an integer from 0 to infinity. The integer n represents the unmatched or wild card address token that is to be rewritten. From left to right, the leftmost address token is represented by the integer 0; the second from the left is represented by the integer 1, and so on. An example of a template entry is

$&0.$&1.com

The element that the rewrite rule applies to determines if the rule applies to the address that appears on the envelope only, the message header only, or both.

Address direction determines whether the rewrite rule applies to a forward address (To, CC, and BCC headers + envelope RCPT TO:) or a backward address (From or Reply-to headers + envelope FROM:).

To Add, Delete, or Modify a Rewrite Rule

AdminConsole>IMTA>Channels>double-click channel>Properties>Rewrite Rules

FIGURE  5-18 Rewrite Rules Section

Monitoring Channel Queues

Utilities: imta-counters, immonitor-queue,

SMTP command: xsta (allows you to get current channel counters without having to log into the system.

To Monitor the IMTA Channel Queues on Admin Console	113
To Monitor the IMTA Channel Queues Using xsta	115
Snapshot of Message Traffic Through IMTA	144

You can monitor accumulated message traffic statistics for each IMTA channel queue (includes user-created channels). At the same time, you can compare statistics accumulated for one channel queue to statistics accumulated for the IMTA.

The queue monitor accumulates the following statistics:

Received messages - Number of messages that have entered the channel queue

Submitted messages - Number of messages that have exited from one channel queue and entered another channel queue

Delivered messages - Number of messages that have exited the channel queue

Stored messages - Number of messages currently stored in the channel queue

Received volume - Volume of messages that have entered the channel queue measured in kilobytes

Submitted volume - Volume of messages that have exited from the channel queue and entered another channel queue measured in kilobytes

Delivered volume - Volume of messages that have exited from the channel queue measured in kilobytes

Stored volume - Volume of messages currently stored in the channel queue measured in kilobytes

For more information refer to "Snapshot of Message Traffic Through IMTA" on page 144.

To Monitor the IMTA Channel Queues on Admin Console

AdminConsole>IMTA>Channels>select channel>Selected pulldown>Monitor Queue

FIGURE  5-19 Internet Message Transfer Agent Channel Queue Monitor

Red - Message count per channel

Blue - Message count per system

Red - Message volume per channel

Blue - Message volume per system

To Monitor the IMTA Channel Queues Using xsta

Viewing Enqueued Messages

To View Messages Stored In the IMTA Channel Queues

116

You can also view a listing of the messages currently in the channel queue. The messages are stored for various reasons; for example, the mail server may be currently unavailable and the message delivery will be retried later. The type of information you can view about the stored messages includes the following:

Message ID

Message originator

Date/time that message was originated

Message size

Contents of message itself

Once you find the specific message, you can view the contents of the message, save it, or delete it from the queue.

To View Messages Stored In the IMTA Channel Queues

AdminConsole>IMTA>Channels>selected channel>Selected Menu>Monitor Queue>Show Stored Message

FIGURE  5-20 Stored Queue Monitoring

DNS-based Canonicalization

---

Note - DNS-based canonicalization will only work in the default domain and its subdomains.

---

Canonicalization is the process of converting an aliased or shortened domain name to its fully qualified domain name (FQDN) or canonical domain name. A fully qualified email address has the following forms:

<uid>@<mailhost>.<company name>.com (example: ed@rocket.stream.com)

<uid>@<subdomains>.<company name>.com (example: al@corp.bridge.com)

There are two primary reasons why domain canonicalization is needed: 1) allowing the short address form to be used within a domain, 2) to canonicalize the FROM: address such that return mail has a deliverable address.

Example for reason 1: You may wish to set up your email system such that users within the same domain can send mail to each other by entering a short form of the address without the FQDN. Thus, if a domain is corp.bridge.com and your server name is hourglass, you may want to provide users with the ability to send local mail using the form <uid>@hourglass or <uid>@hourglass.corp or <uid>@corp instead of <uid>@corp.bridge.com.

Example for reason 2: Some email clients in your system may be set up such that the FROM: header appends the short form of the user's email address. If a recipient wants to reply to the sender, a short form return address, for example uid@corp, is useless since a fully qualified address is needed to complete a delivery. For this reason, address canonicalization should be done as early in the delivery process as possible.

Address canonicalization must perform two tasks:

Canonicalizing addresses of this type can be done by including a set of rewrite rules for each non-fully qualified address. The default SIMS configuration includes some of those rules:

CODE  EXAMPLE  5-2 SIMS Default Rewrite Rules to Canonicalize Local Addresses

! rules to select local users

mailhost.corp.company.com $U%mailhost.corp.company.com [1]

mailhost.corp $U%mailhost.corp.company.com [2]

mailhost $U%mailhost.corp.company.com [3]

corp.company.com $E$U%$D [4]

! tcp_intranet

.corp.company.com $E$U%$H.corp.company.com [5]

* $U%$&0.corp.company.com@tcp_intranet-daemon [6]

.corp $U%$H.corp.company.com [7]

[1] Rule for already fully qualified addresses.

[2] Rewrites: user@mailhost.corp --> user@mailhost.corp.company.com

[3] Rewrites: user@mailhost --> user@mailhost.corp.company.com

[4] Rule for already fully qualified addresses

[5] Rule for already fully qualified addresses

[6] Rewrites: user@myhost --> user@myhost.corp.company.com

[7] Rewrites: user@myhost.sub.corp ->user@myhost.sub.corp.company.com

For complex multinational environments which include multiple servers, these rules may be very numerous or subtle. For example:

If our domain is bridge.com, an internal address might be:

bill@hourglass.uk --> bill@hourglass.uk.bridge.com

And an external address could be:

paul@stream.co.uk --> paul@stream.co.uk

In this first example the internal address ends with .uk and is canonicalized as needed for internal delivery. In the second example, however, the address ends with .uk, but is not an internal address, consequently it shouldn't be canonicalized. Problems like this cannot be solved by adding just one simple re-write rule. That's where DNS-based canonicalization can be useful.

By using the DNS-based canonicalization the administrator can concentrate all the information in one place instead of spreading it across different rewrite rules living in different imta.cnf files. Moreover, this information is already available in the DNS database. The disadvantage of DNS-based canonicalization is that for every address (canonicalization is applied to both envelope and header addresses), at least one DNS lookup is issued, making this process much slower than a simple rewrite rule.

DNS-based Canonicalization Algorithm

A SIMS DNS-based canonicalization consists of successive DNS lookups:

For each DNS lookup:

If a CNAME record is found for the address, the address is replaced by the new one and the entire process starts again (step 1).

If an A record is found, the address that was just used to query is considered the canonical address and the address is rewritten.

If an MX record is found then:

If no domain variation was added yet (example: the incoming address was hourglass.corp.bridge.com), the hostname that was just used to query is considered the canonical address and the address is rewritten.

If no previous MX record were found by previous queries, the hostname is kept but the lookups continue.

If a previous MX record was found, that previous record is considered the canonical address and the address is rewritten.

Thus, if the incoming address is hourglass, an A record and an MX record are found for the address hourglass.corp.bridge.com, then the canonicalized address is hourglass.bridge.com.

If the incoming address is hourglass, the first query will try hourglass.corp.bridge.com. If only an MX record is found for this entry, the query is continued for hourglass.bridge.com. If another MX record is found, then hourglass.corp.bridge.com is the canonical address.

Literal to Domain Canonicalization

It is legal to put an IP address in the domain part of an email address if the IP address must be between square brackets "[ ]" (example: rocketeer@[191.24.12.13]). This is known as literal addressing. Literal to domain canonicalization replaces this type of address with the canonical one if the reverse DNS lookup for IP address to hostname succeeds. Example:

bob@[192.24.12.12] --> bob@rocket.stream.com where 192.24.12.12 is the IP address of rocket.stream.com.

Setting Up DNS-based Canonicalization

DNS-based canonicalization can't be set up through the Admin Console. You have to manually include a set of rewrite rules.

The rewrite rules for DNS-based canonicalization are in the file
/etc/opt/SUNWmail/imta/dns_canonical.rules. The rule corresponding to the DNS canonicalization is:

$* $[IMTA_DNSRULES,imdns_canon_or_tmpfail,$U@$H]

The rule corresponding to the literal to domain canonicalization is

[] $U%$[IMTA_DNSRULES,imdns_canon_literal,$L]

To activate DNS canonicalization, edit /etc/opt/SUNWmail/imta/imta.cnf and uncomment the include line for dns_canonical.rules by removing the leading "!" character):

! DNS canonicalization rules
</etc/opt/SUNWmail/imta/dns_canonical.rules

Then restart the MTA:

/opt/SUNWmail/sbin/imta restart

You can activate only the DNS canonicalization or the literal-to-domain functionality by commenting one of them in /etc/opt/SUNWmail/imta/dns_canonical.rules.

---

Note - These operations will only work if your DNS is accurately configured.

---