Mailspring: Scripts in email alter (break) the clients layout

Created on 6 Oct 2017  路  5Comments  路  Source: Foundry376/Mailspring

Are there any related issues?


No

What operating system are you using?

MacOs Sierra 10.12.6

What version of Mailspring are you using?

Version 1.0.1 (1.0.1)

Bug?
Yes

Do you have any third-party plugins installed? If so, which ones?

No, clean install

Is the issue related to a specific email provider (Gmail, Exchange, etc.)?

No

Is the issue reproducible with a particular attachment, message, signature, etc?


Yes.

  1. Go to https://www.emailprivacytester.com/
  2. Enter email and click on send
  3. Click on the confirm Link
  4. An email is sent to your Email-Account with a variety of tracking techniques, including javascript and other scripts to test your mail client for privacy leaks (does client load remote content, etc)
  5. Result: The layout of Mailspring is broken, the header bar is moved out of the screen, white space occurs at the end of the window. See Screenshot.

The contents of an email should NEVER alter the mail client in any way.

broken_layout
no_top_bar_white_space_bottom
notop_bottom

bug done-pending-release

All 5 comments

Hey! Ahh this tool is great鈥攖hanks for filing this. I wasn't able to get the test email when I put in Office 365 or Gmail accounts, but I just tested with a yahoo account and actually received the email. I've been able to reproduce here so I'll see how this is happening.

Hey鈥攋ust a quick update:

  • Digging into this a bit more, the message isn't executing any JavaScript or adding any styles to the client. (phew...) It contains a broken <object> tag though, and somehow rendering the object tag is causing Chromium to re-layout the page with white space at the bottom. (Deleting a DOM node and then undoing the change in the Developer Tools makes it layout again and everything goes back to normal.) I'm definitely going to fix this, but it doesn't appear to be a security issue as much as a rendering bug.

  • By default, firing all those tracking pixels is intended behavior. That said, even if you turn off the "automatically load images" option, Mailspring still fires the "object tag data" event back to emailprivacytester.com. With "automatically load images" unchecked, that's the only one that still turns red. Technically I suppose this isn't an image, but I think that checkbox should disable all tracking, not just image based tracking, so I'm gonna fix that as well.

image

Thank you very much!

but I think that checkbox should disable all tracking, not just image based tracking, so I'm gonna fix that as well.

Very good, you are the first developer of an email client who actually sees this privacy issue. I wrote to some developers of mail clients and they never fixed this and ignored my requests fixing this kind of issue. Sometimes I even had a discussion going resulting in a long email conversation without any success.
Nice to see that the developers of this awesome mail client care and try to block spammers out. The existence and use of an email is checked by spammers with these kind of tricks emailprivacychecker tests against your email client.

Thank you very much for this awesome mail client and the response!

This should be fixed鈥擨 did a bunch of googling and it looks like there's really no legitimate reason for HTML emails to include tags. Just people trying to play video in email or do weird tracking tricks like the one identified here. I've removed <object> from the HTML sanitizer whitelist and confirmed that the layout issue no longer happens and the "Automatically load images" option correctly blocks all tracking now.

This broke interactive SVG support. Was this an intended change?

Was this page helpful?
0 / 5 - 0 ratings