Is it possible to exceed the 999 character limit on setting an InternetHeader in an Addin for Outlook?

bram robyn 5

For a business project, I am creating an Outlook Addin which will decode an email and check signatures after which we then add labels and so on.

I am required to send an InternetHeader with my email this way:

 item.internetHeaders.setAsync({ "Binding-Data": result }, (setHeaderResult) => {
        if (setHeaderResult.status == Office.AsyncResultStatus.Succeeded) {
          item.saveAsync(result => {
            console.log(result.value);
          })
        }
        else {
          console.log(setHeaderResult);
        }
      })

However, my header will exceed the 999 character limit in most of the cases.
Because of this limit, the header does not want to be added to the email, resulting in an error:

"Sys.ArgumentOutOfRangeException: Sys.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: Binding-Data"

However, I know it is possible to send an email with larger headers.
To test and verify this, I've created a powershell script that sends an email with my required data in the header, which goes perfectly fine, and it's possible to be read out using the Javascript API in the Addin.

I was wondering if there is the possibility to increase or disable the max character limit in the API/Addin, or if it's possible to ask a feature request for this.

1 answer

Michael Taylor 54,646 Reputation points

2024-07-16T15:32:06.6266667+00:00

This is a limit defined by the RFC5322 standard. Each line is limited to 998 or less characters and should be no more than 78 characters.

The fact that you were able to receive (or send) a header that was larger doesn't make it legal. It is up to each client/server to determine whether it enforces the rules or not.

The recommended workaround is to "fold" the line. Refer to the spec on this.
Please sign in to rate this answer.
bram robyn 5 Reputation points

2024-07-17T06:50:14.7733333+00:00

Thank you for your answer.
I understand it isn't according to the standard, the thing is that my header is more than 998 characters long in total. The line is already folded in multiple lines below 78 characters per line, so I'm afraid that this won't do either.

Robin Goussey 0 Reputation points

2024-07-17T13:52:35.3966667+00:00

Yes, but I think the API has no way to fold, or doesn't automatically fold, regarding RFC5322: end of 2.2.3:

"The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation. An unfolded header field has no length restriction and therefore may be indeterminately long"

Is there a way to pass it a folded header to avoid the line length?

Michael Taylor 54,646 Reputation points

2024-07-17T14:49:14.0833333+00:00

Are you sure you're actually folding the lines properly? Maybe you should review the raw data you're sending. Folding requires a CRLF which is different than a CR and/or a LF. Ensure you're actually generating the header properly.

Another thing to consider is that if there is a proxy between you and the remote server then it is possible the proxy may cause some problems. So ideally test your folding without any proxies in the way to eliminate that as a concern.

Irregardless, to your original question of whether you can change the max length, the answer is still no. Folding is your only option.

bram robyn 5 Reputation points

2024-07-18T06:48:14.88+00:00

As far as I know this should be ok.

I convert the data I need sent in a base64, then I go over it 44 characters at a time (that results in less than 78 characters per line after it added binding data and such)
at the end of the line I add the CRLF \r\n.
This should be correct, unless I am missing/overlooking something.

const bindingDataInfo = { BindingSegmentLength: 44, }; const endLine = "\r\n"; const base64Data = btoa(data); let bindingData = ``; bindingData += `binding-type="${bindingDataInfo.BindingType}";${endLine}`; for (let i = 0; i < base64Data.length; i += bindingDataInfo.BindingSegmentLength) { const index = i / bindingDataInfo.BindingSegmentLength; bindingData += `binding-data-object*${index}="${base64Data.slice(i, i + bindingDataInfo.BindingSegmentLength)}";${endLine}`; }

Michael Taylor 54,646 Reputation points

2024-07-18T14:07:57.7433333+00:00

I have to admit I'm not an expert on header folding in the spec but the generated data doesn't seem to follow the format requirements defined by 2.2.3 of the spec. If you use data that is shorter than the 78 character limit does it work?

Is the binding-type stuff a custom data object you're passing for the header and binding-data the only header you're trying to send?

Given your code I don't see the Binding-Data parameter that is actually in the error message. Going back to your original post it appears that whatever result is becomes the field's value. I assume that is what you're passing as the result to the original code you posted. In that case the formatting isn't going to be correct I think because you're folding the value too soon. Personally I would build up the data that you want to send in one function (the last code you provided, but without the folding) and then pass that data string to the function that ultimately is calling setAsync. Inside this function (your original code) you take result and run it through a fold function that takes the string and then injects CRLF + whitespace after every 44 characters. This value is then sent to setAsync.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Is it possible to exceed the 999 character limit on setting an InternetHeader in an Addin for Outlook?

1 answer

Your answer