Configuring the BSMTP channels

From Messaging Server Technical Reference Wiki
Jump to: navigation, search


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 host0 is the name of the local MTA host, as used by the other remote MTA systems, and host1, host2, ..., hostN are the host names of the remote MTA systems. The strings remote1, remote2, ... remoteN and REMOTE1, REMOTE2, ..., REMOTEN are arbitrary and need just be distinct from one another.

With the above definitions, the channel bsout_remote1 will bundle up its BSMTP parcels and send them on to the fixed address bsmtp@host1. 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 domain1, domain2, ... domainN are the domain names of the remote MTA systems.

Finally, add to the FORWARD mapping table the entry


FORWARD 
 
  bsmtp@host0    bsmtp@bsin.host0$Y$D 

where, again, host0 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 bsmtp@host0, it will be forwarded on to the local bsin_gateway 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 FORWARD 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 FORWARD 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 bsout_remote1 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 $Nbsout_remote1 tag in the domain.co.uk rewrite rules, those rewrite rules will be ignored when the bsout_remote1 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 after 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 host0 is the official local host name for the MTA system. The least efficient is the FORWARD mapping table; which method is best for a given site depends upon site-specific issues. Use of the FORWARD mapping table is presented here because that method works in all cases.


See also: