Subject: Re: HTML for email (was: Re: document writing/editing tools used by IETF)

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 1 Mar 2021 09:22:00 -0500

Yes HTML is a disaster for email. But so is plaintext wrapped at 66
characters by the server because people didn't know better.

The reasons HTML is a disaster are

1) There is no standard for HTML in email.
2) HTML has been turned into a presentation format.
3) Email messages used annotations for a decade before HTML which doesn't
support them
4) The SMTP email infrastructure does not provide a viable means of knowing
what formats are accepted by a recipient so there is no way to fix this.

One painful side effect of 1 and 2 is that messages come with embedded font
size specifiers which is beyond stupid. The sender has no idea what device
I am reading something on. But Gmail will happily chose font size settings
that are frequently stupid. I have no control over that as a user.

But the last point is the most important because the difficulty of fixing
the SMTP infrastructure has become greater than the difficulty of replacing
it with something fit for purpose.

Of course the world is not going to move to something new overnight. But I
do have a plan.

On Mon, Mar 1, 2021 at 12:06 AM Keith Moore <[email-masked]>
wrote:

> On 2/27/21 10:00 PM, John Levine wrote:
>
> > Indeed, but that was many decades ago. There are some ways in which the
> > IETF is cutting edge, some in which we are amusingly backward. Most
> > of the people I deal with can send an e-mail that says "I highlighted
> > the changes in yellow" and all of their correspondents see the yellow
> > text. Try that here. Remember that MIME was invented in the IETF and
> > HTML down the virtual hall from here, both about 30 years ago.
> Ok, but to be fair: HTML is a disaster for email.   Way back in the
> mid-1990s most of us thought it would work out ok, and more likely to
> succeed than text/richtext.   But we didn't really take the time to
> understand the nature of the problem in either case.    It's hard to
> write a good html editor for email, especially one that handles inline
> replies properly, and every single HTML editor for email I know of
> botches this.    Accidentally delete the line or invisible space before
> or after a change in format and it's likely to completely mess up your
> formatting, say by merging one correspondent's text with another.  HTML
> doesn't handle annotations well either because (gasp) text messages are
> not naturally hierarchical like HTML (and its *ML predecessors) expect
> them to be.   HTML hasn't exactly been a stable target either, and
> there's lots of variation among MUAs regarding which features are
> supported. It's hard to send an email message that looks more-or-less
> the same to every recipient.
>
> (And, IMO unfortunately, a lot of MUAs take liberties with presentation
> of email messages, which only exacerbates the above problems.)
>
> At the same time HTML is so widely deployed that it's very hard to
> deploy something that works better.
>
> The specific behavior you cite above is actually due to a failure of
> standardization, because the vast majority of Big Corporate environments
> have settled on 1 of about 2 email products overall.   Highlighting text
> in yellow doesn't work as well in IETF because IETF participants are
> (fortunately) still more diverse than Big Corporate employees.
>
> Keith
>
>
>

---

From: tom petch <[email-masked]>
Date: Mon, 1 Mar 2021 17:24:48 +0000

> what formats are accepted by a recipient so there is no way to fix this.

And breaks privacy.  I find it ironic that the IETF seems to devote 
forests to combating a slight possibility of privacy being impaired, 
something that I see bordering on an obsession, but actively supports 
HTML e-mail which drives a coach and horses through privacy.

I now find web mail servers which will not let me view e-mail in plain 
text (which I assume is because they want to harvest as much personal 
data from me as possible).

Tom Petch

---

From: Larry Masinter <[email-masked]>
Date: Mon, 1 Mar 2021 09:31:06 -0800

There's been no interest in the email community for defining a "for email" profile of HTML and multipart/related (or WPACK).
Why is that?

--
https://LarryMasinter.net https://interlisp.org

> -----Original Message-----
> From: ietf <[email-masked]> On Behalf Of tom petch
> Sent: Monday, March 1, 2021 9:25 AM
> To: Phillip Hallam-Baker <[email-masked]>; Keith Moore
> <[email-masked]>
> Cc: IETF Discussion Mailing List <[email-masked]>
> Subject: Re: HTML for email
> 
> > 3) Email messages used annotations for a decade before HTML which
> > doesn't support them
> > 4) The SMTP email infrastructure does not provide a viable means of
> > knowing what formats are accepted by a recipient so there is no way to fix
> this.
> 
> And breaks privacy.  I find it ironic that the IETF seems to devote forests to
> combating a slight possibility of privacy being impaired, something that I see
> bordering on an obsession, but actively supports HTML e-mail which drives a
> coach and horses through privacy.
> 
> I now find web mail servers which will not let me view e-mail in plain text
> (which I assume is because they want to harvest as much personal data from
> me as possible).
> 
> Tom Petch
> 
> 
> > One painful side effect of 1 and 2 is that messages come with embedded
> > font size specifiers which is beyond stupid. The sender has no idea
> > what device I am reading something on. But Gmail will happily chose
> > font size settings that are frequently stupid. I have no control over that as a
> user.
> >
> > But the last point is the most important because the difficulty of
> > fixing the SMTP infrastructure has become greater than the difficulty
> > of replacing it with something fit for purpose.
> >
> > Of course the world is not going to move to something new overnight.
> > But I do have a plan.
> >
> >
> >
> >
> >>> Indeed, but that was many decades ago. There are some ways in which
> >>> the IETF is cutting edge, some in which we are amusingly backward.
> >>> Most of the people I deal with can send an e-mail that says "I
> >>> highlighted the changes in yellow" and all of their correspondents
> >>> see the yellow text. Try that here. Remember that MIME was invented
> >>> in the IETF and HTML down the virtual hall from here, both about 30
> years ago.
> >> write a good html editor for email, especially one that handles
> >> inline replies properly, and every single HTML editor for email I know of
> >> or after a change in format and it's likely to completely mess up
> >> your formatting, say by merging one correspondent's text with
> >> another.  HTML doesn't handle annotations well either because (gasp)
> >> text messages are not naturally hierarchical like HTML (and its *ML
> predecessors) expect
> >> (And, IMO unfortunately, a lot of MUAs take liberties with
> >> presentation of email messages, which only exacerbates the above
> >> problems.)
> >>

---

From: Keith Moore <[email-masked]>
Date: Mon, 1 Mar 2021 13:27:07 -0500

> characters by the server because people didn't know better.

Ok, first please understand that I'm not blaming anyone.   I'm also not 
making any proposal, at least not yet, and I am not currently sure about 
the best way forward.   I'm just making some observations based on 
long-term experience with email collaboration in IETF.

In some sense, plain text works better for IETF's needs than HTML, and 
maybe plain text works better for the needs of anyone doing technical 
discussion over email.  There is some virtue in simplicity.    One of 
the virtues of plain text email is that there's not (much of) a layer of 
interpretation between the text in the message and what the recipient 
sees.   (Of course there is a layer - the character encoding scheme - 
but not much more than that.)

That's not to say that there are no technical problems with plain text 
email or that it can't be improved.   Bbut the biggest problem with 
improving either is one of deployment.

> 1) There is no standard for HTML in email.
While true, it's not immediately clear that HTML is readily extensible 
to fix these problems, because it needs to be defined in such a way that 
a variety of MUA implementations produce consistent behavior when 
multiple parties make successive edits/replies to a message, when 
portions of multiple messages are quoted in a message, and so on.    You 
might, for instance, need to specify the representation of text copied 
from one email and pasted to another.

One way to view the problem of HTML in email, is that in email you need 
to have the ability of many different parties to edit the document over 
and over, by different implementations, without producing a corrupted 
mess.   HTML is not designed for that.   But plain text email has a 
similar problem, and so does every "word processor" format I've seen 
that's more complex than, say, WordStar.   Anyone who has been around 
IETF for awhile has seen the effect of multiple layers of line-wrapping 
and ">" (or similar marks) added at the beginning of lines.

(Actually the problem is even worse, because some MUAs used in a 
conversation will treat the quoted parts as plain text and others will 
try to make them into HTML.   So you get multiple incompatible layers.)

Still, humans can manually "clean up" text that has been subject to that 
kind of repeated alteration.  But cleaning up HTML that has suffered 
similar damage generally doesn't happen, partly because there's a layer 
between the actual HTML and the user interface that keeps users from 
doing exactly what they need.

(I'm not suggesting that we should instead edit the raw HTML in messages 
when composing replies.   In addition to requiring participants to be 
HTML experts, the HTML generated by most MUAs is far too messy for that.)

> 2) HTML has been turned into a presentation format.

I realize this is heresy, but a presentation format is what people 
actually need in the vast majority of cases.

Semantic markup has its place.  When you're writing a book or maybe even 
a long article, you need to focus on content, not layout.   The 
presentation needs to be fine-tuned after the content is written or 
mostly written, and often by different people than those who wrote the 
content.   (and sometimes the content is tweaked for the sake of 
presentation).   Semantic markup makes good sense for that kind of 
application.

But for discussion, a semantic markup layer just gets in the way.   
That's also true for most web pages.   Web developers need to be able to 
dictate what the content looks like on the screen (while still being 
responsive to different kinds of displays), and they're forced to deal 
with a layer that tries to second-guess them.

> 3) Email messages used annotations for a decade before HTML which 

Right.   And it turns out that we need annotations in email.

> knowing what formats are accepted by a recipient so there is no way to 
> fix this.

I'm not sure that would solve the problem at least for IETF's case, or 
for any use case that involves large numbers of potential 
participants.   When you compose a message to send to a mailing list, 
should your user agent poll the capability of every recipient to find 
out what kind of message format each can accept?   Should it send out 
different formats to different recipients?   Should it try to identify a 
common subset so it only has to generate one message and so that 
recipients' experiences will be more consistent?   What if you have an 
email conversation between a small number of people, a new recipient is 
added, and everyone's messages change format because the new recipient's 
capabilities don't support the common subset of the other recipients?   
What about the very common case when a single recipient has multiple 
user agents with different capabilities?

In other words, be careful what you wish for.   There's a lot of value 
in having a common format and minimal set of capabilities that everyone 
supports.

> font size settings that are frequently stupid. I have no control over 
> that as a user.
>
SMTP has turned out to be surprisingly (to me at least) fit for 
purpose.   It was designed in an era when you couldn't expect complete 
and full-time connectivity between senders and receivers, and also 
couldn't expect everyone to have access to the same network (e.g. 
ARPAnet vs. X.25), so it used store-and-forward.   But it turned out 
that store-and-forward was useful even in environments that could 
provide complete connectivity.   And later on it turned out to be useful 
for getting mail through firewalls.   In many environments 
store-and-forward is used to implement spam filters, virus filters, 
etc., to hide internal enterprise network infrastructure from outside 
viewers, and several other purposes. And store-and-forward helps make 
email more reliable, because it separates the problem of persistent 
delivery from the sending user agent's responsibility.

I do think some sort of recipient capability discovery could be useful 
for most messages that are sent to relatively few recipients (and 
actually had a proposal for this a few years ago, specifically to 
discover recipients' public keys), but probably not for IETF-style email 
discussions.   And implementing capability discovery for email means 
basically having two kinds of services that need to stay in sync, which 
creates additional risks.

Keith

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 1 Mar 2021 10:34:01 -0800

Hi Tom,

> HTML e-mail which drives a coach and horses through privacy.

I don't think I understand what you refer to by "actively supports HTML
e-mail".  Could you please clarify?

Thanks,

Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 1 Mar 2021 14:51:04 -0500

On Mon, Mar 01, 2021 at 12:05:49AM -0500, Keith Moore wrote:

> Ok, but to be fair: HTML is a disaster for email.

Mostly in the case of badly machine-generated HTML.  I have
little-difficulty with email sent by humans, where the MUA also emits a
sensible text/plain variant.

> Way back in the mid-1990s most of us thought it would work out ok, and
> more likely to succeed than text/richtext.   But we didn't really take
> the time to understand the nature of the problem in either case.   
> It's hard to write a good html editor for email, especially one that
> handles inline replies properly, and every single HTML editor for
> email I know of botches this.

Way back in the 90's I for one expected that HTML would work more poorly
than it turned out.  As for editors, Apple's Mail.app does a fine job of
editing both HTML and non-HTML email, and handles quoting and inline
replies well.  It is mostly Outlook that's historically poor at RFC2822
and MIME support, because ... MAPI and NIH.

This is not a hard problem, the real issue is that the industry has not
for some time been investing much effort into improving MUAs, its all
walled gardens and cloud now.

-- 
    Viktor.

---

From: Nico Williams <[email-masked]>
Date: Mon, 1 Mar 2021 17:22:38 -0600

> e-mail".  Could you please clarify?

To me it was clear that Tom meant "some IETF participants", not
something more formal like that the IAB has said HTML email is awesome
or whatever.

---

From: Nico Williams <[email-masked]>
Date: Mon, 1 Mar 2021 17:27:28 -0600

On Mon, Mar 01, 2021 at 01:27:07PM -0500, Keith Moore wrote:
> In some sense, plain text works better for IETF's needs than HTML, and maybe
> plain text works better for the needs of anyone doing technical discussion
> over email.  There is some virtue in simplicity.    One of the virtues of
> plain text email is that there's not (much of) a layer of interpretation
> between the text in the message and what the recipient sees.   (Of course
> there is a layer - the character encoding scheme - but not much more than
> that.)

Plain text email in IETF participation works great for me.  Maybe that's
just because I use mutt and VIM.  Because it works great for me, I don't
want to give it up, and I look with suspicion on any proposals to
replace it.

I do like GitHub for some IETF work, but GitHub doesn't make it easy for
me to have a single interface to all the IETF repos I might want to
follow or contribute to, and that would be essential for GH to
supplement the email lists more.

I've seen large communities replace e-mail lists with web-based forum
type solutions, and I for one don't like any such that I've seen yet.

My 2c.

---

From: Nico Williams <[email-masked]>
Date: Mon, 1 Mar 2021 17:30:00 -0600

On Mon, Mar 01, 2021 at 09:31:06AM -0800, Larry Masinter wrote:
> There's been no interest in the email community for defining a "for
> email" profile of HTML and multipart/related (or WPACK).  Why is that?

Maybe because we don't like any of it and none of us is being paid to do it.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 1 Mar 2021 15:32:55 -0800

> something more formal like that the IAB has said HTML email is awesome

That would make a lot of sense, though even with your prompt I'm having a
hard time getting from Tom's text to yours.

(FWIW, I myself perennially find myself reminding people that the official
IETF mail archive (web) service only displays the text/plain component, so
things like color and <div>s for quoting/indentation are lost.)

-Ben

---

From: Keith Moore <[email-masked]>
Date: Mon, 1 Mar 2021 18:47:20 -0500

> things like color and <div>s for quoting/indentation are lost.)

To me it seems like an "official" archive needs to preserve messages in 
the formats in which they were submitted, or as close to that as possible.

I can certainly understand if the web interface to such an archive 
doesn't support every aspect of MIME, or if it is careful about what 
HTML (or JS, or...) it presents to the reader.   But losing color and 
indentation seems very sub-optimal.

It's just a simple matter of (yet more) programming I suppose. And the 
devil is in the details.

Keith

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 1 Mar 2021 15:52:44 -0800

> It's just a simple matter of (yet more) programming I suppose. And the 

I put the "web" qualifier in because there is also an official IMAP
archive, that does preserve the message as submitted.  But it's not very
discoverable and requires quite a bit more effort to set up and use.

-Ben

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 02 Mar 2021 11:07:35 +1100

> discoverable and requires quite a bit more effort to set up and use.

Which then feeds into the very unofficial mirror I'm running, which does preserve all the HTML stuff :)

https://ietf.topicbox-scratch.com/groups/ietf/Tec34c67f6c0f8217/html-for-email

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 1 Mar 2021 19:42:13 -0500

>discoverable and requires quite a bit more effort to set up and use.

There's also an mbox format archive for people who really want the bits at:

https://www.ietf.org/mail-archive/text/

It's rsync-able.

If people want the mail archive to show HTML, there's certainly plenty of HTML sanitizers
we could use to show the HTML version of messages if we thought that was a good use of
the tools team's time.

On the other hand, perhaps we could make up our mind first whether formatted e-mail is a
part of the way the world works now, or it's a scourge to be stomped out.  Like, you know, NAT.

R's,
John

---

From: Larry Masinter <[email-masked]>
Date: Mon, 1 Mar 2021 16:52:45 -0800

The problem of RFC-formats and editing tools and the problem of HTML for email and mail archives -- these are fundamentally the same problem.

Alice wants to send something she saw to Bob, with some confidence that she'll know what Bob can see.
(Taking into account accessibility, platform-independence, and archiving -- if Bob can take a long time to read).

Right now, all you can do is snap a screenshot or send a PDF, each with its own drawbacks.

> From: ietf <[email-masked]> On Behalf Of John Levine
> Sent: Monday, March 1, 2021 4:42 PM
> To: [email-masked]
> >archive, that does preserve the message as submitted.  But it's not
> >very discoverable and requires quite a bit more effort to set up and use.
> 
> If people want the mail archive to show HTML, there's certainly plenty of
> HTML sanitizers we could use to show the HTML version of messages if we
> thought that was a good use of the tools team's time.
> 
> On the other hand, perhaps we could make up our mind first whether
> formatted e-mail is a part of the way the world works now, or it's a scourge
> to be stomped out.  Like, you know, NAT.
> 
> R's,
> John

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Mar 2021 14:35:38 +1300

On 02-Mar-21 13:42, John Levine wrote:
...> On the other hand, perhaps we could make up our mind first whether formatted e-mail is a
> part of the way the world works now, or it's a scourge to be stomped out.  Like, you know, NAT.

What we actually do with NAT, although it's undoubtedly the worst invention since white bread, is invent ways of living with it. For the purposes of IETF-style debate via email, we haven't really invented a good way of living with Content-Type: text/html, which is why some discussion threads rapidly become incomprehensible.

That is a technical problem of the kind that the IETF ought to be good at solving, if we tackle it systematically. How to maked threaded commenting work properly when some senders prefer Content-Type: text/html and others prefer Content-Type: text/plain?

(Incidentally, I have been amused to see several messages in my spam bucket recently with the subject "Telefax is the new email".)

   Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 1 Mar 2021 23:33:52 -0500

> Maybe because we don't like any of it and none of us is being paid to do

Been there, did that.

draft-hallambaker-mesh-dare-11 - Mathematical Mesh 3.0 Part III : Data At
Rest Encryption (DARE) (ietf.org)
<https://tools.ietf.org/html/draft-hallambaker-mesh-dare-11>

Of course, not working for a company that rhymes with Sproogle, nobody
seemed interested.

I shipped code implementing that one two years ago.

---

From: tom petch <[email-masked]>
Date: Tue, 2 Mar 2021 09:42:58 +0000

Ben

I think that a security-conscious mail-list system would suppress the 
html alternative.  E-mail used to have lots of executables attached with 
the potential to spread virus and the like and, nowadays, most mail 
exploders will remove anything like that that could do damage without 
being asked - it is taken as read.  In recent times, a lot of attention 
has been paid to privacy, in the work of the IETF, but sending out the 
html to all subscribers I see as a vector for bad actors to breach privacy.

Yes, the archive is text/plain but it is very rare that I will go to the 
archive for an e-mail.

Tom Petch

> .

---

From: tom petch <[email-masked]>
Date: Tue, 2 Mar 2021 09:59:58 +0000

> that are frequently stupid. I have no control over that as a user.

Going back to the original, having ranted about my number one hate, the 
loss of privacy to anyone else on the list .....

The points you make are all good, and good reason why IETF mailing lists 
should silently discard text/html attachments.

But it gets worse.  Quoting is another disaster area, in at least two 
regards.  The service I am obliged to use (for at least some lists) 
increases the left and right margins for each successive level of quote 
so that after five or so quotes, the space available for message text is 
down to a single character, yes, just one single character, so that a 
message of 300 character is now presented as a column 300 separate 
lines, each with one character.  Can the designer of a presentation 
format really be that stupid?  Yes!

Another presentation format for quoting is to place coloured bars down 
the left hand side of the scree, a different colour for each level of 
quote and initially, there are gaps in the last coloured bar where new 
text has been added so that it is clear what is the response, what is 
original, in the post.  But after five or so levels of quote, that left 
hand bar, yellow I think, becomes continuous so that it is impossible to 
see what is new, what is old, unless one gets the previous post from the 
trash and compares the two (or goes to the IETF archive and waits for it 
to catch up with the thread).

HTML has its uses, but e-mail is not one of them.

Tom Petch

Sent from a real MUA.

---

From: [email-masked]
Date: Tue, 02 Mar 2021 06:08:13 -0800 (PST)

> html alternative.

I did an informal survey of the viability of this approach a while back. The
very first thing I found is that the IETF is an outlier, and you shouldn't
assume what you see on IETF lists is in any way the norm.

When dealing with lists in general, do the text only thinkg and you end up with
delightful stuff like messages that say, "Please see the HTML part for the
actual content of this message". Or "This message can only be read by a client
that supports HTML".

Then there are the ones that do a crap job of producing the text from the HTML.
Things like text that is the same as the HTML with all the XML-ish punctuation
removed, but retaining all the tags and scripts. There's even one that produces
text with one character on each line that I especially like.

And then there are the ones which insert the text part but leave it blank.

This is just the subset I've seen on various lists. Once you start considering
the full gamut of email messages you'll find additional things like commercial
messages where the text part says, "Please click on this URL to view the
message on the web". 

> E-mail used to have lots of executables attached with
> being asked - it is taken as read.

In spam, sure. But in legitimate email? Not in my experience.

> In recent times, a lot of attention

A potential vector. And while lists are important, I'm far more concerned
with the more general case that includes commercial email.

And like it or not, outside the IETF the HTML horse left the barn a long time
back. We can chose to deal with or ignore it, but getting it back in
the barn is not an option.

				Ned

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 2 Mar 2021 15:55:16 +0000

[email-masked] wrote on 02/03/2021 14:08:
> And like it or not, outside the IETF the HTML horse left the barn a
> long time back.

Bear in mind that even within the IETF, plenty of people view the entire 
HTML email debate as flogging the proverbial dead horse, and when it 
rolls around every several months, welcomes it in the same way that you 
might welcome an outbreak of cold sores.

> We can chose to deal with or ignore it, but getting
> it back in the barn is not an option.
Looking at this from a different perspective, in the twenty-something 
years of discussion since Content-Type: text/html first appeared, have 
any actionable and viable suggestions emerged about how to deal with 
html email, other than stripping it off in the archived emails?

Maybe the people who are upset about html email could form a working 
group, take the discussion there and write up an ID with observations 
and recommendations for html emails at the ietf?

Nick

---

From: Keith Moore <[email-masked]>
Date: Tue, 2 Mar 2021 11:08:38 -0500

> actual content of this message". Or "This message can only be read by 

My experience echos this.  A few years ago I prototyped a system for 
allowing annotations (among other things) on email list messages.  In 
order to do that I had to parse incoming messages, convert them to HTML 
if necessary, and add links to those messages at appropriate places.   
(think "click here to annotate") What I found for multipart/alternative 
messages was that the HTML quite often didn't reflect the actual 
structure of the message so it was hard to use, and I actually 
experimented with converting the HTML to plain text before doing further 
processing.   But the text portion of the multipart/alternative messages 
were often worse, because of things like Ned cited.

Keith

---

From: [email-masked]
Date: Tue, 02 Mar 2021 08:08:46 -0800 (PST)

> and recommendations for html emails at the ietf?

Better idea: Create a list for the discussion. That addresses the immediate
goal of saving the poor dead horse from yet another beating, because when the
topic arises (again) we can redirect people to that list.

Whether or not a working  group materializes is then up to the participants. 

				Ned

---

From: tom petch <[email-masked]>
Date: Tue, 2 Mar 2021 16:31:03 +0000

> html email, other than stripping it off in the archived emails?

Strip it off before sending it out to list subscribers!  Perhaps an 
option on the subscription for those who want to risk the HTML.  I would 
leave the HTML in the archive as I have more control over when and how I 
access that.

The issue as I first said is privacy.  I think that the IETF, along with 
other parts of the industry have done a bad job of alerting users to the 
potential for evil actors with a variety of protocols.  There is a lot 
at the moment around me based on an older technology, phones, on the 
ability of evil actors to forge the number that appears on caller 
display to be that of a trusted organisation, government, financial 
institution and so on.  There is also the trick that the caller does not 
put the phone down so when you call back your trusted institution to 
verify the caller, you get the evil actor's mate.  And I read that the 
bill for this is racking up billions, typically via push-payment fraud.

Here, the idea that opening an e-mail, or letting it be implicitly 
opened for you by the system, enables someone to track when and where 
you are, via HTML, will, I think, come as a surprise to many and, given 
the attention that privacy has garnered in the IETF, that surprise will 
be unwelcome.  As I said, given all that attention, I remain at a loss 
that the IETF does nothing about it, allows it on IETF lists, does not 
publish text/html considered harmful.  I do not see a way that evil 
actors can exploit this for e.g. financial gain, but then, I do not have 
the mindset of an evil actor - doubtless they are working on it.

Tom Petch

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 2 Mar 2021 16:41:37 +0000

tom petch wrote on 02/03/2021 16:31:
> Strip it off before sending it out to list subscribers!

Great!  Is there an ID because some people may have an issue with this 
and it's the sort of thing that might need consensus, given the 
inconclusive discussion over the years.

Nick

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Mar 2021 10:45:25 -0600

On Tue, Mar 02, 2021 at 03:55:16PM +0000, Nick Hilliard wrote:
> HTML email debate as flogging the proverbial dead horse, and when it rolls
> around every several months, welcomes it in the same way that you might
> welcome an outbreak of cold sores.

That can be said of many discussions here, some of which are ongoing.

> Looking at this from a different perspective, in the twenty-something years
> of discussion since Content-Type: text/html first appeared, have any
> actionable and viable suggestions emerged about how to deal with html email,
> other than stripping it off in the archived emails?

Wearing a security hat, what I would do is strip off all script and img
elements, and any element with an href that gets dereferenced
automatically.

Or maybe pass it through elinks and then turn the references back into
HTML links that the user can click on if they really like.

> Maybe the people who are upset about html email could form a working group,
> take the discussion there and write up an ID with observations and
> recommendations for html emails at the ietf?

Unlikely.  We're a volunteer organization, but the volunteers do get
paid to do most of what they do here.

A better approach would be to standardize a subset of HTML for email
that is secure enough.  But I think that would fall on the W3C.

Nico
--

---

From: tom petch <[email-masked]>
Date: Tue, 2 Mar 2021 16:47:38 +0000

> inconclusive discussion over the years.

I thought about an I-D
text/html considered harmful
but realised that I only know of the one clearcut privacy issue and that 
there are probably many more lurking there were I up-to-date with all 
that HTML is capable of nowadays.

Tom Petch

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Mar 2021 10:49:17 -0600

On Tue, Mar 02, 2021 at 04:47:38PM +0000, tom petch wrote:
> there are probably many more lurking there were I up-to-date with all that
> HTML is capable of nowadays.

Well, maybe if you publish a barebones I-D others will contribute
text...

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Mar 2021 12:07:10 -0500

On Tue, Mar 2, 2021 at 5:00 AM tom petch <[email-masked]> wrote:

> knowing
> font

No it shouldn't. The reason HTML email is so crappy is precisely because
people here failed to realize why the other 3 billion Internet users wanted
it. And you are still making that mistake.

Only a very very small fraction of the world is fond of VT100 console
output. It is a significant fraction of IETF but its still a minority.

HTML email is bad because nobody in the places which might have had
influence wanted to make it really good.

SMTP has had a good run. So has the telephone system. But they are both
long past their prime and need to go the way of the fax machine. I still
have two fax machines in the house, its a function of the printer. But
neither has been hooked up in five years now.

The replacement is quite feasible. Here is how I plan to go about it.

1) Open callsign registry.

Alice creates a public key pair, registers the public part in the callsign
registry claiming the name @alice and specifying her current service
provider where people can reach her.

Traditional RFC822 email addresses are owned by the domain name owner.
Alice doesn't own [email-masked] and she can't take it with her.

The registry itself doesn't provide any services. It doesn't even provide
query lookup, only zone transfer. This is so we can make the names really
really cheap.

2) Contact catalog

Alice exchanges her contact information with friends. This is a kimono
affair, she probably doesn't put her email address or her telephone in her
public contact. But she has a contact specifying her SMTP, OpenPGP, S/MIME
etc. And unlike traditional contact formats that aren't backed by PKI/TKI,
this one automatically updates.

3) TKI

Threshold key infrastructure allows Alice to manage her private keys
without knowing she is doing it.

I am not going to be replacing SMTP on day one. Mesh messaging is
deliberately limited to 32KB messages. That might well be reduced to 8K
before launch. But consider this, I am providing an open system that allows
banks, stockbrokers, healthcare providers to reach their customer and send
them secure messages that comply with HIPPA, GDPR etc. It is a system that
allows them the security of their private infrastructures and the ubiquity
of SMTP.

The Mesh is designed to allow these people to offload their costs. Running
their proprietary messaging systems is expensive and not really that good
for the customer. An open system serves them much better. So just like my
brokerage buys me anti-virus subscriptions, I think that a few bucks a year
to give me Mesh secure messaging will work.

And another thing. The Mesh is an open framework that makes it really easy
for app designers to build their own stuff on top with confidentiality and
integrity controls built into the core. All you need to achieve OPEN secure
voice and video conferencing is to use the Mesh presence protocol to
establish a WebRTC session.

And one more thing, Mesh Messaging is limited to 32KB precisely so that it
can be used to send TB of data at a time. The raw video of the Mesh
architecture series is 4TB. I should be able to send that to my editor by
mailing it to them. Not by SMTP, I am not because it is a fore and storward
system. Mesh messaging limits push messages to 32KB but the message sent
can be 'please pull the raw video files from https://....'

So no, I don't plan to replace SMTP directly. Nor do I intend to replace
the telephone. Instead, I am architecting an open system that is capable of
growing by filling completely different needs and just happens to make them
unnecessary.

The point when I have won is when you can buy cheap Mesh 'phones' for the
home which are a combo of Mesh video, Mesh voice, Mesh messaging and they
are also the remote control for your TV and smart home.

 Oh and yes, I will be making a subset of HTML the basis for the messaging
part.

---

From: Keith Moore <[email-masked]>
Date: Tue, 2 Mar 2021 12:39:44 -0500

On 3/2/21 12:07 PM, Phillip Hallam-Baker wrote:

> No it shouldn't. The reason HTML email is so crappy is precisely 
> because people here failed to realize why the other 3 billion Internet 
> users wanted it. And you are still making that mistake.
I think you are overstating several things.  For example, 'the other 3 
billion Internet users' didn't necessarily want the HTML email we have 
with all of its privacy issues and other warts.   To a large extent they 
just used what they were given.   They may have had a choice of plain 
text vs. html email (and some may still have that choice), but the 
particular kind of HTML that their preferred MUA or more likely webmail 
implementation generates is now the widespread default
> output. It is a significant fraction of IETF but its still a minority.
Most IETF users aren't "fond of VT100 console output" either.  Even in 
IETF there are probably few users of plain-text email systems running in 
terminal windows.  (Not zero, but relatively few.)   And most IETF users 
can probably make good occasional use of bold face, italic, color, 
etc.   But because of the way we use email, with some conventions dating 
from when email was plain text only, we are especially aware of some of 
the worst limitations of HTML email.
> influence wanted to make it really good.
Or maybe because each company had a different idea of what "really good" 
HTML email would be like, and nobody took a leadership role to try to 
make it interoperable.
> SMTP has had a good run. So has the telephone system. But they are 
> both long past their prime and need to go the way of the fax machine.

Yeah, right.   (Note that the fax machine has gone away largely because 
SMTP has replaced it.)

Anybody can design a system that's theoretically better than any 
existing system if they are smart enough and work hard enough. The trick 
is to get everyone else to go along with it.   And to displace something 
that actually exists and is working, the new system has to be MUCH 
better than the old.   The more widely deployed the existing system is, 
the harder it is to replace it. And incremental changes are not as pure 
as a clean sheet design, they are usually easier to deploy.

Keith

---

From: Larry Masinter <[email-masked]>
Date: Tue, 2 Mar 2021 09:43:45 -0800

There is a working group WPACK which could have taken on the problem of how to package HTML, embedded image, JavaScript libraries in a way that could be interpreted in a sandboxed environment. Maybe what they are doing could be retargeted for such a purpose? 

> From: ietf <[email-masked]> On Behalf Of Nick Hilliard
> Sent: Tuesday, March 2, 2021 7:55 AM
> To: [email-masked]
> > We can chose to deal with or ignore it, but getting it back in the
> > barn is not an option.
> actionable and viable suggestions emerged about how to deal with html
> email, other than stripping it off in the archived emails?
> 
> group, take the discussion there and write up an ID with observations and

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Mar 2021 12:52:45 -0500

On Tue, Mar 2, 2021 at 12:39 PM Keith Moore <[email-masked]>
wrote:

> Anybody can design a system that's theoretically better than any existing
> system if they are smart enough and work hard enough.   The trick is to get
> everyone else to go along with it.   And to displace something that
> actually exists and is working, the new system has to be MUCH better than
> the old.   The more widely deployed the existing system is, the harder it
> is to replace it.   And incremental changes are not as pure as a clean
> sheet design, they are usually easier to deploy.
>
The difference between what I am doing with the Mesh and what TimBL is
doing on Solid is that he is just being himself and hoping that will be
enough to be successful and I spent the best part of a decade working out
why the Web succeeded and I designed the Mesh so to maximize the
probability of success.

TimBL might well be successful a second time. But it is pretty clear that
if either of us starts to pull ahead, they will quickly absorb what is
useful from the other. That was also a part of the success of the Web. Will
either succeed? Probably not but we have both been successful in deploying
very large systems in the past. Nobody can be sure of success.

What I am certain of though is that failure is certain if nobody bothers to
try. It is pretty easy to see where the Internet is headed at this point.
The Web is the only open system that hasn't fallen into disrepair. The user
base is headed off to the walled gardens because those are at least being
maintained. The only thing that stops the phone system and SMTP becoming
derelict is they are the only ubiquitous communications systems in use.

---

From: Keith Moore <[email-masked]>
Date: Tue, 2 Mar 2021 13:26:50 -0500

On 3/2/21 12:52 PM, Phillip Hallam-Baker wrote:

> Will either succeed? Probably not but we have both been successful in 
> deploying very large systems in the past. Nobody can be sure of success.
>
> What I am certain of though is that failure is certain if nobody 
> bothers to try.
Completely agree with that much.   And a new idea doesn't have to be a 
complete success for it to be beneficial.
> It is pretty easy to see where the Internet is headed at this point. 
> The Web is the only open system that hasn't fallen into disrepair.

I would claim that the web *has* fallen into disrepair. It's a huge 
honking mess that seems likely to drown in its own increasing complexity 
even if nothing comes along to replace it. Some of what's there will 
probably survive, but I don't know how much or how ubiquitous it will be.

Keith

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Mar 2021 13:28:19 -0500

On Tue, Mar 2, 2021 at 12:44 PM Larry Masinter <[email-masked]> wrote:

> There is a working group WPACK which could have taken on the problem of
> how to package HTML, embedded image, JavaScript libraries in a way that
> could be interpreted in a sandboxed environment. Maybe what they are doing
> could be retargeted for such a purpose?
>

No.

And here is my objection to the current IETF approach of 'focused' WGs:
They are more likely to produce an output but it is very likely to be an
output that it would be better hadn't been created in the first place.

What I needed for my work is a packaging format that supports:

1) Incremental Encryption
2) Incremental Integrity
3) Authentication

What Google needed for their immediate commercial needs was a simple
archive technology that zips up a few Web page components delivered over
HTTP/TLS. So they wrote a very narrow spec that only addressed their use
case and then came to IETF to get it blessed as a niche solution. But it is
a solution that was designed with absolutely no thought to the wider
problem. They didn't want to consider the wider problem at all.

This is how PKIX got in the state it has. Instead of considering revocation
from a high level standpoint and building a scalable solution we had a
'make do' solution which led to another incremental solution which was
again curtailed and... That is how we ended up with five separate assertion
types in PKIX. TAXI which became the basis for XKMS and SAML was an attempt
to simplify and get back to basics.

What I fully expect will happen of course is that at some point we will
want to introduce DARE into IETF. Security of Data at Rest is starting to
become an enterprise concern. And of course there will be people asking
'why not build it on WPACK' and 'why not use CBOR' and the answer will be
that there are very specific requirements that apply to DARE which the
people working on those systems told me are out of scope and they do not
want to consider.

Oh and the reason DARE is designed the way it is is for backwards
compatibility with a different set of standards. JSON-B is a strict
superset of JSON encoding so that every valid JSON document is also JSON-B.
You need a separate serializer to make use of JSON-B encoding but a single
decoder will decode both and also the compressed version and the version
with binary encodings for extended binary data types.

Using DARE for HTML packaging is easy because I designed it to support HTML
packaging even though I had absolutely no need for that at the time I did
the work. Why did I design that spec to meet a use case I don't care about?
Well if you want your spec to support unexpected and new use cases you
cannot imagine, you had better start by meeting the use cases you can.

The SAML TC had a use cases sub-committee that spent hours arguing over
which use cases to include. Some of that argument was productive because it
resulted in a better statement of the use case. But a lot of it was
pointless discussion of whether a use case was important enough to generate
a requirement and I didn't care whether it was important enough, I worked
out a way to meet the requirement regardless.

---

From: Keith Moore <[email-masked]>
Date: Tue, 2 Mar 2021 13:36:18 -0500

On 3/2/21 1:28 PM, Phillip Hallam-Baker wrote:

> archive technology that zips up a few Web page components delivered 
> over HTTP/TLS. So they wrote a very narrow spec that only addressed 
> their use case and then came to IETF to get it blessed as a niche 
> solution. But it is a solution that was designed with absolutely no 
> thought to the wider problem. They didn't want to consider the wider 
> problem at all.

That kind of tension between different ideas of how to scope an effort 
always exists.   I agree that IETF often scopes its WGs too narrowly, 
sometimes in a deliberate effort to create an artificial sense of 
consensus.   And by doing so, it often fails to resolve tussles that 
could have probably been resolved.   But sometimes you simply can't get 
enough of the different concerns to cooperate to address a common 
problem.   And you can fail by scoping an effort too widely at least as 
easily as you can fail by scoping an effort too narrowly.   It's a 
judgment call, and sometimes those judgments will be better than others.

Keith