Re: No subset for email

(I posted this to the list, last night, but have not seen it appear 
there.  So I decided to re-post and copy you.)



Folks,

Howdy.


Quite a few of the postings have been interesting, but I found these
tidbits particularly helpful:


Gregory Woodhouse wrote:
> Now, that's interesting: Are web-based e-mail applications (which are
>  increasingly common) really distinguishable from other web-based 
> applications?


gregory.woodhouse@sbcglobal.net wrote:
>    part of the problem is that the issue has been cast in the wrong 
> terms. Instead of looking for a subset (focusing on the technical 
> solution) that will solve the problem, shouldn't we start out by 
> trying to clearly state what it is we are trying to do?


Tavis Reddick wrote:
> In these discussions, I'm not sure if I understand the role of the 
> user, email client and server in choosing settings for personal 
> preference, accessibility and security.


Arnt Gulbrandsen wrote:
> First and most important: rendering email in a rectangular part of
> the screen isn't enough. It's also necessary to reply (including
> quoting) and to display excerpts of the message.
> 
> Second, what good would such security settings have? There isn't any 
> trusted origin in email, 



At the start of an effort like this, any good engineer wants to dive
into the details.  (Well, ok.  So do bad ones.) The challenge is to
refrain from diving in too quickly.

If folks can agree on the particular problems they want to solve
(together), and then agree on the responsibilities for different
components (e.g., html provider, html rendering engine, ...) then the
fine-grained details are likely to follow rather naturally.


So perhaps some meta-questions, taking from the above:

1. What is it about email use of HTML that is inherently different from
web use?  As an example, the asynchrony between the HTML provider and
the HTML rendering means that the two cannot interact, to tailor what is
provided.

2. What is it about the pragmatic aspects of email use that create
pressure for additional differences from the web?  The obvious example,
here, is the very different security concerns.  When talking with a web
server, the client can have a fair degree of assurance that they are who
they say they are, and SSL/TLS significantly add to that assurance.
Email might yet get there, with DKIM, but it is a long way from that
safety.  And the current state of email abuse is one of chronic red-alert.

3. As noted, the Reply function introduces additional expectations.
What are they exactly? (Reply has a long-history of being the litmus
test for adequacy in a proposal.  To that end, it underscores that email
is about two-way dialogue, not just one-way publishing.)

4. Generically, what are the security concerns/threats that are key to
safe use of HTML in email?

5. Must HTML in email be compatible with HTML on the web?  Would it be
acceptable to have valid email HTML not be subject to successful
processing as a web page?  (I'm trying to imagine the justification for
making the answer be yes, and I'm failing...)

6. ...?


d/


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Received on Monday, 16 April 2007 11:40:16 UTC