Re: HTML for email

[Phillip Hallam-Baker <[e-mail]>]

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

> On 01/03/2021 14:22, Phillip Hallam-Baker wrote:
> > 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.
>
> 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.
>

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 [e-mail] 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.