When sending an email containing a local link (i.e. file:///X:/scripts/out/find-missing-url.result.txt), I have to ensure, by editing the source, that it is not an anchor <A> and it is only under a <DIV> element. Sending like this, the link is clickable.
P.S. By the way, it seems that HTML injection is possible using the forum. I realized this because at first I wrote the “<” literally and it was treated as HTML. So changed it to be an HTML encoded version.
There is no way that the application can know that the message is internal, nor is there a way the application can know that the recipient has scripts also mapped to X:. So the link is not clickable because it refers to a local file on your device.
And what is the expectation when the message is received by a user with a Mac, even if he is sitting next to you in the office? That link is never going to work for him, even if you alter it as you suggest.
I will try to clarify the situation, but first of all, I would like to say that I am a senior software engineer and I know the issue is located within the software. Why I know this? Because there are two behaviors depending on how I send it.
The link sent is using the file protocol using an URI of the format: file:///X:/PATH_TO_FILE/FILENAME.EXTENSION
The path is a mapped drive that is accessible on all computers of our local network (hence the internal message said previously). So, the accessibility of the file is not an issue.
Methods used to send:
Using Insert link menu where I enter the same thing for URL and NAME (file protocol link).
– The link is clickable when writing the email using CTRL+CLICK, but it is not when receiving it. Even if the <A …> is correct when looking at the source of the email.
Using Insert link menu where I enter the URL as file protocol link and NAME as another value (i.e. file to check).
– Same result as previous method.
Copy/paste the file protocol link into the email and then hitting Enter.
– Editing the source before sending tells me the href attribute is not set correctly, but even if it was, it is still not clickable when received.
Any of the method above, but Editing the source before sending the email to remove all HTML codes to give something like "<DIV …>file:///X:/MY_PATH/MYFILE</DIV>.
– Now, the received email is showing a clickable link on the file. Moreover, EmClient is asking if I am sure to open the link because it is a local one. Answering yes, opens the file.
Hoping I was really clear. I don’t want any EmClient user support for this issue. I would like the bug to be reported to the development team.
The reason is that there’s simply no valid use case for URLs such as file:///x:/path/to/the%20file.txt since each recipient may have the drive letter mapped differently even when used inside the same organization.
We do allow file URLs pointing to shared disks that use the UNC format of the URL, eg. file://hostname/path/to/the%20file.txt.
Agree with @Gary this is not a bug. Mailers are “not normally” meant to share LAN URL’s that way.
However on sharing a Local LAN directory or Local LAN files links if using a eg: Windows PC via eM Client or “any other mailer” is that when i insert a “Link” i do it this way “which works” for me -
When you do then open the LAN link in the email, you will get the Open Dangerous “security warning” dialogue box in eM Client as per below example, but that’s normal being its a LAN local folder or file.
I’m following up on this older discussion. I agree with Master_DJon. Gary I think you are wrong with your argument. For our customers, users within the internal LAN use the same letter for the network drive of the main data structure. As part of the information sent, the Secretariat sends links to folders within the data structure where the necessary documents are stored. With Outlook, users are used to clicking on a link and opening a folder from a network drive. It’s not possible with emclient, or at least not easily…how to explain to the assistant to replace the drive letter in the link with a UNC path that she doesn’t even know?
They purchased Emclient and are having a problem with it because of this functionality.
At least as an option to turn on this functionality.
There are a lot of email that are sent within the same network which computers have the same configuration. So, at least just say, “we don’t want to implement this” instead of a pale argument like this. The intended usage and novel usage may not be the same, but as software developers, we shall always consider both.