Thank you for calling out the code in your prior message. If I’d paid better attention, I could have saved myself a lot effort typing up the console messages. 
Unfortunately, this line of code diverted my attention from the rest:
cburlMailto.addParameter("to", strEmailTo);
I believe that the canonical definition of mailto is RFC6068 and section 2 lays out the syntax for a mailto Uniform Resource Identifier (URI).
Reveal additional detail
mailtoURI = "mailto:" [ to ] [ hfields ]
to = addr-spec *("," addr-spec )
hfields = "?" hfield *( "&" hfield )
hfield = hfname "=" hfvalue
hfname = *qchar
hfvalue = *qchar
addr-spec = local-part "@" domain
local-part = dot-atom-text / quoted-string
domain = dot-atom-text / "[" *dtext-no-obs "]"
dtext-no-obs = %d33-90 / ; Printable US-ASCII
%d94-126 ; characters not including
; "[", "]", or "\"
qchar = unreserved / pct-encoded / some-delims
some-delims = "!" / "$" / "'" / "(" / ")" / "*"
/ "+" / "," / ";" / ":" / "@"
As section 2 indicates, the portion of the URI before the question mark (“?”) delimiter does NOT contain the header characters to:
mailtoURI = "mailto:" [ to ] [ hfields ]
to = addr-spec *("," addr-spec )
Consequently, I don’t think that it is correct to use .addParameter method to assemble the to address(es).
Having said that, the to address(es) can NOT simply be added to the .baseURL property without encoding at least portions of them.
Reveal additional detail
As stated on page 4:
1. A number of characters that can appear in <addr-spec> MUST be
percent-encoded. These are the characters that cannot appear in
a URI according to [STD66] as well as "%" (because it is used for
percent-encoding) and all the characters in gen-delims except "@"
and ":" (i.e., "/", "?", "#", "[", and "]"). Of the characters
in sub-delims, at least the following also have to be percent-
encoded: "&", ";", and "=". Care has to be taken both when
encoding as well as when decoding to make sure these operations
are applied only once.
and
4. Percent-encoding can be used in the <domain> part of an
<addr-spec> in order to denote an internationalized domain name.
The considerations for <reg-name> in [STD66] apply. In
particular, non-ASCII characters MUST first be encoded according
to UTF-8 [STD63], and then each octet of the corresponding UTF-8
sequence MUST be percent-encoded to be represented as URI
characters. URI-producing applications MUST NOT use
percent-encoding in domain names unless it is used to represent a
UTF-8 character sequence. When the internationalized domain name
is used to compose a message, the name MUST be transformed to the
Internationalizing Domain Names in Applications (IDNA) encoding
[RFC5891] where appropriate. URI producers SHOULD provide these
domain names in the IDNA encoding, rather than percent-encoded,
if they wish to maximize interoperability with legacy 'mailto'
URI interpreters.
Thus, I encode the to address(es) and place them in the .baseURL property:
strBaseURL = "mailto:" + encodeURI(strEmailTo);
Likewise, I think that the values (hfvalue) of the other portions of the URI, e.g., cc, bcc, subject, and body, must also be encoded (though I didn’t do so in my demonstration code above).
Finally, section 5 makes it clear exactly how to encode new lines in the body:
Also note that line breaks
in the body of a message MUST be encoded with "%0D%0A".
Reveal additional detail
5. Encoding
[STD66] requires that many characters in URIs be encoded. This
affects the 'mailto' URI scheme for some common characters that might
appear in addresses, header fields, or message contents. One such
character is space (" ", ASCII hex 20). Note the examples below that
use "%20" for space in the message body. Also note that line breaks
in the body of a message MUST be encoded with "%0D%0A".
Implementations MAY add a final line break to the body of a message
even if there is no trailing "%0D%0A" in the body <hfield> of the
'mailto' URI. Line breaks in other <hfield>s SHOULD NOT be used.
When creating 'mailto' URIs, any reserved characters that are used in
the URIs MUST be encoded so that properly written URI interpreters
can read them. Also, client software that reads URIs MUST decode
strings before creating the mail message so that the mail message
appears in a form that the recipient software will understand. These
strings SHOULD be decoded before showing the message to the sending
user.
Software creating 'mailto' URIs likewise has to be careful to encode
any reserved characters that are used. HTML forms are one kind of
software that creates 'mailto' URIs. Current implementations encode
a space as '+', but this creates problems because such a '+' standing
for a space cannot be distinguished from a real '+' in a 'mailto'
URI. When producing 'mailto' URIs, all spaces SHOULD be encoded as
%20, and '+' characters MAY be encoded as %2B. Please note that '+'
characters are frequently used as part of an email address to
indicate a subaddress, as for example in <bill+ietf@example.org>.
The 'mailto' URI scheme is limited in that it does not provide for
substitution of variables. Thus, it is impossible to create a
'mailto' URI that includes a user's email address in the message
body. This limitation also prevents 'mailto' URIs that are signed
with public keys and other such variable information.
Anyway, I learned a lot reading RFC6068 and to be honest a lot of it is just too inscrutable for me to comprehend.
)