I received a link in an html formatted email as part of an email verification process for a site.
However, whenever I clicked on it, right mouse clicked to open the link in a browser or right mouse clicked and copied the link target to the clipboard, the link content changed and did not correspond to the plaint text underlying link in the email source.
This was reproducible in Pegasus V4.80 with IERenderer 2.6.5.18 with several emails from that site as well as with the sample code (link) below. I checked the same emails and link with Thunderbird and they worked ok.

During that process the following sample link changed from:

 https://example.com/#/verify-email?userId=3D54dd1&token=3DCfDJ

to

 https://example.com/?userId=3D54dd1&token=3DCfDJ#/verify-email

Could it be a bug in the IERenderer?

Many thanks

Thomas

https://example.com/#/verify-email?userId=3D54dd1&token=3DCfDJ

The above line contains twice the "=3D" encoding (encoding a simple "=" ) which might be an undecoded part of the quoted-printable transport encoding applied to lots of email messages and should never show up as the clicked link nor in any kind of human readable display except for the raw message view (which you rather likely copied it from). Then there are certain kinds of characters which aren't allowed to show up in URLs and therefore need to be UTF-8 encoded (language independent character set) and percent or HTML entity escaped (for hiding non-ASCII or special HTML characters such as &char; ) - which we don't have an example of in your case. And - what IER does not least: Send them through a WinInet processing function called InternetCanonicalizeURL() for verifying its validity (and there's more). IOW: Can you please forward such a message (as unmodified attachment) either to my private address (which I know you know ) or to <beta-reports [@] pmail.gen.nz>, Thomas?

This way I can figure out which one of the verification or conversion attempts fails for what reason: I suppose it's the InternetCanonicalizeURL() function because the "hash" sign usually designates the final part of a URL, namely an intra-page URL like this one: https://www.w3.org/TR/html4/intro/intro.html#fragment-uri (its a working one actually explaining itself). Another candidate would be the Tidy module for fixing lots of common HTML issues one of which I already recently needed to patch.

TIA

Many thanks for your detailed reply Michael,

As you mentioned, I think that it might be related to some misinterpretation of the # (hash) in the link (Fragment identifiers)? I will send you the original email for more details for you to check.

By the way, where you able to reproduce my results with the URI given above?

I just tried it again and used that first sample link within PM and entered it through "Insert hyperlink into message" in the formatting section as the URL and some arbitrary text as the link description and sent the message to myself. And it indeed reproduced the results previously described above by moving the "#/verify-email" section to the back of the copied URI. (PS used a different client before to send for testing)

Thanks

Thomas

I didn't try since there are too many options to take into account. Thanks for submitting the test message, turned out to be the InternetCanonicalizeURL() function as expected although I did already take care of some similar issues before. I've now applied another adjustment keeping fingers off URLs being directed to further browser processing.

Decoding for human readable display won't be affected by this since I always kept these two options apart as you can tell by comparing the info tooltip display to the URLs being submitted to the browsers or clipboard (although the latter could be a matter of arguments since it's actually up to the users to determine what the clipboard contents are supposed to be used for). The tooltips at least are meant to provide a way for telling users whether there might be some kind of malicious redirection hidden by the various encodings being used.