Re: Requesting comments on draft-cheney-safe-02.txt

["Cheney, Edward A SSG RES USAR USARC" <[e-mail]>]

Hector,

> Since this in the SMTP forum, FaceBook, for example, is one of the
> entities that believes all MAIL is own by them and can be used to
> extracting information about both parties. So does Google and yahoo,
> but FaceBook has raised and highlighted the issue of recent by
> questioning any the idea of user email privacy.

In my understanding the privacy of email is simultaneously and equally
owned by all named parties in the transaction.  This means Facebook and
Google can do with the email whatever they want so long as that data is
never transfered to a third party without the express consent of all
named users.  This is basically a subscription oriented business model
where a user voluntarily becomes party to a service and the vendor of
that collects data upon the user in an attempt to make the service more
fulfilling.  Netflix is an example of this exact model outside of email.


> Even then, IMV, even if it is considered that an alternative should be
> considered, it would be a major revamp and thus SHOULD open the door
> to a newer more efficient protocol. One where the state machine would
> be much simpler.   Maybe something like SIP or XMPP or SOAP.

Is this to say that SMTP is outdated and should be replaced by something
more open for scalability and performance?  If so, are you suggesting a
more modern protocol replace SMTP or provide assistance to SMTP?


> Both Microsoft and Adobe have newer client-side plug-ins that now
> offer  signed certificate authentication/authorization methods with
> their client-side "far calls."   So I don't think your draft will
> replace this part since it duplicates this resolution.

I do not claim to have produced anything new with regard to certificates
or digital signatures.  If a more efficient model for independent
identity validation does exist I will definately incorporate that in.


> For AJAX, the SAFE consideration would produce scalability and
> performance issues.  I envision many timeout design issues.

SAFE will introduce scalability problems for email, because it would
open email to considerably higher bandwidth consumption.  That
consumption would likely come at a cost from equal or greater reduction
in bandwidth from the web.  On a slow connection may web pages timeout,
because many sites take broadband connections for granted.  This is not
the fault of any technology, but poor development.  This is not a
technology problem for the web and I don't see such poor development
decisions equivocating to technology failure of extending email.


> SAFE restricting DOM events would be a major show stopper. Probably
> the single thing that would stop people from further consideration.

I completely agree, but still will not budge.  Allowing event execution
is a slippery slope that will only bring the security failures of the
web to email.  This is a security solution at a usability cost.  There
are only three possible choices to consider:

1) Concede the usability limitations of SAFE are acceptable to procede.
2) Propose a separate competing solution that is equally limited.
3) Do nothing and watch the result, which is technology failure.

What is more important to you: executing events or securing your data?


> The direction is MORE client side plug-ins, NOT LESS. Flash,
> SilverLight, APEX, Google Apps, Firefox Plug-ins are prime examples.

I agree with that as well.  The security flaws associated with code
executed by those plugins is owned by the author of those proprietary
plugins.  That typically results in fast and reliable patching at the
cost of the plugin's owner.


> There are quite a few client/server communication wirings. I don't see
> how we can use SMTP in the wiring here.

The document you provided looks like an elaborate dynamic AJAX
environment where a server-side application is independently accessing
the data store that the AJAX framework is either writing to or reading
from.  The SAFE model is perfectly capable of replicating this
functionality.  SAFE is essentially an inverted form of AJAX itself,
while traditional AJAX may occur on the server.  By traditional AJAX at
the mail server I mean that data can be dynamically written by an
application to a data store for use at a later time or use by a
different machine in the same domain.  There is no reason that the
XMLHttpRequest object cannot be used at the email server, except that it
cannot be used in accordance with SMTP.

I have already thought of this, but chose not to include it in the SAFE
concept.  First of all this is a processing elaboration not necessary
for transmission description.  Secondly, there are likely many different
ways to do this correctly that are dependent upon various unique
conditions.


> Introduce SAFE as a new PROXY or protocol that would be more of a plug
> and play solution.

I see SAFE as operating as an extension to prior existing SMTP service
implementations and not really a replacement.  The only additional
requirements of the mail server directly are support of the XMLSmtpPush
object and to respond only to the specific client.  The mail server
could even pass script processing to another machine as the scripting
sandbox so long as it is the server that sends the responces.

Thanks,
Austin