Topics

You can use a Configuration Settings document to set up how MIME and international character sets convert on multiple Domino servers. You can indicate that you want all servers in the Notes domain to be included by entering a wildcard (*) in the group or server field, or you can specify server names or group names that are controlled by this document. By checking the "International MIME Settings for this document" field on the Basics tab in the Configuration Settings document, it means obey the international MIME settings for the servers using this document. If the field is not checked in a configuration document, then the International MIME settings for that document will be ignored. This allows your organization to set language-specific information for messages depending on the server.

MIME - Basics tab
Domino R5 supports 16 different character set groups (also known as language groups) including Unicode. Some language groups (for example, "Japanese") correspond to a single language and some (for example, "Central Europe") correspond to a region where the languages use more or less the same characters. Some language groups support multiple character sets.

You can indicate a single primary character set group and multiple secondary character set groups. These choices control both inbound (MIME -> Notes CD) and outbound (Notes CD -> MIME) conversions.

For inbound conversion, character set autodetection is required when the incoming MIME or non-MIME message does not contain character set information. Domino is able to distinguish with a high degree of (but not perfect) accuracy among the various character sets used by "CJKT" languages, that is, Simplified Chinese (used in the People's Republic of China), Japanese, Korean, and Traditional Chinese (used in Taiwan). In order to perform this autodetection with the best accuracy possible, it is necessary for Domino to know what priority order to assign to the CJKT regions. For example, if a message is ambiguously either EUC-KR (a Korean character set) or GB2312 (a Simplified Chinese character set), then the priority order of primary and secondary character set groups will be used to determine which character set to choose. The priority order chosen is primary, then secondary (in an undefined order -- it does not matter in which order you have your multiple secondary choices), then the operating system group (for operating systems such as Windows NT where the locale can be queried).

For outbound conversion, Domino chooses a MIME character set based on the text of the message. For some messages in some languages (such as Thai), it is usually obvious which character set to choose. For other messages (such as some European languages), there is much more overlap in the character sets and it is sometimes difficult to guess which MIME character set to use. The primary, secondary, and operating system groups, in that order, are used to break ties in determining which character set to use. That means, for example, if a message contains all characters that could either be Korean or Japanese, then the primary and secondary groups will be used to determine which character set to use.

Note that the client makes additional uses of the primary and secondary settings (configured in the International MIME Settings document in the personal Address book of the user), such as determining which character sets appear by default in the override Encoding dialogs.

Field	Enter
Primary character set group	Choose the appropriate language or region -- for example, Western -- used by your organization.
Secondary character set groups	Choose the appropriate language or region(s) -- for example, Western -- used by your organization.

MIME - Conversion Options - General tab
This tab allows you to indicate whether return receipts can be requested for messages that are going either inbound or outbound from the Internet.

Field	Enter
Return receipts	Enable to allow return receipts for outbound or inbound SMTP messages. For inbound messages, it supports both disposition notifications and return receipts. (default = Disabled)

MIME - Conversion Options - Inbound tab
The fields on this tab control how inbound messages are converted.

Field	Enter
Line length	The maximum line length for the body of inbound messages, useful when a message contains long lines of text without spaces -- for example, URLs. (default = 75)
Use character set auto-detection if message has no character set information	Yes to determine the character set used in the body by examining the content; useful if your site routinely receives non-MIME messages that are encoded in character sets other than ASCII. Provides the best fidelity, but costs in performance. (default = No)

MIME - Conversion Options - Outbound tab
The fields on this tab control how outbound SMTP messages are converted.

Field	Select
Attachment encoding method	The method for encoding file attachments included with outbound SMTP mail. Choose one: - Base64 (default) - Quoted Printable - UUencode
Message Content	Determines how the message will be converted. Choose one: - Convert from Notes to Internet message format (default) - Create multi-part alternative including conversion and encapsulation. This provides true fidelity of the note and encapsulation.
Covert tabs to spaces	Enable to change tabs within text to spaces. (default = No)
Outbound line length	The maximum line length for the body of outbound messages, useful when a message contains long lines of text without spaces -- for example, URLs. If there is a table or forwarded mail headers, then the line length default is doubled so no line break occurs until 150. (default = 75)
Lookup Internet address for all Notes addresses when Internet address is not defined in document	Enable to lookup the Internet address in the Person document , if not provided in the Send To field. Disable (default) to form an Internet address by converting spaces into underscores and encoding Notes domains with percent signs. For example: John_Smith%Notes@acme.com

MIME - Settings by Character Set Groups tab
These fields allow you to override default values for character sets, fonts, and so on, for individual character set groups.

Field	Enter
For outbound messages options below use all possible choices	Check this box to indicate that all character sets are available during configuration of the headers and body character sets. This is an advanced option that allows you to configure non-standard character set choices for various languages.
MIME settings by character set group	This list allows you to choose among the different groups for configuration. It does not matter which value you leave this on when you save the document, it is just used for switching among "tabs".

MIME - Settings by Character Set Groups tab
Inbound Message Options - Font Options section

Field	Enter
HTML Proportional	The typeface style to be used for proportional type in inbound SMTP messages. (default = Default Serif)
HTML Mono-spaced	The typeface to be used for mono-spaced type in inbound SMTP messages. (default = Default Mono-space)
HTML Size	The point size to use for HTML text in inbound SMTP messages. (default = 12)
Plain text	The typeface to be used for plain text in inbound SMTP messages. (default = Default Mono-space)
Plain text size:	The point size to use for plain text in inbound SMTP messages. (default = 10)

MIME - Settings by Character Set Groups tab
Outbound Message Options section
Enter the character set and encoding type for the header and body text of a message. This does not affect attachments. For each language (or region) there is a default character set. For example, for Western Europe the default character set is ISO-8859-1, but other Latin character sets would also be appropriate. You can indicate the specific character set and encoding to be used for outbound SMTP message headers and body content. In general, it is correct to use the same character set for both the headers and the body of outbound messages. The exception is Korean, where the headers and body are typically sent using different character sets. The default values reflect this.

The following matrix shows supported combinations of Message Content versus Attachment Encoding:

Message Content Options	Base 64	Quoted Printable	UUencode
Users without Lotus Notes [MIME]	Yes	Yes	Yes
Users with & without Lotus Notes (not a recommended option)	Yes	No	No

Note: You must be a system administrator with editor access to the Administration Client to see the value choices.

Field	Choose
Header Character Set	The character set. (default = character set defined in the MIME settings by character set group field.)
Body Character Set	The character set. (default = character set defined in the MIME settings by character set group field.)
Header Encoding	The encoding method for outbound headers. Choose one: - Base 64 - Quoted Printable - None The default value is based on the chosen character set.
Body Encoding	The encoding method for outbound body text.

MIME - Advanced - Advanced Inbound Message Options tab

Field	Enter
Resent headers take precedence over original headers	Enable to use RFC822 re-sent headers instead of normal headers. (default = Disabled)
Remove group names from headers	Enable to remove all group names from address headers. (default = No)
If each recipient's address does not appear in any address header, then add their address to the BCClist	Enable resolve differences between the address in the envelope and the address in the header. Any non-RFC822 compliant address is placed in the BCC: header field of a separate copy of the message. (default = No)
For non-MIME messages or MIME messages with an unknown character set, 8-bit character set is assumed to be	Choose the character set to be used as the default if the "Use character set auto-detection if message has no character set information" field is disabled or fails to identify the character set.
Character set name aliases	Enter the substitute name for the equivalent character set to allow MIME to be converted to native MIME. An alias allows a character set name tag in an inbound message to be treated as though it were a different character set. For example, mapping "ISO-8859-1" to "KOI8-R" would be useful in an environment where incoming messages are frequently labeled as ISO-8859-1 (Western) when the data is really KOI8-R (Cyrillic).

MIME - Advanced - Advanced Outbound Message Options tab

Macintosh file attachment support

Sending and receiving Macintosh attachments presents a unique set of problems. Conventional operating systems store a file as an unstructured stream of bytes, along with a small amount of descriptive information such as the file name, creation date, and so forth. The Macintosh operating system (MacOS) carries more information, and stores a file in three parts:

1. Finder information: This includes the file creator and type, which are 32-bit binary identifiers (often represented as 4-character strings), as well as the position of the file icon in the Finder window it lives in.

2. Resource fork: Structured information that can be manipulated by standard system tools; this can include strings, sounds, pictures, code segments, icons, GUI elements, and so forth.

3. Data fork: An unstructured byte stream.

BinHex is fine for Macintosh-to-Macintosh use, but often a Macintosh user wants to send a file containing valid cross-platform data -- for example, a JPEG image, a QuickTime video, or a Lotus 1-2-3 spreadsheet -- to a colleague who is using a PC. BinHex isn't as suitable for this case. Although there are freely available utilities for PCs that let them decode BinHex attachments, using such a utility entails an extra manual step (not to mention the trouble of obtaining and installing the utility in the first place). Because of this, the Internet community defined a standard, called RFC1740, for mailing Macintosh attachments that preserves maximum fidelity for Macintosh users and yet permits cross-platform data to be received in a useful form by non-Macintosh users. In most cases, RFC1740 encoding is used to send Macintosh file attachments.

MIME encoding for Macintosh attachments outbound (Notes to Internet)
Standard RFC1740 encoding occurs for outbound MIME processing and when the "Outbound Macintosh attachment conversion" field is set to "AppleDouble (base64 only)". If the attachment contains a resource fork, the Notes format to MIME converter always sends the resource fork, followed by the data fork. The MIME-to-Notes format converter handles the forks in either order. If the attachment does not contain a resource fork, the data fork is sent "normally" (as a standard MIME type if it can be recognized as such).

If the message is sent outbound as MIME and "Outbound Macintosh attachment conversion" is set to "BinHex", and it goes through a Notes format to MIME conversion, then the attachment is sent as application/mac-binhex40.

In all cases, the attachment is accompanied by the MIME "x-mac-type" and "x-mac-creator" parameters so that even if there is no "application/applefile" part, the receiving user agent can store the attachment with the correct type and creator, allowing the attachment to be launched properly.

Inbound (Internet to Notes)
Inbound, AppleSingle, AppleDouble, and BinHex are supported. Macintosh attachments of any encoding are stored as normal Notes Macintosh attachments; if the data fork would be meaningful to a PC user, then a PC Notes user can launch the attachment normally.

In these examples, unless noted otherwise, when it is said that an attachment can be detached and launched normally, or can be launched from within Notes, it is assumed that the user has the application needed to open the attachment properly installed on his or her system. Also, it is assumed that MIME-compliant user agents are used.

1. A Macintosh Netscape user sends a JPEGview file containing a JPEG image (with no resource fork, which would be the normal case) to two recipients: both are Notes users, one uses a Macintosh and one uses a PC.

Both users receive the attachment intact. If the Macintosh user has JPEGview, the attachment displays with the JPEGview file icon, and can be launched from within Notes. If the Macintosh user does not have JPEGview, the attachment displays with a generic file icon and cannot be launched from within Notes. For the PC user it also has a generic icon; it can be launched from within Notes only if its name ends in .JPG and the user has an application association set up for the .JPG extension. In all cases, the image can be viewed from within Notes by using the "Attachment - View" function.

2. A Macintosh Claris Emailer user sends a 1-2-3 spreadsheet to two Notes users; one who uses a Macintosh and one who uses a PC.

Both recipients receive an intact 1-2-3 spreadsheet attachment. The Macintosh recipient can launch it from within Notes, or can detach it and double-click to launch -- regardless of the name given to the attachment.

The PC user can launch it from within Notes, or detach it and double-click to launch, only if the filename ends in .WK1, WK3, .123, or some other extension associated with the Lotus 1-2-3 application. (This is a restriction of Windows and has nothing to do with Notes.)

3. A PC Notes user sends a 1-2-3 spreadsheet to a Macintosh Claris Emailer user.

The PC user would have to save the spreadsheet as a 1-2-3 R1 spreadsheet, since it is the most recent version of 1-2-3 available on the Macintosh. This is encoded with the MIME type "X-Lotus-123R1", a private MIME type defined by Lotus. Since this is a private MIME type, normally Claris Emailer would not understand it, so the attachment would contain correct data but could not be directly launched. It could be opened manually by first launching 1-2-3 and using the File - Open command.

As an alternative, Claris Emailer uses the file mapping table maintained by Internet Config (a widely used free software utility) to look up MIME types and map them to Macintosh file type and creator codes. It's easy to use Internet Config to add a mapping for the "X-Lotus-123R1" type. If this is done first, then the attachment in this example can be directly launched on the Macintosh.