send link function output format invalid in 6.4.15002.6500

shawnkhall 4 years ago updated by Ben Burner 4 years ago 5

The "open in email client" link in the Access Build "Send Link" tool fails to wrap the resulting link in angle brackets. URIs longer than 72 characters should be wrapped in angle brackets per RFC 3261 section 20. Currently it simply generates a 450+ character URI without angle brackets.

ConnectWise Control Version:
Server Affected:
Host Client Affected:
Guest Client Affected:



This issue should be resolved in the 6.5 release of ConnectWise Control.

Waiting for information

Good morning,

If you don't mind, could you provide the exact subsection of section 20 that outlines the 72-character limit in the following document:




Hi, Ben,

Thanks for the fast response - and sorry about the book, but hopefully this gives you enough context to fully understand the situation.

Angle brackets serve an important purpose. According to RFC2396 (the specific standard that normalizes use of URI and URL formats for modern use) the use of an angle bracket is suggested (though not required) when wrapping URIs in content. This is especially important in formats where you can not control the method of distribution. This is detailed here:

   URI are often transmitted through formats that do not provide a clear
   context for their interpretation. For example, there are many
   occasions when URI are included in plain text; examples include text
   sent in electronic mail, USENET news messages, and, most importantly,
   printed on paper. In such cases, it is important to be able to
   delimit the URI from the rest of the text, and in particular from
   punctuation marks that might be mistaken for part of the URI.
   In practice, URI are delimited in a variety of ways, but usually
   within double-quotes "http://example.com/", angle brackets
   <http://example.com/>, or just using whitespace
   These wrappers do not form part of the URI.

(Note that I replaced the sample domain that originally appeared in this quote with example.com per RFC2606.)

RFC3261 explains the purpose of encapsulating URIs with angle brackets at §20.10 as a mechanism to ensure that logical break characters often included in URIs ("?", "&", ",", ";") are not treated as breaks.

   When the header field value contains a display name, the URI
   including all URI parameters is enclosed in "<" and ">". If no "<"
   and ">" are present, all parameters after the URI are header
   parameters, not URI parameters. The display name can be tokens, or a
   quoted string, if a larger character set is desired.

The specific issue is that URIs tend to break at "wrap-points" within most client applications, resulting in a nonfunctional or nonparsable address. Wrapping the URI in angle brackets tells the user-agent that any carriage returns or line feeds within the URI should be ignored, and that it should not attempt to reflow or replace any content between the angle brackets.

The SMTP protocol, the standard by which all email is transmitted, uses an encapsulation process (RFC2646: Text/Plain, Format=Flowed) that generally breaks each line into between 64 and 72 characters to achieve universal relay and agent compatibility, but loses context in doing so. Yes, messages could be sent in HTML format (text/html) but since you can't guarantee that messages will be sent only in HTML format, you must assume that at least some clients will use text/plain instead. In fact, I think you'll find most security people prefer plain-text email. In other words, you have to play well with that 72-character imposition or you will break things.


   When generating Format=Flowed text, lines SHOULD be shorter than 80
   characters.  As suggested values, any paragraph longer than 79
   characters in total length could be wrapped using lines of 72 or
   fewer characters.  While the specific line length used is a matter of
   aesthetics and preference, longer lines are more likely to require
   rewrapping and to encounter difficulties with older mailers.  It has
   been suggested that 66 character lines are the most readable.

While this, by itself, doesn't mean that unwrapped URIs will necessarily break, it does mean that any URI that is longer than 72 characters is very likely to break unless enclosed in double-quotes or angle brackets, and the recommendation from RFC2396 is to use angle brackets. If a URI that's a mere 73 characters long is likely to have problems, a 450+ character URI is guaranteed to have problems. 

It's important to understand that while some URIs may work when sent text/plain at over 72 characters, it is only because the webmaster is performing a redirect in order to get you to the right place thanks to a service in place on those individual websites that recognizes bad-form URIs and attempts to fix them. In these cases the URIs can be redirected because everything after a unique ID in the URI is there only for the sake of SEO and has no actual value in getting access to the content at the complete URI itself. In fact, most websites will not behave in this way and will return a 404 error instead. Frankly, it's poor form to expect the webmaster to treat user inadequacies as correct. 

With ConnectWise Control, if the URI breaks you will not get the same content. ConnectWise Control simply can not redirect to the correct full URI since every token within the full URI has important and unique context. Most of the tokens (name/value pairs) in the URIs generated by ConnectWise Control can not safely be stripped or broken without defecting the entire URI. Heck, there are even individual tokens that exceed that 72-character limit!

Moreover, neglecting the angle brackets is especially likely to create problems when used in a mailto link since the link itself presumes that the resulting context is to be an email message...you know, those things that wrap at 72 characters! While you could, theoretically, use quotes to wrap the URI instead, since the links are being used in a mailto anchor, which itself is already using quotes to wrap it's own URI thanks to the HTML spec requirements, it's all the more important to use angle brackets instead.

Do you follow?

Under review

Thank you for the detailed reply!

I have submitted your comments to the development team for review.




This issue should be resolved in the 6.5 release of ConnectWise Control.

Commenting disabled