The actual conversions performed by the conversion channel are controlled by rules specified in the IMTA conversion file. This is the file specified by the IMTA_CONVERSION_FILE option in the IMTA tailor file. By default, this is the file /etc/opt/SUNWmail/imta/conversions.
The IMTA conversion file is a text file containing entries in a format that is modeled after MIME Content-Type: parameters. Each entry consists of one or more lines grouped together; each line contains one or more name=value; parameter clauses. Quoting rules conform to MIME conventions for Content-Type: header line parameters. Every line except the last must end with a semicolon (;). A physical line in this file is limited to 252 characters. You can split a logical line into multiple physical lines using the backslash (\) continuation character. Entries are terminated either by a line that does not end in a semicolon, one or more blank lines, or both. For example, the following entry specifies that application/wordperfect5.1 parts in messages sent to the local channel should be converted to DDIF:
The rule parameters currently provided are shown in TABLE 3-11. Parameters not listed in the table are ignored.
TABLE 3-11 Available Conversion Parameters
TABLE 3-12 shows the basic set of environment variables available for use by the conversion command.
TABLE 3-12 Environment Variables used by Conversion Channel
Additional environment variables containing Content-Type: information can be created as they are needed using the PARAMETER-SYMBOL-n facility.
The conversion channel processes each message part-by-part. The header of each part is read and its Content-Type: and other header information is extracted. 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 parameter is performed.
More specifically, the matching checks: if the IN-CHAN and OUT-CHAN parameters match the channels through which the message is passing; and if the PART-NUMBER matches the structured part number2 of the message part; and if all of the IN-CHAN, IN-PARAMETER-NAME, IN-PARAMETER-VALUE, IN-SUBTYPE, and IN-TYPE, parameters match the Content-Type: of the message; and if all of the IN-DISPOSITION, IN-DPARAMETER-NAME, and IN-DPARAMETER-VALUE parameters match the Content-Disposition of the message; and if the IN-DESCRIPTION matches the Content-Description of the message; and if the IN-SUBJECT, IN-A1-TYPE, and IN-A1-FORMAT of the headers of the immediately enclosing message (MESSAGE/RFC822 part) match those immediately enclosing the message part. Only if all specified parameters match is the entry consider 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. 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 INPUT_FILE environment variable and producing the file specified by the OUTPUT_FILE environment variable.
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, and OUT-DPARAMETER-VALUE-n parameters.
This process is repeated for each part of the message until all parts have been processed.
When performing conversions on a message part, the conversion channel has access to the headers in an enclosing MESSAGE/RFC822 part, or to the message headers if there is no enclosing MESSAGE/RFC822 part.
For instance, the IN-A1-TYPE and IN-A1-FORMAT parameters can be used to check the A1-Type and A1-Format headers of an enclosing part, and the OUT-A1-TYPE and OUT-A1-FORMAT parameters can be used to set those enclosing headers.
More generally, if an entry is selected that has ORIGINAL-HEADER-FILE=1, then all the original headers of the enclosing MESSAGE/RFC822 part are written to the file represented by the OUTPUT_HEADERS environment variable. If OVERRIDE-HEADER-FILE=1, then the conversion channel will read and use as the headers on that enclosing part the contents of the file represented by the OUTPUT_HEADERS environment variable.
Environment variable names may be substituted into a conversion entry by enclosing the name in single quotes. For instance, with a site supplied command procedure CONVERTER that attempts to perform various conversions and which defines OUTPUT_TYPE and OUTPUT_SYMBOL job logicals describing its output, one might use an entry along the lines of:
To obtain a literal single quote in a conversion entry, quote it with the backslash character, \'. To obtain a literal
backslash in a conversion entry, use two backslashes, \\.
The value for a conversion parameter may be obtained by calling out to a mapping table. The syntax for calling out to a mapping table is as follows:
Consider the following mapping table:
The following conversion entry for the above mapping table results in substituting generic file names in place of specific file names on attachments: