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 Traveler and Verse clients on Android, Windows Mobile, and Nokia Symbian use the SyncML protocol which sends the attachment data in smaller HTTP packets. As a result, these clients can send mails that are larger than the HTTP POST limits.   

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 content  
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 7 MB attachment could be as big as 9 MB when sent. In addition, the non-atttachment mail content is included in the POST, which  might cause the total content to surpass a 10 MB limit.
  • 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.
  • In addition to HTTP limits, sending data from the client to the server may be limited in other ways. See Server limitations and restrictions.