PIPE Module

The CommuniGate Pro PIPE module creates the Submitted folder inside the CommuniGate Pro base folder.

The PIPE module scans this folder periodically, and processes the files with the .sub file name extension. When such a file is found, the module copies it into a message queue file and submits that file to the Server kernel for processing.

The .sub text files should contain messages in the RFC822 format. The module uses the data in the RFC822 header fields to compose the message envelope.

• The RFC821 "channel format" should NOT be used: submitted files should use the system native "End of Line" character(s), the dot (.) symbol in the first position should not be doubled, and the file should not end with the dot (.) symbol.
• Addresses specified in the To:, Cc:, Bcc: header fields are used to create the message envelope (recipient addresses).
• The Bcc: header fields are removed from the submitted message.
• If at least one Envelope-To: header field is detected, message envelope (recipient) addresses are formed using the addresses specified in these header fields, and addresses in all remaining To, Cc, and Bcc headers are not placed into the message envelope. The Envelope-To: header fields are removed from the submitted message.
• If no Envelope-To: header field exists, and the Envelope-Ignore field or fields exist, the addresses specified in To/Cc/Bcc header fields and also listed in the Envelope-Ignore fields are NOT included into the message envelope.
• If the Sender: and/or From: header fields contain addresses without the domain part, the Server domain name is added to those addresses.
• If the Return-Path: header field exists, the address specified in that header is used to compose the Return-Path envelope address, and this header field is removed from the submitted message.
• If the Return-Path: header field does not exist, the address specified in the From: or Sender: header field is used to compose the envelope Return-Path address.
• If the Envelope-ID: header field exists, its content is used as the message Envelope ID. This header field is removed from the submitted message.
• If the Envelope-Notify: header field exists, it should contain one or several keywords SUCCESS,FAILURE,DELAY,RELAY separated with comma symbols, or it should contain one keyword NEVER.
  This header field specifies the DSN parameters applied to all envelope addresses composed after this field is met. This header field is removed from the submitted message.
  Several Envelope-Notify: header fields can be used to specify different DSN parameters for different addresses.

If processing of a .sub file fails (for example, if the file does not have any recipient address), the module places a record into the System Log, and changes the file extension to .bad.

If a .sub file is submitted successfully, the file is deleted from the Submitted folder.

Because of the way the PIPE module processes the Submitted folder, it is recommended to compose messages in a different file directory and then move the composed .sub files to the Submitted folder, or to compose messages in the Submitted folder, in files with the .tmp file name extension, and then change the file name extension to .sub.

Messages submitted via the PIPE module are marked as "received from a trusted source", so they can be relayed without restrictions.

The PIPE module accepts all messages directed to the pipe domain.

The local part of the message address specifies the external application to launch. The part can contain parameters, and can be enclosed into the quotation marks.

Example:

A message directed to the "execjoe -l store"@pipe address will be sent to the application execjoe started with the -l store parameters.

In order to allow several PIPE processors to deliver messages simultaneously, the PIPE module creates a separate queue for each message it has to deliver. If you want to serialize processing, you can use the following form of the PIPE address:
"queue[name] application parameters"@pipe
All messages directed to these addresses will be placed into the name queue, and a single PIPE processor will send the enqueued messages to the application(s) specified in those addresses. You can use any alphanumeric string as a queue name, and you can specify as many queues as you need.

The message text (the header and the body) is sent to the task as that task standard input (stdin).

An application name can be prefixed with the [FILE] tag:
[FILE] application parameters
When this prefix is used, the application standard input will be empty (closed), or it will contain only the message header fields added by Rules. The string -f Queue/fileid.msg (the -f flag and the Message file name, relative to the base directory) will be appended to the end of the application parameters:
-f Queue/12002345.msg

Note: The beginning of a Queue file contains the service information (envelope, options, etc.). The application should ignore this information skipping the file data till the first empty line. The message itself starts after that first empty line in the Queue file.

In emergency situations you may need to process an additional Queue directory without stopping your server. These situations include a server hardware failure when the rescued Queue files should be processed with some other, already running server.

To process an additional Queue directory, move it to the base directory of a running server as the ForeignQueue directory. If you prefer to use symbolic links, make sure that the Queue and ForeignQueue directories are created on the same file system.

Every 3 minutes the PIPE module checks if the ForeignQueue directory exists in the server base directory. If the ForeignQueue directory is found, the module moves all .msg files from the ForeignQueue to the Queue directory (it can rename the files in the process), and deletes all .tmp files found in the ForeignQueue directory. Files with other extensions are left in the ForeignQueue directory.