How HCL Traveler processes attachments

There are several issues to be aware of in how HCL Traveler processes attachments. 

When attachments are downloaded, they are streamed, and all device types should be able to stream large attachments without issue. However, the way a device sends an attachment can vary depending on the device type.

HCL Verse on Android clients, HCL Verse on iOS devices, and HCL Traveler for Microsoft Outlook clients use the SyncML protocol which sends the attachment data in small HTTP packets. Although the SyncML protocol generally avoids issues with the HTTP POST limits, the protocol includes a Maximum Object Size limit which prevents the client from sending any objects larger than that limit. Similar to the HTTP POST limits, the attachment encoding as part of the RFC822 specification and mail content applies to the Maximum Object Size. The limit can be changed via the NTS_TSS_MAX_OBJ_SIZE notes.ini on the server, but currently all of the current SyncML clients use a fixed limit of 25MB, except for HCL Verse Android which honors the NTS_TSS_MAX_OBJ_SIZE value from the server.

Microsoft Exchange ActiveSync devices (BlackBerry, Microsoft Windows Phone, Microsoft Windows Tablet, and Apple using Apple mail client), on the other hand, will send the attachments as part of one large HTTP POST as defined in the Microsoft Exchange ActiveSync specification. Many HTTP servers have limits on the size of HTTP POST requests, and sending a mail with large attachments may exceed these limits. The only way to allow larger attachments is to allow larger HTTP POST requests.

There are Domino HTTP settings that will affect the maximum size of an HTTP POST. The two primary fields are:   
  • Internet Protocols Tab > Domino Web Engine > Maximum POST data 

    OR, if you are using internet site documents:

    Web Site > Domino Web Engine > Maximum POST data

  • Internet Protocols Tab > HTTP > Maximum size of request   
In addition to the Domino HTTP settings that affect the size of the POST data, there are other issues to consider: 
  • Attachments are encoded as part of the RFC822 specification. Encoding the attachments may increase the size up to 33%. This means a 40MB attachment could be as big as 52MB when sent, surpassing a 50MB limit. In addition, the mail content itself is included in the POST, which increases the message size and limits the possible attachment size. The HCL Verse for Android, HCL Verse for iOS, and HCL Traveler for Microsoft Outlook clients enforce a 25MB limit. Allowing for the body and attachment size increase due to encoding, attachments are limited to approximately 17MB with the HCL Verse clients and 15MB with HTMO (Outlook restricts attachments to 20MB after encoding).
  • Any internal network infrastructure, such as firewalls or proxy servers, may also have limits on HTTP POST or data sizes. These limits are outside the control of the HCL Traveler service and customers should confer with their network teams to investigate if any such limits are in place.
  • All devices have HTTP request timeouts. For some devices, this timeout can be as long as five minutes. If posting the data takes longer than the device's timeout, the device itself may terminate the transaction. This can happen with a slower network connection. All parts of the network including proxies and firewalls should allow HTTP requests that may take this long or longer.