|Oracle eMail Server Administrator's Guide
If you will be exchanging messages and message attachments with a non-MIME-compliant system, then you can set up a gateway that performs special encoding and decoding.
In most cases, the default MIME (Multipurpose Internet Mail Extensions) configuration will be sufficient for your needs. If you need to customize your MIME configuration, then use the following tasks described in this chapter:
The SMTP/MIME (Simple Mail Transfer Protocol/Multipurpose Internet Mail Extensions) gateway provides a standard set of content transfer methods for encoding MIME attachments such as base64, quoted-printable, 7-bit, 8-bit, and binary methods. In addition, the gateway can also be configured to perform non-standard content transfer encoding and decoding, such as uuencode.
All outbound messages undergo either type conversion or content transfer encoding before they can be transmitted through the SMTP gateway. Exceptions are message bodies and attachments of types that map to text/<text-subtype> without conversion. The character set used is the one specified with the
default_charset gateway parameter.
You can specify the content-transfer method with the
default_encoding gateway parameter. The sender can also override this parameter by specifying any supported encoding method in the Content-Transfer-Encoding header when composing a message.
SMTP transmits data in 7-bit byte streams. MIME defines how 8-bit data can be encoded in 7-bit byte stream for transmission in SMTP. The gateway recognizes that messages composed in a non-ASCII character set may contain 8-bit data that requires transfer encoding.
The gateway checks the Content-Transfer-Encoding header (not case-sensitive) for the name of the encoding method the message sender wants to use--for example, quoted-printable or x-uuencode. When the Content-Transfer-Encoding header is not present in the main message, the gateway uses the default transfer encoding method specified in the
When an attachment containing 8-bit data does not require type conversion, the gateway performs transfer encoding on the data. For example, the attachment type mapping instructs the gateway to map eMail Server type GIF to image/gif, but does not define a converter for this GIF-to-image/gif mapping. The attachment will undergo content transfer encoding and be sent out as an image/gif MIME part.
default_charset gateway parameter enables the 32-bit Windows client programs that cannot use the X-Orcl-Charset extended header to specify the character set information of the message body of outbound SMTP/MIME messages.
default_charset parameter carries all the semantics of the X-Orcl-Charset extended header. This parameter takes a lower precedence over the X-Orcl-Charset extended header. That is, if a sender specifies X-Orcl-Charset extended header, then the extended header value will be taken as the
default_charset parameter in the Content-Type header of the message body and all of its text attachments (which are without the
default_charset parameter in the Content-Type header).
If this parameter is set to non-ASCII characters, then text parts of outbound messages are encoded by using the current transfer method defined by the
default_textencoding gateway parameter. Content transfer encoding is necessary for converting text composed in 8-bit character sets to ensure that it is correctly transferred by the SMTP/MIME gateway.
The value of
default_charset is suppressed by the value of X-Orcl-Charset extended header if present in the message.
default_textencoding gateway parameter specifies the content transfer encoding method used for text message bodies and text attachments written in non-ASCII character sets.
The method of content transfer encoding used for text message bodies and text attachments is the value set for the
default_textencoding gateway parameter. By default, the
default_textencoding parameter is set to
The value of the gateway parameter
default_encoding applies only to non-text body parts. The value of this parameter will be suppressed by the extended header Content-Transfer-Encoding.
When you define external programs for content transfer encoding/decoding by using the
insert attachmap command, use the
foreigntype parameter to specify the name of the encoding method. Also, give the
localtype parameter a value corresponding to an attachment type that has a definition for the generic platform.
Standard content transfer encoding methods described in RFC1521 (that is base64, quoted-printable, 7bit, 8bit, and binary) are not given to external programs to perform encoding and so must use the gateway's interpretation of the encoding algorithms.
External encoder programs should perform both encoding and decoding. Restrictions for external conversion programs also apply to external content transfer encoders.
"Defining an x-uuencode Converter: Example" for more information
When an external encoder program fails, the gateway encodes the data in base64. A message explaining this is sent to the message sender.
When an external decoder program terminates with an error, the MIME body part is inserted as an attachment type defined in the
default_type parameter, a process parameter for the UNIX gateway processes. The attachment starts with an X-Orcl-Comment header, which reports that the gateway failed to decode the data. The Comment header is followed by the original Content-Type and Content-Transfer-Encoding headers.
The following example defines an external converter for the x-uuencode transfer encoding method. The gateway uses the shell command
ofcuu.sh -E in directory $ORACLE_HOME/bin to filter all binary data.
The name of the transfer encoding method appears in the Content-Transfer-Encoding header of the outbound message.
IOFCMGR>insert attachmap gateway=smtp 2>foreigntype=x-uuencode 3>converter=ofc_uu.sh 4>description='unix-to-unix encode/decode' localtype=1;
Messages that are not MIME-compliant may use the uuencode method to encode 8-bit data into 7-bit data. You configure the uuencode method by using the gateway parameters
You use the
do_uuencode parameter to determine if 8-bit data should be encoded by the gateway without relying on external encoders. If the parameter is not zero, then the gateway codes 8-bit (non-ASCII) data contained in outgoing messages.
The SMTP/MIME (Simple Mail Transfer Protocol/Multipurpose Internet Mail Extensions) gateway also supports plugging in external encoders for encoding content transfer for messages that are not RFC1521-compliant. The sender of a message can explicitly specify a certain method of content transfer encoding.
When composing a message, use the X-Orcl-Charset extended header to indicate the character set being used in the message body and the attachments to text MIME types (which do not have the
charset parameter specified in their Content-Type header). This extended header will not be transmitted.
Use the parameter
do_uudecode to determine if non-MIME-compliant data encoded with uuencode should be decoded or treated like ordinary MIME messages. If the parameter is not zero, then the gateway performs automatic decoding of encoded data contained in incoming messages. If the parameter is set to zero, then data is not automatically decoded. (This only works for non-MIME-compliant data that is uuencoded. MIME-compliant messages with a content-transfer-encoding of
uuencode require an external decoder.)
The gateway examines each line of the message for the start of a uuencoded segment.
In a piece of uuencoded data, a file name and the file permission are specified at the beginning. The gateway will create an attachment with the specified file name but will ignore the file permission. If decoding is successful, then the decoded data is inserted into the attachment. However, if decoding fails, then the uuencoded data is inserted in the attachment.
In either case, an attachment is created for a uuencoded segment in a message that is of the type specified by the gateway parameter
default_type. The uuencoded segment will be removed from the message body.