Why links and images in a briefing arrive defused

Relayed text is someone else's words. Images that would fetch a URL are removed. Markdown links become readable text. Mail clients cannot auto-link a bare URL the sender planted. Ordinary comparisons like a < b survive.

3 min read

A briefing is written by one assistant, or one person, and read by another. The reader did not choose those words. Anything in them that fetches, executes, or quietly phones home is a channel the sender should not have.

So RelayLink defuses the text before it reaches an assistant, an email, or the package page. It does not "clean it up" into nicer HTML. It makes it inert.

What gets removed

Images. ![alt](https://…) and the reference-style forms. A client that rendered those would fetch a URL the sender chose, at the moment the briefing was opened — the same shape as a tracking pixel. They become [image removed: …].

HTML tags and autolinks. <img …>, <script>, <https://evil> lose their angle brackets and survive as text. A comparison like a < b is left alone: the check only fires when the next character looks like a tag or a URL scheme.

Link definitions. The [id]: https://… lines that make reference links resolve. Kill those and a form we missed cannot still fetch.

Control characters go. Newlines stay — this is prose, and a note with paragraphs is the point. (A listing that prints one record as labelled lines is a different surface: there, a newline in a sender-chosen field is a forged header. That stripping happens where the listing is built, not here.)

A markdown link [label](url) becomes label (url) — readable, not clickable as markup.

Email goes one step further. Mail clients auto-link anything that looks like a URL. A bare https://… the sender planted would become a blue click that is not ours. Those are rewritten so they will not linkify. The only intentionally clickable URL in a RelayLink email is the package link the template adds after this runs.

Two renderers, on purpose

The package page is the one HTML sink. Every field is encoded. Combined with a policy that serves no script on that page, relayed content cannot execute or auto-fetch.

The assistant and the email see the neutralized markdown. They do not get a second pass through a blog-style HTML renderer. That pipeline exists for guides we wrote and reviewed. Routing a stranger's briefing through it would turn ![x](url) into a live image.

We also do not entity-encode here. Encoding is the web page's job. Doing it twice would show &amp; to the assistant and mangle the page.

What this is not

It is not a spam filter. It is not a judgement that your URL is bad. It is a rule about who chose the fetch. RelayLink's own links — the package page, sign-in, the setup guide — are added by RelayLink. Yours arrive as words.

If you need the other person to open a document, say so in the note and put the address in plain text. They can copy it. That is slower than a live image. It is also not a beacon.

Tags features security email packages

Frequently asked questions

Can I put a screenshot in a briefing?
Not as a live image. A markdown image would make the recipient's client fetch a URL you chose — that is a tracking pixel with an alt tag. The image is replaced with a short "removed" note. Describe the picture, or put it somewhere the recipient already trusts.
Will my link still be readable?
Yes. A markdown link becomes "label (url)" as text. In email, a bare http URL is rewritten so a mail client will not turn it into a click. The only link in that mail that is meant to be clicked is RelayLink's own package link.
Why not turn the briefing into HTML?
The web page encodes every field. The assistant and the email see markdown or plain text. A markdown-to-HTML renderer on the package page would turn inert text like ![x](url) into a live fetch. That is the one thing this product must not do with someone else's words.

Related articles