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
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.
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.
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!
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.
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
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.
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.
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].
[+] [-] ldom22|10 years ago|reply
[+] [-] myztic|10 years ago|reply
[+] [-] Houshalter|10 years ago|reply
[+] [-] shimon|10 years ago|reply
Fun hack! I feel like there should be some clever practical applications but I'm drawing a blank.
[+] [-] lassejansen|10 years ago|reply
[+] [-] avian|10 years ago|reply
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.
[+] [-] hk__2|10 years ago|reply
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.
[+] [-] drvdevd|10 years ago|reply
[+] [-] rogeryu|10 years ago|reply
[+] [-] nrao123|10 years ago|reply
Maybe - this solution would help in figuring out who the leakers are!
[+] [-] andrei_says_|10 years ago|reply
If it worked on all email clients.
[+] [-] yoavm|10 years ago|reply
[+] [-] Latty|10 years ago|reply
[+] [-] whafro|10 years ago|reply
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.
[+] [-] mschuster91|10 years ago|reply
[+] [-] vortico|10 years ago|reply
[+] [-] rosalinekarr|10 years ago|reply
[+] [-] SatoshiRoberts|10 years ago|reply
[+] [-] mschuster91|10 years ago|reply
[+] [-] __jal|10 years ago|reply
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.
[+] [-] tdeck|10 years ago|reply
[1] http://linuxmafia.com/~rick/afw/#tabdamage
[+] [-] kecks|10 years ago|reply
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].
[+] [-] Houshalter|10 years ago|reply
[+] [-] Pranz|10 years ago|reply
[+] [-] rorykoehler|10 years ago|reply
[+] [-] alch-|10 years ago|reply