How HCL Traveler processes SmartForward/SmartReply requests

A SmartForward/SmartReply (SFSR) request is an email that is a forward or reply of a previously received email that does not include the body or attachments from the original email which is being forwarded or replied to. Instead, a SFSR contains just the forward/reply body text and any additional attachments, plus an identifier of the original email.

The Traveler server constructs the forward/reply email body using the body and attachments from the SFSR request along with the body and attachments from the original email. Using SFSR allows the mobile client to forward attachments from an email that it received without downloading or uploading the attachments over the connection between the device and Traveler, saving time and bandwidth.

SFSR is enabled in the Traveler server by notes.ini setting NTS_SFSR_SUPPORT. For more information, see Notes.ini settings.

Traveler's SFSR capability is sent to the mobile clients during the SyncML capabilities exchange in the GetSettings reply. The HCL Verse clients for iOS and Android that support SFSR start using it once the support is enabled. In contrast, the iOS native Mail app always sends fully constructed forward and reply emails, including the original email body and attachments that it deems necessaary, regardless of Traveler's SFSR support setting.

Construction of the forward/reply email body depends on how the original email was saved in the user's mail file. Most emails are saved as Notes RichText documents - in that case, the body from the SFSR request is converted to Notes RichText before the original email body is appended to it. Conversion from HTML to Notes RichText is not perfect, so formatting of the SFSR body text may be altered slightly during construction of the forward/reply email. If the original email was saved as a MIME document with a text/html section, the HTML body of the original email is copied into the text/html body of the SFSR request in an attempt to preserve HTML formatting.

The SFSR request and the original email may both contain inline attachments and non-inline attachments. The constructed forward/reply email includes all inline attachments from both the SFSR request and the original email, and non-inline attachments from the SFSR request. However, non-inline attachments from the original email are only included if the SFSR request specifically identifies them. A field in the SFSR request contains a list of the attachments from the original email that should be included. By default, the device requests all non-inline attachments from the original email on SmartForward requests, and none of the non-inline attachments from the original email on SmartReply requests. However, the client is allowed to select which non-inline attachments from the original email should be included or excluded for both SmartForward and SmartReply.

Note: SFSR processing is not performed on forward or reply emails that were saved as Draft, then reopened and sent. Saving as Draft converts the forward or reply into plain text, losing all formatting and converting inline attachments to non-inline.