Re: [Pan-users] HTML posting Was: Should "Go Next Watched Article" work?

[Steven D'Aprano]

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