Each of the PMDF systems which will be exchanging mail via BSMTP will need one incoming BSMTP channel and an outgoing BSMTP channel for each of the remote PMDF 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 PMDF host, as used by the other remote PMDF systems, and host1, host2, ..., hostN are the host names of the remote PMDF systems. The strings remote1, remote2, ..., remoteN, and REMOTE1, ..., REMOTE2, and 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 PMDF 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 PMDF system which will be used by the BSOUT channels on the remote PMDF systems. That way, when they send BSMTP parcels to bsmtp@host0 , it will be forwarded on to the local bsin_gateway channel. ²

For example, assume that the example.com domain will be exchanging BSMTP traffic with the example.co.uk domain via the PMDF hosts hub.example.com and athena.example.co.uk. Then hub.example.com would have the configuration

example.co.uk $U%$H@BSOUT-REMOTE1$Nbsout_remote1 .example.co.uk $U%$H$D@BSOUT-REMOTE1$Nbsout_remote1 ... bsin_gateway smtp bsin.hub.example.com bsout_remote1 smtp master user bsmtp daemon athena.example.co.uk BSOUT-REMOTE1

and the FORWARD mapping table entry

FORWARD bsmtp@hub.example.com bsmtp@bsin.hub.example.com$Y$D

The system athena.example.co.uk would have the configuration

example.com $U%$H@BSOUT-REMOTE1$Nbsout_remote1 .example.com $U%$H$D@BSOUT-REMOTE1$Nbsout_remote1 ... bsin_gateway smtp bsin.athena.example.co.uk bsout_remote1 smtp master user bsmtp daemon hub.example.com BSOUT-REMOTE1

and the FORWARD mapping table entry

FORWARD bsmtp@athena.example.co.uk bsmtp@bsin.athena.example.co.uk$Y$D

With the above configurations, when a user on hub.example.com sends mail to user@example.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.example.co.uk . Owing to the $Nbsout_remote1 tag in the example.co.uk rewrite rules, those rewrite rules will be ignored when the bsout_remote1 channel enqueues the message. Instead, the normal rewrite rules for example.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 want to use the after channel keyword on their BSOUT channels. So doing may prove advantageous for sites who want 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 channel 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.