Mail delivery channels

A mail channel permits delivery of a mail message and logically has two components:

• a channel table whose data determines what messages will be delivered by the channel

• an agent, or program, which performs the actual delivery

The delivery agent may be a type of network communication protocol, such as SMTP or UUCP. In the case of local mail, the delivery agent is the slocal program. By specifying the channel program, you specify to sendmail what the mechanism is for delivering mail in that channel.

Both channel tables and programs will be discussed in more detail in ``Channel program'' and ``Channel table type''.

To see the various mail channels:

1. Select the ``Mail Delivery Channels'' category group.

2. Double click or press <Enter>.

Local

Called to deliver mail to mailboxes and processes on the local machine. See UNRESOLVED XREF-0 for more details.

SMTP

Called to deliver or accept mail from a TCP/IP network connection. The SMTP channel transfers messages by establishing a TCP/IP connection to a remote machine, and, using the Simple Mail Transfer Protocol (SMTP) to send one or more mail messages. The Internet Protocol (IP) allows many local or wide area networks to be interconnected transparently. This permits the SMTP channel to exchange messages with any machine on any network to which it is connected. For a list of RFCs describing SMTP and its extensions, see UNRESOLVED XREF-0.

Badhost (delay)

When you have a channel configured for use of the domain name service in order to match and qualify host names (as the default SMTP channel does), you need some way of preventing messages from failing in delivery (or ``bouncing'') in the event that the name server is temporarily unavailable. This channel accomplishes that purpose. In such an occurance, a message which fails to be resolved by the default SMTP channel will be ``delayed'' by the Badhost channel, and queued for another future attempt at delivery; hopefully, at a time when the network is restored. By default, sendmail is configured to allow messages to remain in the queue for up to five days before messages are considered undeliverable and are bounced. For more information on the queue timeout options, see UNRESOLVED XREF-0.

---

NOTE: This form of the Badhost channel is similar in function to the ``Nameserver delay channel'' in MMDF on SCO OpenServer Release 5.

---

UUCP

Called to direct mail to UUCP delivery to another machine, or to accept mail from another machine. Incoming mail is converted into the format specified by RFC822, Standard for the Format of ARPA Internet Text Messages. Outgoing mail on the UUCP channel includes a ``from'' line and the mail path arguments are separated by UUCP exclamation point characters (!). Refer to uucp(1bnu) for more information.

Multihome

Multihoming is the ability for a single physical machine to appear as multiple virtual machines in (possibly) different domains. An IP address is consumed by each virtual domain. A guiding principle of multihoming is that virtual users should have access to all of the services that users on a normal UNIX host have access to. For every virtual user, a physical user is required and mapping from virtual users to physical users for each domain.

This has several benefits: it allows normal authentication to be used after the simple user mapping has been accomplished. Multiple virtual users can map to a single physical user. The virtual user can have the same name or a different name at the administrator's choice. Virtual users have access to non-multihome-aware services but they must use their physical user ID to access non-multihome-aware services.

It is envisaged that as more multihome-aware services come online that user-perceived dependence upon the physical user ID will diminish. Refer to multihome(1) and multihome(1M) manual pages for more information on Multihome.

The Multihome channel allows mail addressed to a virtual user in a virtual domain to be sent to the actual physical user it maps to on the local machine. The channel table for the Multihome channel holds the virtual domains configured for the machine. The channel program for the Multihome channel converts the virtual user address into a physical user address, and then re-submits the message to sendmail. Aliasing may be configured for each virtual domain, and, since the message is re-submitted to sendmail, aliasing is executed on the final physical name as well.

Enabling the Multihome channel is only one piece of configuring multihoming for the mail system. For additional information about configuring virtual domains, virtual user mappings, and aliasing for virtual domains using the Virtual Domains User Manager, see ``The Virtual Domain User Manager''.

Badhost (forwarding)

In addition to its use for delaying delivery of messages (``Badhost (delay)'') in the default configuration, the Badhost channel may be configured to forward messages to a ``smart'' host if the mail address is truly unknown to the local machine. The use of ``bad'' is a misnomer; a machine is unknown (and therefore ``bad'') if the address has not been resolved previously by another mail channel. Therefore, it is important to order the Badhost channel after all other channels which also handle mail to remote hosts; by default the Badhost channel, whether in the role of delaying or forwarding, is positioned in this way. For this form of the Badhost channel, you must specify the forwarding host, which is assumed to be ``smart'' enough to successfully deliver the message. This, then, is the main difference between the two forms of the Badhost channel, as for the purpose of delay you do not specify a forwarding host. By default, this channel uses SMTP to perform the mail forwarding, but the delivery program may be configured otherwise, as in other mail channels. See UNRESOLVED XREF-0.

Baduser

Called when local mail is addressed to an unknown user name, in order to forward this mail to a smart host. The channel table for the Baduser channel uses the ``user'' class map in sendmail in order to determine unknown (or ``bad'') users. Data from both /etc/passwd and NIS can be accessed by sendmail's ``user'' class map. The Baduser channel must be the last channel in the list of channels. The Badhost channel forwards its mail to another ``smart'' host, which you must specify. It is again assumed that this ``smart'' host can successfully deliver the message. By default, the Baduser channel uses SMTP to perform the mail forwarding, but this may be configured otherwise. See UNRESOLVED XREF-0.

1. Select the Settings menu.

2. Click on the specific channel wanted to enable or disable it.

In the case of the Badhost channel, if it is already enabled, then selecting the Settings Bad Host Forwarding/Delay menu option causes a dialog to appear for the purpose of modifying the forwarding host. If it is not already enabled, it will be, and a dialog appears for the purpose of specifying the forwarding host. If no value for the forwarding host is entered, the Badhost channel queues messages for future attempts at delivery.

1. Select the channel to be deleted on the the main screen.

2. Delete the channel by either selecting the Edit Delete menu option, or clicking on the Delete button on the toolbar.

All of the channel attributes, including that of the forwarding host, may be modified as discussed in ``Modifying mail channels''.

In addition, customized channels may be configured. You may choose a channel table from a selection of built-in tables, or create a channel table file which you will populate with data. The delivery agent may also be selected from a list of known available programs, or you may enter the pathname to a program that you supply. Details on how to create a custom channel are covered in the section, ``Adding channels''.