Conversion entry scanning and application
The conversion channel processes each message routed through it, part by part. The header of each part is read and its Content-type: and other header information is extracted. (Note that composite media types, that is, MULTIPART/* or MESSAGE/* "parts", are not made available per se to the conversion channel, though any component discrete body parts within such composite types are made available to the conversion channel for potential processing.)
The entries in the conversion file are then scanned in order from first to last; any
IN-* parameters present and the
OUT-CHAN parameter, if present, are checked. If all of these parameters match the corresponding information for the body part being processed, then the conversion specified by the remainder of the entry is performed. Note that an entry must include an
IN-TYPE clause in order to match. More specifically, the matching checks:
OUT-CHANparameters match the channels1 through which the message is passing;
and if the specified
PART-NUMBERmatches the structured part number2 of the message part;
and if the (required!)
IN-TYPEparameter, as well as all specified
IN-SUBTYPEparameters, match the Content-type: of the message part;
and if all specified
IN-DPARAMETER-VALUEparameters match the Content-disposition of the message part;
and if the
IN-DESCRIPTIONmatches the Content-description of the message part;
and if specified
IN-A1-FORMATvalues match those of the headers of the immediately enclosing message (message/rfc822 part);
and (as of MS 7.0.5) if the
IN-ENCODINGmatches the Content-transfer-encoding of the message part.
Only if all specified parameters match is the entry considered to match. Scanning terminates once a matching entry has been found or all entries have been exhausted. If no entry matches, no conversion is performed.
If the matching entry specifies
DELETE=1, then the message part is deleted. Otherwise, the command specified by the
COMMAND parameter is executed.
Once an entry with a
COMMAND parameter has been selected, the body part is extracted to a file. The converter execution environment is prepared as specified by the
PARAMETER-SYMBOL-n parameters and
DPARAMETER-SYMBOL-n parameters. Finally, a subprocess is created to run the command specified by the
COMMAND parameter. The command should perform the necessary conversion operation, reading the file specified by the environment variable (UNIX) and producing the file specified by the environment variable (UNIX).
The command may optionally set options in the
OUTPUT_OPTIONS file to pass information back to the conversion channel.
Conversion operations are terminated and no conversion is performed if the forked command returns an error.
If the command succeeds, the resulting output file is read as specified by the
OUT-MODE parameter and a new body part containing the converted material is constructed according to the
This process is repeated for each part of the message until all parts have been processed.
See Conversion entry parameters for a complete list of the parameters available to conversion entries.
1The source channel and destination channel are normally the original source channel and original destination channel prior to the
CONVERSIONS mapping table applying and forcing a "hop" through the conversion channel: that is, the conversion channel itself is not normally the
OUT-CHAN. However, see the
original_channel_probe MTA option, and explicit routing of an address through the conversion channel for exceptions.
2 The structured part number is the message part number as it would appear in PMDF MAIL. That is, a multipart message has outer "level" parts counted starting from 1, and with a part, if it is a multipart itself, the subparts count starting from 1, and so on for additional "levels". So a multipart with no additional sublevels may have part numbers 1, 2, 3, etc., while a multipart whose second part is itself a multipart, might have part numbers 1, 2.1, 2.2, etc., 3, etc..