On Fri, Sep 27, 2013 at 07:53:59PM +0000, Duncan wrote: > > WRT HTML malware, I suppose it's possible, but it seems that you would > > have to have pretty lax defaults for your browser and OS for that to > > really be a serious problem. I worry more about my email address > > leaking onto the Internet, and being deluged with offers to improve the > > size/function of my reproductive organs. > > With email, one of the tricks spammers use to verify an address is > sending an HTML mail that references an image on their site. [...] > This sort of tracker image is called a web bug.
Web bugs and HTML are not just good for verifying email address. There are all sorts of tricks people can do with HTML email. They can track when, and if, you open emails. They can't literally tell if you have read the email, but they can certainly tell when and how often you've opened it. They can implement "self-destructing emails", which can only be opened once, or which cannot be forwarded to others, or printed from the mail client. Or they can track who you forward emails to. There are free and commercial services which offer to do this: https://duckduckgo.com/q=email+tracking+service I discussed this on another mailing list recently: https://mail.python.org/pipermail/python-list/2013-August/654312.html And more here: https://mail.python.org/pipermail/python-list/2013-September/655332.html https://mail.python.org/pipermail/python-list/2013-September/655357.html In the second two, I talk about visiting websites. But of course the same applies to HTML mail. The technology is exactly the same, even the HTML renderer software is usually the same, only the front-end is different. If IE has a bug that lets a website install malware on your machine, so does Outlook which uses IE. [...] > Meanwhile, how many non-spam/non-malware messages actually NEED HTML to > deliver their message effectively? Don't mistake HTML (a technology) for the ability to use rich text (a function). Formatted text can be useful. We have bold and italics and superscripts and similar for a reason, they add information to text (or at least they *can* add information to text). In plain text, we're limited to pseudo-formatting using markup, which is second-quality at best. But there's no technical reason why formatted rich-text must be implemented by inefficient, insecure, user-hostile HTML. There are alternatives: - Web and news clients could be aware of markup standards such as ReST and Markdown, displaying (say) *italic* and **bold** using actual italic and bold. Or at least a subset of the markup. Pan already does this, in a very limited way, but doesn't support the full ReST or Markdown specification. [Aside: technically HTML is also a markup language, but it's too powerful, too verbose, and too hard to read to be a good standard for rich text.) ReST and Markdown are good choices because they are designed to look just like the ad hoc and intuitive pseudo-formatting people already use for plain text email: if your mail client doesn't support ReST, the marked-up text still looks good. - Another standard markup is TeX/LaTeX, which is probably the most powerful typesetting software around, but not exactly user-friendly or easy to read. - An existing email standard is Enriched Text: https://en.wikipedia.org/wiki/Enriched_text Alas, it is hardly supported by anything of note, and although it is more secure than HTML, it suffers from the same verbosity and is likewise difficult to read. Compare bold+italic text: Enriched text: <bold><italic>Something important!</italic></bold> ReST/Markdown: ***Something important!*** So there are options for rich text that don't involve HTML. Mail and news clients could include WYSIWYG editors that generated (say) ReST or Markdown text, and the user would never need deal with the markup commands themselves. They would just select a range of text and click the B button to format it bold. The recipient would see bold text if their client supported ReST, otherwise they would see **bold** text. -- Steven _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
