Impossible to use URL protocols in anchors

Mail
1

When I insert a link with any URL protocol except these:

  • http:
  • https:
  • mailto:
    It gets removed. Specifically, HREF property gets wiped.

And it should not. There are enough useful protocols that can be used. Like:

However, this affects saved messages and snippets. E.g. if I insert an anchor with tel: and send the message right away, it will not be cut for the receiver (even though it will be removed in my Sent folder). But this just makes even more difficult to use signature templates, because I want to have these links added automatically.

I’d like these to be handled properly. If HTML filter removes stuff from my original message on saving or sending a message, I’d also like to be aware of that. Ideally, I’d like to configure this filter so it doesn’t remove stuff without my consent, of course.

2

What version of eM Client are you using Andrew, and how are you inserting the link into the message?

I am not able to reproduce this and it always works just fine whether done manually when creating a new message, or when used in a template or signature.

This is the link I used to test: 1-562-867-5309

This is what appeared in the sent message in my Sent folder after sending:

The link behind the number is 1-562-867-5309 You can view that by right-click on the message and choosing View mail source.

This is what appears in the received message verified using the web interface for the provider:

The link on the number is again  1-562-867-5309

So the sent and received messages are the same. eM Client changed the a href= to a href=3D but that does not make any difference. It still works as it should.

3

I’m using latest 7.2.38715.0 on Windows.

Note that in your Sent folder, the link is displayed just as a blue text, and it’s not clickable. Compared to how it’s displayed in received form, it’s completely different.
As you said, the code is somehow still there if you go to  View mail source.

However, note that if you do not send the message right away, but instead save it as a draft and come back to it later, you will be left with just blue text. Just 1-562-867-5309.

Then, note that the same thing happens when you use signature. If you insert 1-562-867-5309 in a signature that is used by default, then create a new message, it will be inserted just as a blue text. Just  1-562-867-5309.

So, I may insert a collection of custom links in my signature in hopes they will be clickable for the receiver, but in the end only http: and mailto: are clickable. The same thing I can see in any draft where such a signature was added.

How it should work, in my understanding:

  • There should be no functional differences in “View mail source” and “Edit source” contents.
  • No URL protocol should be filtered out at any level, or there should be an option for controlling such behavior.

I hope my description is good enough.

4

I am not seeing that with drafts. The link as I inserted it is still there as it should be.

You still did not say how you are adding the link to your message. That may be the issue.

Also, please don’t confuse eM Client’s ability to create correct links with it’s inability to open some links. The link created as I described above is correct, and can be opened with a web mail interface. Some email clients, like eM Client, cannot open these links, so that may just be the issue.

5

Okay I’ll try to explain in detail.

I create a signature using Edit source function. Here is how it looks like

Then I set up this signature to be my default signature:

I create a new message, input my own address in To field. The signature appears not clickable. If I open Edit source, this is what I see:

I send it like this. I don’t change anything in the contents. Here is what I get in my inbox:

As you can see, it came without HREF attribute. This means there is no link, and it can’t be clickable, under any client.

There is a workaround: when I create a message, I must choose my signature again from Signature menu, even though it was inserted automatically by default. When I do so, this is how it looks like (it’s clickable):

(Note that at this point, if I don’t send the message but save it as a draft, then the workaround has to be used again before sending, or else it will look exactly like the first example - without HREF attribute. Both in sent and inbox folders.)

After sending with such a workaround applied, here is what I get in my inbox:

In this case, even though it appears not clickable, the HREF attribute is present.

If I send such a message to a different client, e.g. Gmail, the link is clickable. This is what I want. But to achieve this, I have to:

  • Choose my signature again every time I create a message.
  • Choose my signature again every time I continue editing an old message from draft.

Which is not convenient.

As for why it’s not clickable in eM Client, I guess this is a whole different story, which deserves a separate discussion. I believe it should be clickable, like with any other client where such links are clickable. More points:

  • You mentioned the eM’s “inability to open some links”. I can’t accept this statement because (1) regular http/mailto links are clickable, and (2) any link can be clickable in the editor, and it all works. This is not an inability, but a programmed behavior.
  • Any security concerns about making some links not clickable are illogical because eM doesn’t block unsafe attachments. It just lets the user know about possible danger, which should have been used with clickable links too instead.
  • Not providing even an option to enable the expected behavior (clickable links) is a problem.

My guess though, is that it’s still related, because it seems like a source of this problem: if you disable this filtering, both the receiver would get clickable links as expected, and I would see clickable links in my sent messages.

6

eM Client had some issues with clicking non-standard or newer format links in the received message body in the past. I remember some threads on this forum about linked content from some clothing retailers that used different url formats. It may be that these newer types of links had just not caught up with eM Client’s developers. eM Client is not alone in this, as there are other clients that suffer the same issues. Fortunately some community developed projects like Thunderbird try to keep up with current trends, and web mail interfaces always have tried to do the same, so there is an alternative option for the receiver of such messages if this is a regular problem.

But why eM Client is changing the html on your automatically inserted signatures is something you would have to take up with eM Client Inc. as there is really nothing that other users on this forum will be able to change to make it work for you.

If you use eM Client for business, best is to make use of your Pro License VIP Support option. They will be able to assist you further, or at least get the issue logged with the developers.

If you have a Free License, this may just be one of those little inconvenient issues you will have to live with while you get an otherwise excellent email client for your personal use.

7

Thanks I may try that. But I don’t think your understanding of the issue is correct. It’s not about trends and not catching up. It’s about supporting standards. URL protocols for HTML anchors are all standard. There is no way a programmer should treat tel:, https: or skype: in different ways. It’s all up to OS to decide what to do with them. In this case, a client application just tampers with HTML code in a way that removes HREF attribute in many cases, so it’s definitely a client application issue.

8

But best you take it up with eM Client. We are all just users here, so no need to go any further with this.

9

We started filtering the link URLs due to security issue that was reported to us. I understand we may have been overly cautious with the whitelisted protocols and we will tweak it to allow more of the protocols in a future update but it’s gonna be a whitelist nonetheless.

We rely on several levels of protection for security attacks, one is a built-in sandboxing of the Chromium browser engine, other one is pre-filtering of the content for problematic CSS, HTML or scripting patterns. We don’t filter the content when it is saved or sent but we do filter it when it’s loaded into the editor. That’s why repeated opening and saving triggers the filtering.

The reason for filtering in message/template/signature editor is one specific attack vector. It was an email message that appeared normal when received. The Chromium sandboxing properly blocked the attack. However, when one replied to the message it ended up in slightly different sandbox configuration where obscure CSS or SVG pattern could trigger the “href” to be opened without user interaction. We fixed the particular attack vector by tweaking multiple levels of the protection but out of abundance of caution we also switched to much stricter filtering.

10

To make it clear, the intention of the filtering is not to strip custom URL protocols on content you are authoring. It is just difficult to do it properly on mixed content like replies to an existing email. The new message is original message content (which is treated as untrusted and unsafe) that is interleaved with your new content and signatures (treated as trusted). Once the message is saved as a draft and reopened the trusted and untrusted parts of the message cannot be easily distinguished.

We are continually working to improve this experience without compromising security. However, in some cases we were forced to tip the balance toward protecting the user with a quick fix that may not have covered all the edge cases.

11

Thanks for the response. I understand the difficulties.

If you prefer whitelisting, that’s fine by me. I hope the relatively popular social app protocols are going to be included.

Still, is it possible to also provide some option to disable this kind of filtering? The inability to click a safe link and discrepancies between the message source and the output are rather confusing. As an additional measure, what about detecting any click on a link with unknown or unwanted protocol and asking the user if he knows what he is doing? Just like with opening attachments.

12

> Still, is it possible to also provide some option to disable this kind of filtering?

We do not plan an option to disable it. It is security measure. We will look into any case where the filtering may cause confusion or unpredictable behavior though.

> As an additional measure, what about detecting any click on a link with unknown or unwanted protocol and asking the user if he knows what he is doing?

We already do that for some URLs like those pointing to shared disks (used in some companies in internal communication) and we fully intend to do it for more of these URLs.

The issue is, however, that it was possible to create specially crafted HTML code where the Chromium engine opened the URL without user interaction or clicking the link at all. While we would most certainly be able to intercept that it would still be confusing to ask the user to open something that they didn’t click on. Unfortunately I cannot share the exact details of the issue unless it gets published on a public vulnerability list (CVE). While all up-to-date public builds of eM Client have been patched it is an issue that may affect other vendors and it is up to the security researches to disclose it.