How IBM Traveler processes attachments

There are several issues to be aware of in how IBM 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.

IBM Verse on Android clients and IBM Verse on iOS devices, use the SyncML protocol which sends the attachment data in small HTTP packets. As a result, it can send larger sized attachments.   

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, the encoding of  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.   
  • 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 IBM 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.