3 ms·

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.

by JoBrad 11y ago

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.

ceejayoz 11y ago
> they also have to make sure malformed HTML can't break the rest of the page <iframe src="/actual/email"></iframe>
- azinman2 11y ago
  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.
  - ceejayoz 11y ago
    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.
- livingparadox 11y ago
  Anyone who doesn't do this is asking for trouble
- mschuster91 11y ago
  Please, add a sandbox attribute on your iframes. I have outlined the reason for this below.
tehlike 11y ago
> 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 https://developer.mozilla.org/en-US/docs/Web/API/Blob
- JoBrad 11y ago
  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.
- tempestn 11y ago
  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.

by JoBrad 11y ago

ceejayoz 11y ago

> they also have to make sure malformed HTML can't break the rest of the page <iframe src="/actual/email"></iframe>

azinman2 11y ago
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.
- ceejayoz 11y ago
  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.
livingparadox 11y ago
Anyone who doesn't do this is asking for trouble
mschuster91 11y ago
Please, add a sandbox attribute on your iframes. I have outlined the reason for this below.

tehlike 11y ago

> 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 https://developer.mozilla.org/en-US/docs/Web/API/Blob

JoBrad 11y ago
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.
tempestn 11y ago
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.