Configuring the BSMTP channels

Each of the MTA systems which will be exchanging mail via BSMTP will need one incoming BSMTP channel and an outgoing BSMTP channel for each  of the remote MTA systems. The channel definitions should be along the lines of: bsin_gateway smtp bsin.host0 bsout_remote1 smtp master user bsmtp daemon host1 BSOUT-REMOTE1 bsout_remote2 smtp master user bsmtp daemon host2 BSOUT-REMOTE2... bsout_remoteN smtp master user bsmtp daemon hostN BSOUT-REMOTEN where  is the name of the local MTA host, as  used by the other remote MTA systems, and ,   , ...,   are the  host names of the remote MTA systems. The strings ,  , ...    and  ,   , ...,   are  arbitrary and need just be distinct from one another.

With the above definitions, the channel  will  bundle up its BSMTP parcels and send them on to the fixed address. Likewise for the remaining BSOUT channels.

The rewrite rules appear as: domain1    $U%$H@BSOUT-REMOTE1$Nbsout_remote1 .domain1   $U%$H$D@BSOUT-REMOTE1$Nbsout_remote1 domain2    $U%$H@BSOUT-REMOTE2$Nbsout_remote2 .domain2   $U%$H$D@BSOUT-REMOTE2$Nbsout_remote2 ...  domainN    $U%$H@BSOUT-REMOTEN$Nbsout_remoteN .domainN   $U%$H$D@BSOUT-REMOTEN$Nbsout_remoteN where,  , ...    are the domain names of the remote MTA  systems.

Finally, add to the   mapping table  the entry FORWARD bsmtp@host0   bsmtp@bsin.host0$Y$D where, again,  is the host name for the  local MTA system which will be used by the BSOUT channels on the remote  MTA systems. That way, when they send BSMTP parcels to , it will be forwarded on to the local    channel.1

For example, assume that the domain.com domain will be exchanging BSMTP traffic with the domain.co.uk domain via the MTA hosts hub.domain.com  and athena.domain.co.uk. Then hub.domain.com would have the configuration domain.co.uk   $U%$H@BSOUT-REMOTE1$Nbsout_remote1 .domain.co.uk  $U%$H$D@BSOUT-REMOTE1$Nbsout_remote1 ... bsin_gateway smtp bsin.hub.domain.com bsout_remote1 smtp master user bsmtp daemon athena.domain.co.uk BSOUT-REMOTE1 and the  mapping table  entry FORWARD bsmtp@hub.domain.com bsmtp@bsin.hub.domain.com$Y$D The system athena.domain.co.uk would have the configuration domain.com   $U%$H@BSOUT-REMOTE1$Nbsout_remote1 .domain.com  $U%$H$D@BSOUT-REMOTE1$Nbsout_remote1 ... bsin_gateway smtp bsin.athena.domain.co.uk bsout_remote1 smtp master user bsmtp daemon hub.domain.com BSOUT-REMOTE1 and the  mapping table  entry FORWARD bsmtp@athena.domain.co.uk bsmtp@bsin.athena.domain.co.uk$Y$D With the above configurations, when a user on hub.domain.com sends mail to user@domain.co.uk, the message is routed to the    channel. That channel will package the message up into a BSMTP parcel and send that parcel on to bsmtp@athena.domain.co.uk. Owing to the   tag in the domain.co.uk rewrite rules, those rewrite  rules will be ignored when the   channel enqueues the  message. Instead, the normal rewrite rules for domain.co.uk will take effect and route the message containing the parcel out to the WAN  (e.g., the Internet).

Note that the outbound BSMTP channels can construct application/batch-smtp message parts containing multiple messages. As such, sites may wish to use the    channel option on  their BSOUT channels. So doing may prove advantageous for sites who wish to bundle their mail up into large parcels and send those parcels  only once every few minutes, hours, or days. Also, the ATTEMPT_TRANSACTIONS_PER_SESSION TCP/IP-channel-specific option might be used with the  BSOUT channels to prevent cases where, under heavy load, a BSOUT  channel just runs continuously bundling into a single parcel messages  queuing up to be sent out. This option puts an upper limit on the number of messages placed in a single parcel and forces the channel to  close a parcel, send it along, and start a new parcel when there are  lots of messages to bundle up.

This completes the basic configuration so that BSMTP channels may run and deliver messages. Commonly, however, sites also desire to perform one or more forms of message transformation or processing on BSMTP messages; for further details, see BSMTP service conversions.

Note 1 Any of several mechanisms might be used to accomplish this forwarding. The most efficient is the use of an alias when   is the official local host name  for the MTA system. The least efficient is the   mapping table;  which method is best for a given site depends upon site-specific  issues. Use of the  mapping table is presented here because that  method works in all cases.

See also:
 * BSMTP channels
 * FORWARD mapping table
 * after Option
 * ATTEMPT_TRANSACTIONS_PER_SESSION