Hector, I must have not communicated the problem and objective clearly. The security problem only exists in the realm of the WWW. The solution to this problem, as I propose it, only exists over SMTP. The idea is to eventually abandon use of all client-side scripting on WWW in favor of an alternate secure solution that is only capable of existing over SMTP.
I am not actually proposing to mix or merge HTTP and SMTP transaction states. I have not thought of such an idea, and so such might be possible but I have given no thought to how that might work. The closet to mixing protocols that I have ever thought of is to supply a URI in a markup language over email that may be either HTTP or SMTP as defined by that URI. Thanks, Austin ----- Original Message ----- From: Hector Santos <[email protected]> Date: Friday, July 31, 2009 8:30 Subject: Re: Requesting comments on draft-cheney-safe-02.txt To: "Cheney, Edward A SSG RES USAR USARC" <[email protected]> Cc: "J.D. Falk" <[email protected]>, [email protected] > Do you have examples of these HTTP-based SMTP Client Side Script? > > I presume its a HTTP POST request on port 25 (or some other known > SMTP > server port) with the posted request body content containing > batched > SMTP commands? > > Off hand, I am not sure if the security concerns are SMTP related. > > -- > Hector Santos > http://www.santronics.com > > > > Cheney, Edward A SSG RES USAR USARC wrote: > > > The idea is that security vulnerabilities on the internet occur > most significantly as a result of client-side scripting from > documents transmitted across HTTP. By most significant I mean as > measured by quantity and not severity. In addition to frequent > immediate vulernabilities client-side scripting can also operate as > an execution point for other additional vulernabilities not > directly associated with client-side scripting. It is my opinion > that the only way to solve this security problem is to either break > HTTP or eliminate client-side scripting. I find there is no reason > to break HTTP since it is working perfectly well and is not to > blame for this problem. Client-side scripting cannot be removed > unless an alternative convention is proposed. > > > > It is absolutely imparitive that a solution exist as the quantity > of these security problems are continually increasing and there is > no possible solution available from HTTP. If a solution is not > proposed the security flaws of the system will become so > significant that the commerical value of financial transactions and > PII leaks will eventually result in abandoning the internet as an > open platform in favor of more secure proprietary technologies. > > > > As an alerternative method of allowing interactivity from client- > side scripting I wrote this document to migrate the concept of > client-side scripting to the email architecture. The idea is that > interactivity from client-side scripting can be replaced by > transaction interactivity. Since mail servers are intermediate > agents in the transmission, opposed to an end point like an HTTP > server, they can make processing or scripting decisions upon data > without that scripting having to exist on a client system. In > other words, it is basically an inverted form of AJAX that does not > execute on the client-side. The idea is easily possible using > SMTP, but is not possible over HTTP since HTTP does not have > intermediate agents between the client and server. > > > > Thanks, > > Austin > > > > ----- Original Message ----- > > From: "J.D. Falk" < > > Date: Friday, July 31, 2009 1:44 > > Subject: Re: Requesting comments on draft-cheney-safe-02.txt > > To: "Cheney, Edward A SSG RES USAR USARC" < > > Cc: [email protected] > > > > > >> Cheney, Edward A SSG RES USAR USARC wrote: > >> > >>> I am requesting comments on the following this internet draft. Any > >>> questions, confusion, feedback, or changes would be helpful. > >>> > >>> http://tools.ietf.org/id/draft-cheney-safe-02.txt > >> Interesting idea. What's the use case you have in mind? In other > >> words: > >> who will use it, and why? > >> > >> -- > >> J.D. Falk > >> Return Path Inc > >> http://www.returnpath.net/ > > > > > > > > > > >
