Show HN: Super Mail Forward, an HTML email that evolves as you forward it | Hacker News Reader

Show HN: Super Mail Forward, an HTML email that evolves as you forward it

medium.com

454 pointshteumeuleu65 comments

This is great for pranks: you send a serious looking email to someone, and then they forward it to someone else thinking they sent some chart or whatever but the next receiver instead sees another picture of your choosing

Or a new way to distribute spam? ;)

Or spearphishing. Send a secretary something that looks like a nice business proposal, then when she forwards it to her boss it's a link to some XSS attack.

Should be the other way around. You forward an email that's "obviously" spam, and then the abuse guys go "what do you mean, this is a regular project status update!"

you can use it to send "for your eyes only" stuff.

example: send an image to Mary and tell her not to send it to anyone else. She inevitably sends it to someone else, but the image magically changes to another image that says a message, maybe it says "DAMN IT MARY, I SAID DON'T SEND IT TO ANYONE ELSE!"

I'd replace it with "Mary's STD Test results" so the person who receives it will be very confused.

Trojan Phish.

Can't you do that just by changing the image at the url it points to?

I believe gmail downloads and caches images when it receives the email now.

Which is even better. You can change the image right after sending it, so anyone they send it to is guaranteed to get a different image.

That brings up an interesting question. Does GMail cache per-user or per-url? I would suspect the latter.

Would still work if they sent to a different email client.

TL;DR: A series of markup and styling hacks that exploit HTML interpretation quirks of various web email services can be hacked to intentionally vary message appearance between services. Coupled with forwarding, which further transforms the email using service-specific quirks, you can make a game where different paths of forwarding across services trigger different appearances.

Fun hack! I feel like there should be some clever practical applications but I'm drawing a blank.

> I feel like there should be some clever practical applications but I'm drawing a blank.

I wouldn't want to maintain any clever practical applications that break any time one of these web services subtly change the way they mangle HTML.

Fun is a good enough "application" for me! ;-)

One great application of this would be to hide the unsubscribe link if the email is forwarded.

no anti-pattern is ever "great".

I wouldn't call that an anti-pattern, it prevents people you forwarded the mail to from easily unsubscribing you from the mailing list. They aren't subscribed, they shouldn't be able to unsubscribe.

Would only work if the recipient you forward to has a different email provider.

> I feel like there should be some clever practical applications but I'm drawing a blank.

You could maybe make some sort of email analytics where you could guess the email client of the readers. Use a different background 1x1 gif image for each one then check your logs.

If you're in the email marketing business having to create and test email templates, this could actually be a very practical exercise and a team building game at the same time, I think. These bugs are a serious pain point sometimes for folks on deadlines. I could see making a sort of perpetual internal game out of this to make the job more fun and incentivize documenting new bugs found.

It would be extremely useful for email invitations which change the action when forwarded.

If it worked on all email clients.

I remember reading Silicon Valley company being frustrated with whatever emails they had sent on company policy being forwarded to journalists (Kara Swisher??) . One hack they came up with was to slightly reword every email slightly to identify who did it.

Maybe - this solution would help in figuring out who the leakers are!

That's a classic canary trap. [0]

[0] https://en.wikipedia.org/wiki/Canary_trap

More than anything, this thing shows the sad situation of CSS support in different email clients.

Sad situation? I'd say it's limited for security and user comfort. I can't say I've ever felt HTML emails beyond basic text formatting and links improved my life.

How is Gmail not supporting 'box-shadow' or ignoring 'display: none;' but allowing 'display: none !important;' a security feature? Not supporting classes? Why does AOL messes with inline URLs (so that they stop working)?

This article is full of examples that are obviously bugs. And worst - it's all neither documented nor standardised.

And then there's Outlook. My quality of life is so much better since I left the email marketing industry.

Although I agree with you, I generally should trust my email provider to not mess with my email, however I choose to receive it.

Sure, html email is annoying, but let there be a flag or option for the user to decide to display it or not.

There are some good reasons why email clients do modify HTML: security is one, but they also have to make sure malformed HTML can't break the rest of the page. There are also reasons why they don't publish clear documentation on what they do to it, but this mostly means huge headaches for anyone who tries to create HTML email.

> they also have to make sure malformed HTML can't break the rest of the page

    <iframe src="/actual/email"></iframe>

Changes what you can then do with the email. If you want to hide quoted or let users select specific text for forwards, you're SOL.

As long as they're on the same domain, you should be able to reach into the child iframe. Used to be a common technique for handling file upload progress before AJAX support for uploading became commonplace.

The child can reach up to the parent via JS, too, but you'd want to sanitize any JS in an email anyways.

Anyone who doesn't do this is asking for trouble

Please, add a sandbox attribute on your iframes. I have outlined the reason for this below.

> they also have to make sure malformed HTML can't break the rest of the page

What do you mean? That's the point of iframe, so the email content cannot break email. We have object urls[1], and it's really not super hard to put emails into a different url to simply iframe src="" it.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Blob

My first thought it that you may be looking at what is feasible today vs what was feasible for email clients (web or client) since they've been supporting HTML email. Email has been around a long time, and thinking of email as being a vector for security concerns has been a topic for even longer than consideration of browsers as a security concern because while you can "be smart" about where you browse, you can't "be smart" about what email you receive. Email that positions elements over portions of the email client or screen scrapes your email is a big deal, obviously.

Also, I am not saying that this was the only way to mitigate this risk (Apple Mail seems to pretty much use an iframe in their client, whereas other email clients still munge the HTML (Outlook, Eudora, Lotus, etc). But it is the way that many did choose, and I can understand why whether or not I agree with how they did it.

iframes have a number of real world usability problems. One example is that iOS ignores any sizing of the iframe, automatically growing it to fit its content, which could easily mangle the rest of your layout.

This is sadly misinformed. Having had to create business emails in the past, it's frankly a nightmare, and I can't agree with anyone who doesn't see that.

Having a universally implemented, and uniformly implemented, limited subset of CSS would actually improve the situation for you.

I could say the same thing about the web itself.

Leaving Javascript out of email is just good sense. Leaving full support for HTML+CSS is not.

"Limited" is OK. Inconsistent across mail apps is bad.

One challenge many services face when sending emails is that you often want to log a user into the account if they've clicked in from an email – after all, if they have access to the email account, they can usually reset the password.

But the rub is always the propensity for users to forward on those same emails. If they do, then the second recipient gets control of the first recipient's account, and that's rarely the intention of the first recipient/forwarder.

I haven't had a chance to dive in enough, but I wonder if a technique like this could effectively swap tokenized links with generic links (even if you're just swapping 'display' rules) when a message is forwarded. You might have to use different message style/markup output depending on which service you're sending the message to, but my read of this article is that it's not a ridiculous thought.

Ironically, Lotus Notes Webmail is the only client I have seen so far that actually uses iframes to display HTML emails. If webmails just could embed the HTML content into an iframe with the proper sandbox attributes... nods off and dreams

Wow, you could embed entire videos with the data: uri, or run entire web apps with inline javascript with Lotus Notes if they don't sanitize it. Or completely breach their privacy by scanning their LAN for webcam URLs or taking screenshots with WebGL textures using Nvidia driver bugs... nods off and dreams

Isn't that something any website can do right now?

I don't know if you can take advantage of the random Nvidia texture leak in Linux with WebGL (I've seen it done with OpenGL), but yes. Internet users typically need to have at least some trust in the sites they visit because indeed, bad sites can do bad things to your privacy.

No, that doesn't work with proper sandbox attribute. To quote w3schools (http://www.w3schools.com/tags/att_iframe_sandbox.asp):

When the sandbox attribute is present, and it will:

* treat the content as being from a unique origin

* block form submission

* block script execution

* disable APIs

* prevent links from targeting other browsing contexts

* prevent content from using plugins (through <embed>, <object>, <applet>, or other)

* prevent the content to navigate its top-level browsing context

* block automatically triggered features (such as automatically playing a video or automatically focusing a form control)

I'd say alone blocking scripts, form submits, preventing links to change other contents and checking if there's behavior stuff in the CSS (which facilitates Javascript injection) is enough to have a secure webmail display. Responsive webmails \o/

Interesting, I wasn't aware of this.

Oh man, that is a dream. I had no idea that this was a thing. Too bad iframes themselves are kind of tricky to size correctly or I'd be using this willy-nilly. Skip sanitizing HTML and use a full sandboxed HTML iFrame for every comment on a user forum!

> Too bad iframes themselves are kind of tricky to size correctly

You could use an injected JS (postMessage with the iframe window height) and update the iframe height from the outside. And for the content you should just strip any script tags so you can safely allow scripting.

You should strip script tags in any case so that someone cannot use an API call which outputs raw comments as a delivery vector.

Also, you're putting users without sandbox attribute support on risk of being exploited... so you'd have to switch between two paths for display.

> Also, you're putting users without sandbox attribute support on risk of being exploited... so you'd have to switch between two paths for display.

An evil part of me considers that a feature, not a bug.

And as for stripping script tags, I'm always reminded of this story:

http://blog.codinghorror.com/protecting-your-cookies-httponl...

Does this prevent a page from positioning an element over another element, outside of its frame?

This would be great for an email marketing campaign. You could probably get a lot of people to refer their friends just for the opportunity to see some cool animation or graphics.

HTML email made me think of IE6 as the iPhone 6. The rendering engines on most clients are horrible.

tbh Thunderbird is the only standalone mail client using a full-featured browser engine as backend. Even Outlook uses a castrated-beyond-belief IE.

Some versions of Outlook use the even worse MS Word engine.

This is a really interesting hack.

I love things that exploit the oddities of the landscape to do artsy/funky things; far more interesting than finding yet another way to trick someone into installing a password stealer.

This reminds me of the old concept of "tab damage"[1] on usenet/mailing lists. People used to leave little "devices" in their signatures that based on this that would point to the number of times a message had been forwarded or quoted, because client software would typically indent the quoted message.

[1] http://linuxmafia.com/~rick/afw/#tabdamage

This can leak the user's client by changing links per client.

Make a link per identifiable client, show only the one for the current client, and give each link a post/get parameter identifying the client. Quite easy to do, but a lot of work to have broad client support.

Tada! I now know you read your email on your [obscure and bugged client], which is susceptible to [this and that exploit].

Why not just insert the exploit into the first email? What do you gain by identifying the client?

This is an exploit as well, just a different kind. It doesn't require any programming errors in the clients, instead it relies on the non-standardization of clients.

Wow, this was a very creative use of forwarding.

Nice work here and also nice post about the Brave thing and internet business model on your site btw. I agree 100%.

That, sir, is totally awesome. Well played.

Reply on news.ycombinator.com