Pipe channels

Pipe channels are used to effect delivery for specific addresses via a site-supplied program or script. While pipe channels are loosely based upon the   (pipe) functionality of sendmail, they have been carefully  designed to not pose a security threat. First, the availability of a pipe channel is configurable: the MTA administrator may remove the pipe channel from the configuration if he or she prefers not to trust the technology. Second, the commands executed by the pipe channel are controlled by the MTA administrator, and no user supplied input  can find its way into those commands: each command the administrator supplies is used  verbatim with the exception of the optional substitution of a filename  generated by the channel itself without reference to user supplied  input. Finally, the decision to run a command is not based upon the presence of special characters appearing in a recipient address, but  rather upon a recipient address exactly matching a specific address or  host name in a table or database which the MTA administrator must provide. If an exact match between an incoming address and the site&#x27;s table or database exists,  then the command listed in the table for that match is executed.

Unlike the sendmail pipe functionality, the MTA&#x27;s pipe channel does not pipe the message to be processed to the program or script. Instead, it writes the message to be processed to a temporary file and then forks a  subprocess to run the site-supplied command for that message. The forked subprocess then opens the message file on stdin prior to executing the command.

The command can either read the message from stdin or it can make use of the name of the temporary file which can be  substituted into the command by the channel. The temporary file should not be deleted or altered by the subprocess; the channel will delete it  itself. If it is not possible to prevent the subprocess from disrupting the file, then the pipe channel should be marked with the    channel option.

If the subprocess exits with exit code of 0 (EX_OK) then the message is presumed to have been delivered successfully and is removed from the MTA&#x27;s queues. If it exits with an exit code of 71, 74, 75, or 79 (EX_OSERR, EX_IOERR, EX_TEMPFAIL, or EX_DB) then a temporary  error is presumed to have occurred and delivery of the message is  deferred. If any other exit code is returned, then the message will be returned to its originator as undeliverable. These exit codes are defined in the system header file.

See also:
 * Setting up a pipe channel
 * Pipe entry match order
 * single Option
 * Other channels