5 ms·

I'll address more of your comment later, but for now let's start here: >Only an issue if the client rolls their own HTML renderer. Outlook uses the IE Trident

I'll address more of your comment later, but for now let's start here: >Only an issue if the client rolls their own HTML renderer. Outlook uses the IE Trident Engine, Thunderbird uses Firefox' engine, Gmail transforms using the Chromium engine internally. That means the email client is usually as secure as the respective browser, unless you use a mail client that rolls their own engine. This is not true. You can't just drop a modern web browser into an email client and have it magically be secure - if you do, your client will be broken and insecure. A huge number of browser features have to be removed - loading external images, stylesheets. scripts, images in stylesheets (except datas URLs, so add a special codepath for that). Things like animations aren't desirable, nor forms, etc. The list of things you have to turn off is huge and getting longer with each browser release. And you had better keep up with those releases, as each one fixes a half dozen security bugs which are inevitable in a technology whose specification alone is a million lines.

zaarn 7y ago
That stuff is actually not that hard, mozilla's engine has compile flags for that stuff and the patches you have to make are minimal. There are a few methods for runtime restrictions too, they're quite extensive in their capabilities and sufficient for sandboxing a mail.
- Sir_Cmpwn 7y ago
  Mozilla's engine is a giant multi-million lines-of-code ball of C++ and Rust and JavaScript weighing in at nearly 200 MiB - not including dependencies. And what if I don't want to support the browser monoculture? Implementing a new one is a daunting task (nigh impossible), but rendering plaintext is easy peasy. Mutt is 1 megabyte.
  - yyyk 7y ago
    HTML email in practice doesn't need much more than what w3m supports, in some places less - no need for w3m's frame, cookie, or FTP support. w3m is smaller than mutt. Limiting HTML mail to an agreed subset could actually be a winnable fight compared to more impractical suggestions.
    - Sir_Cmpwn 7y ago
      As someone who uses w3m to read HTML emails sometimes, it's very hit and miss. Perhaps 50% of emails are easily readable in w3m, on a good day.
      - yyyk 7y ago
        Let's say 50% (or even 30%). How much more code would have been needed to correctly render most of the rest? I strongly doubt it's 200 MiB, probably much closer to w3m's size. HTML email is in practice a large subst of HTML4+a tiny bit of CSS.

zaarn 7y ago

That stuff is actually not that hard, mozilla's engine has compile flags for that stuff and the patches you have to make are minimal. There are a few methods for runtime restrictions too, they're quite extensive in their capabilities and sufficient for sandboxing a mail.

Sir_Cmpwn 7y ago
Mozilla's engine is a giant multi-million lines-of-code ball of C++ and Rust and JavaScript weighing in at nearly 200 MiB - not including dependencies. And what if I don't want to support the browser monoculture? Implementing a new one is a daunting task (nigh impossible), but rendering plaintext is easy peasy. Mutt is 1 megabyte.
- yyyk 7y ago
  HTML email in practice doesn't need much more than what w3m supports, in some places less - no need for w3m's frame, cookie, or FTP support. w3m is smaller than mutt. Limiting HTML mail to an agreed subset could actually be a winnable fight compared to more impractical suggestions.
  - Sir_Cmpwn 7y ago
    As someone who uses w3m to read HTML emails sometimes, it's very hit and miss. Perhaps 50% of emails are easily readable in w3m, on a good day.
    - yyyk 7y ago
      Let's say 50% (or even 30%). How much more code would have been needed to correctly render most of the rest? I strongly doubt it's 200 MiB, probably much closer to w3m's size. HTML email is in practice a large subst of HTML4+a tiny bit of CSS.