Technical Paper Lotus Notes Knowledge Base
Published
Product Area: Notes Date: 01.05.2002
Product Release: Notes Client 5.x Document #: 183036
Category: Messaging & Mail\\Workstation Mail (Mailer)\\Wkstn Based Mail Issues
. This document is based on the following
Software Problem Report(s): About SPRs
SPR Number:
JHOD4QHL76
KGEW4QDQNP
BPAE4FVTYP
JHOD4R5VVK SPR Status:
Open/Reproduced
Duplicate Report
Under Investigation
Under Investigation Fixed in:
Not Applicable
Not Applicable
Not Applicable
Not Applicable
Troubleshooting MIME and Converted Rich Text Messages Displayed by the Notes Client
OVERVIEW
This document describes functionality and issues for messages that are/were in MIME format. It covers the attributes of messages and includes several limitations and issues with messages created and sent from a browser, specifically those created from Netscape. Each section builds on information covered previously in the document.
The following are issues covered in this document - each are described in detail later in this document under the "SPECIFIC SYMPTOMS" section below:
1. Image links are "broken" and do not display. They contain a red X in the upper left corner.
2. [IMAGE] appears instead of the image (Netscape) / Gray box appears instead of image in attachment viewer (IE).
3. Images appear but cannot be detached because there is no attachment icon.
4. Messages do not render all of the expected HTML.
FIRST STEP IN TROUBLESHOOTING THESE ISSUES - NOTES RICH TEXT or MIME?
The first step in troubleshooting these issues is to determine whether the message is in Notes Rich Text or MIME format. You can determine this by checking the Body field in the Document Properties' fields tab. If the message is in Rich Text format, the Body field is of type Rich Text. If it is in MIME, the Body field is of type MIME Part and a field called $NotesHasNativeMIME exists and is equal to "1".
You can determine if the message was in MIME format (at one point) by viewing the $MIMETrack field. This field gives you the conversion history of the message:
If there is no $MIMETrack field, the message originated in Notes Rich Text or was converted by an R4 SMTP MTA.
"Itemized by ...." - the server or router takes an Internet mail message and stores it in a Notes message document with a sequence of Body fields of type MIME Part. Each body field corresponds to a MIME body part or a MIME Multipart termination. The field contains the MIME "blob" specific to that part.
"Serialized by... " - the router takes the message stored in a Notes Document and converts it to a MIME message. This occurs when a Person document's mail system is set to POP3/IMAP. Serializing prepares documents for download via the protocol after being stored as a Notes message.
"MIME - CD by...." - the server or router converts the notes message's MIME Part body fields into one or more Rich Text body fields.
1. The Router converts this based on the Format Preference in the Person document and whether any MAIL.BOX or the mailfile is in R4.x ODS format.
2. The Server converts this temporarily if the message is perceived to be opened by an R4.x client. If the message is edited or copied by the R4.x client, it is converted permanently.
Refer to the document titled, "Background and Current Status of Notes/Domino R5 Native Support of HTML and MHTML Rich Text Format" (#181131) for more information on message conversion.
WHAT WAS IN THE MIME HEADER?
Information in the MIME header also affects how a message is displayed. The only way to determine what was in the MIME header is to trap the message at the server. Refer to the document titled, "How to Trap Inbound SMTP Messages on a Domino 5.x Server" (#178652 ) for information on how to do this.
Content-Type: When the Content-Type's Name parameter is set equal to a filename, Notes encapsulates the MIME Part into an attachment with that filename and attaches it to the message as a $File field. For example, if the Content-Type is set to image/jpeg, the encoded image in the corresponding section is attached. If the Content-Type is set to text/html, the text in the section is attached as a file. In both cases, the Notes viewer can view and launch the image or HTML, respectively.
Content-Disposition: When the Content-Disposition equals "inline", Notes creates a $File field containing the MIME "blob" attachment. However, when the message is opened, there is no attachment icon and the attachment is rendered automatically. For example, if the Content-Type's Name parameter indicates an image, the image will display. If it indicates an HTML file, the HTML is rendered automatically when opened. In both cases, there is no attachment to detach.
Content-Location and Content-Base: These header fields indicate the location of URLs used within the HTML included in the current MIME part. The Content-Base specifies the base Uniform Resource Identifier for resolving URLs within the section. The Content-Location is used to specify locations corresponding to the Content-Base. If there is no Content-Base, the Content-Location defines the base URL for the section.
NOTE: As of Domino R5.0.5, Content-Location and Content-Base are not supported
Messages containing web pages often do not contain actual images. They may reference images via the <IMG SRC> tag in the HTML. This HTML forces the client to act like a browser, going out to the site and obtaining those images. When a web page is emailed from the browser, the page is likely to contain references to images that are elsewhere on the site. The Domino server does not obtain these images and store them in the document. It simply stores the HTML in the message so that the client can do the browsing when the message is displayed.
SPECIFIC SYMPTOMS
In the following cases, the message was created using the Netscape browser.
1. The client is disconnected, and the image is not contained in the message. In this case, the Notes client is expected to go out to the website and obtain the image. If the client is disconnected, it cannot access the site, and the image is broken.
2. The image is referred to by a "relative URL" reference. This relies on the Content-Base and/or Content-Location field in the MIME header. Neither are currently supported in Notes. Because of this, the Notes client is unable to interpret Relative URLs. This issue has been reported to Lotus Quality Engineering (as SPR JHOD4QHL76). Images referred to by direct URL references display fine. This is why the same message will show some images and not others. For example, images referred to in the HTML by <IMG SRC = "\images\image.gif"> appear as a broken link. Images referred to by <IMG SRC = "
www.lotus.com\images\image.gif"> appear fine.
These problems do not occur with messages generated from Internet Explorer. Although each MIME section is encapsulated into an attachment using the Content-Type Name parameter, the attachment is of type HTML and rendered automatically by the Notes client. Internet Explorer adds the BASE HREF tag to the HTML header. Because Notes can render the HTML and does not have to utilize the MIME header, all references are able to obtain images using this "base".
NOTE: When connected, you may initially see a block for where the image lies, along with a grey down arrow in the upper left. This appears while the Notes client is in process of obtaining the images. If the connection is slow, or the web site is complex, it may take some time before the image is actually displayed.
Some messages display images that are not actually contained in the message, but are instead referenced using the <IMG SRC> HTML tag. With a MIME message, the images are displayed by the browser-capable Notes client, which connects to the web site and displays the message using the URL link. However, if the message is converted to Notes Rich Text, this problem occurs. The Domino server process responsible for this conversion is not browser-capable and is not responsible for obtaining the images when the message is converted by the router (on delivery) or by the server (when opened from an R4.6x client). Therefore, the image cannot be obtained, and the [IMAGE] placemark is added instead. It is recommended to upgrade the client to R5, and set the preference in the Person document to 'No Preference' or 'Prefers MIME' to prevent conversion.
The [IMAGE] symptom occurs with Netscape produced messages. There is no Content-Type Name specified in the header. Therefore, no attachment is created with the information from the section. The information must be translated directly to the Body field by the server. Since the image is not obtained by the server, [IMAGE] text is placed instead.
Internet Explorer messages contain the Content-Type Name= allowing Notes to create an attachment based on the indicated filename. The Notes Viewer can view the HTML. However, the actual code is shown, and images appear as gray boxes with a full "X" in the middle. The attachment can be detached and launched successfully, assuming that the extension is correctly associated with the browser program. The web page message created from Internet Explorer is usually of file type HTM or HTML. The attachment will be launched with the browser program (if there is one) associated with this file type.
This issue has been reported to Lotus Quality Engineering (as SPRs KGEW4QDQNP and BPAE4FVTYP).
This occurs for MIME messages with a Content-Disposition field in the MIME header set to "Inline". This tells Notes to prevent displaying the attachment icon. According to the MIME standard, the display of an attachment is used when action is required on the part of the recipient. Inline message components are displayed automatically and no expected action is required by the recipient. Netscape adds this field to the MIME header, and Notes follows through by not allowing the image to be detached.
However, starting with Notes 5.0.5, a User Preference can be set to force Notes to create an attachment icon and allow the recipient to detach the image file. This preference is under File, Preferences, User Preferences, Additional Options, "Show in-line MIME images as attachments". When this preference is set, the image is not displayed automatically and must be viewed, launched, or detached from the message.
Carriage Return/Line Feeds (CR/LF) in HTML code are not parsed correctly as a space by the Notes Client when the MIME message is converted to Notes Rich Text. This can be a problem in the rare circumstance that an HTML tag with a space is split among 2 lines by CR/LF. For instance, if the code contains the following lines, the text specified by the alt= tag will not be rendered because the whole tag is invalid:
<img
name="image" src="image.gif" width="326" height="50" alt="image.gif (3637 bytes)" border="0">
Whereas the following line will display "sandbox.gif (3637 bytes)":
<img name="image" src="image.gif" width="326" height="50" alt="image.gif (3637 bytes)" border="0">
This issue has been reported to Lotus Quality Engineering (as SPR JHOD4R5VVK). Keep in mind that, with converted messages, the Notes Viewer is limited in what it can display, utilizing information specified by the Alt tags instead.
Related Documents:
Background and Current Status of Notes/Domino R5 Native Support of HTML and MHTML Rich Text Format
Document #: 181131
How to Trap Inbound SMTP Messages on a Domino 5.x Server
Document #: 178652
Font, Color and Size Stripped from Rich Text Field by Web Agent
Document #: 177242
Rich Text Editor Java Applet Can Handle Only 40K of Text Before Creating a $MIME_PART Attachment
Document #: 190819
© 2002 IBM Corporation. All rights reserved.
Material may not be reproduced or distributed in any form without permission.
