Conversion entry scanning and application

From Messaging Server Technical Reference Wiki
Jump to: navigation, search

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:

  • if specified IN-CHAN and OUT-CHAN parameters match the channels1 through which the message is passing;
  • and if the specified PART-NUMBER matches the structured part number2 of the message part;
  • and if the (required!) IN-TYPE parameter, as well as all specified IN-PARAMETER-NAME, IN-PARAMETER-VALUE, and IN-SUBTYPE parameters, match the Content-type: of the message part;
  • and if all specified IN-DISPOSITION, IN-DPARAMETER-NAME, and IN-DPARAMETER-VALUE parameters match the Content-disposition of the message part;
  • and if the IN-DESCRIPTION matches the Content-description of the message part;
  • and if specified IN-SUBJECT, IN-MESSAGE-CONTEXT, IN-A1-TYPE, and IN-A1-FORMAT values match those of the headers of the immediately enclosing message (message/rfc822 part);
  • and (as of MS 7.0.5) if the IN-ENCODING matches 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 OUT-ENCODING, OUT-PARAMETER-NAME-n, OUT-PARAMETER-VALUE-n, OUT-SUBTYPE, OUT-TYPE, OUT-DESCRIPTION, OUT-DISPOSITION, OUT-DPARAMETER-VALUE-n parameters.

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 IN-CHAN or 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..

See also: