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
host0 is the name of the local MTA host, as used by the other remote MTA systems, and
hostN are the host names of the remote MTA systems. The strings
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
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
domainN are the domain names of the remote MTA systems.
Finally, add to the
FORWARD mapping table the entry
FORWARD bsmtp@host0 email@example.com$Y$D
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
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
FORWARD mapping table entry
FORWARD firstname.lastname@example.org email@example.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
FORWARD mapping table entry
FORWARD firstname.lastname@example.org email@example.com$Y$D
With the above configurations, when a user on hub.domain.com sends mail to firstname.lastname@example.org, 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 email@example.com. 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.