Subject: Re: Requesting comments on draft-cheney-safe-02.txt
From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: "Peter J. Holzer" <[email-masked]>
Cc: [email-masked]
Date: Sat, 01 Aug 2009 09:56:55 +0400
List-Id: <ietf-smtp.imc.org>

Peter,

> I think you mix up HTTP and client-side scripting. HTTP is only a
> protocol to send and request data.

> Therefore I don't think you gain anything by using SMTP instead of
> HTTP as the transport protocol.

The problem only exists in the realm of HTTP due to where code actually
executes for interaction.  HTTP is certainly not part of the problem,
but it also cannot be a part of the solution due to the simplicity of
its design.  In the WWW all interactive code executes at the user-agent
software.  This software is written by a stranger to the local user who
has absolutely no ability to verify the integrity of the code until
after it has executed.  The user-agent cannot even control if the code
executes automatically upon rendering of the page except to completely
disable execution of all client-side code.

> What is gained by adding intermediate systems?
Intermediate systems offer a point of execution for code that is neither
the local user-agent or the destination.  This means interactive code
can execute completely outside a client user-agent.  This is important
for a couple of reasons:

1) Code is not executing at the client user-agent, so the client user-
agent is free from vulnerabilities associated with the execution of such
code.

2) The server that owns the code is the exact point of execution for
that code.  This forces such an owner to take ownership of security and
integrity of that code for their own self protection.  In the WWW
client-side code can be intentionally harmful because it is owned by a
server that will never execute it.

3) It is an unrealistic expectation that any professional requirements
for evaluation of security, best practices, or efficiency can be
presumed of either the end user or the developer of client-side code.  A
system of standard limitations for code execution must exist at the
application layer in order to ensure that security is not violated by
poor code developement or end-user ignorance.

Technically speaking HTTP is also unidirectional.  HTTP typically
operates with a GET request for a resource on a server and the server
responds with that resource.  Since logic is not capable of being passed
into that GET request HTTP is unidirectional as a result.  The solution
to HTTP unidirectionality is the XMLHttpRequest object.  SMTP is also
unidirectional.  My solution for SMTP is the XMLSmtpPush object.

> With your model, how would this be handled?

In your example the code would execute using HTML's onkeyup event.  The
limitation of this model is that event oriented execution is not
allowed.  This is an intentional decision.  Here is how I explained it
yesterday:

I am extremely hesitant to suggest that any event oriented execution
should exist from an email client.  Its a drastic hard stop to
completely remove the possibility of security compromise from the
client.  I believe there is a middle ground where extremely limited
interactions are possible from execution based upon client events, such
as mere manipulation of the DOM.  It is very possible that such limited
execution can be easily specified, but I believe this would be too
easily abused.  I believe people know how things should work on the WWW
and if provided the opportunity would do everything in their power to
ensure that they work in email without regard for the standards or
security compromises.

In this model interaction occurs by result of expected content responses
to a transmission opposed to execution of events.  I simply do not want
to invite the opportunity for abuse if then intent of this model is
security.

I have not examined the transmission model of XMPP, but I really do
enjoy that is written as XML opposed to seven bit ASCII.  I have chosen
SMTP for this model, because SMTP is the most widely supported
communication and it contains the necessary intermediary agents which
HTTP does not.

Thanks,
Austin

----- Original Message -----
From: "Peter J. Holzer" <[email-masked]>
Date: Saturday, August 1, 2009 2:11
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
To: [email-masked]

> [can you get your MUA to wrap lines at approximately 70 characters?
> Single lines of 750+ characters are a bit unwieldy]
> 
> On 2009-07-31 02:36:31 +0400, 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.
> I think you mix up HTTP and client-side scripting. HTTP is only a
> protocol to send and request data. Some clients interpret some data
> received by HTTP as code, but that has nothing to do with the HTTP
> protocol itself. The same data received via FTP, or SMTP could be
> interpreted just the same.
> 
> Therefore I don't think you gain anything by using SMTP instead of 
> HTTPas the transport protocol.
> 
> 
> > Client-side scripting cannot be removed unless an alternative
> > convention is proposed.
> [...]
> > 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.
> 
> What is gained by adding intermediate systems? I see only added
> complexity and a potential for additional security holes here.
> 
> The idea to run the scripts on the server and let them only manipulate
> the DOM of a document on the client via a well-defined protocol has 
> somemerit. But it probably makes a lot more sense to base this 
> protocol on
> HTTP or XMPP than on SMTP. (most importantly, because HTTP and XMPP 
> allowcommunication in both directions, while SMTP is unidirectional 
> (exceptfor status codes))
> 
> 
> > 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.
> 
> I don't see what purpose the intermediate servers serve in your model.
> Why are they necessary?
> 
> As a sample use case, consider a typical "autofill" search form:
> 
> The browser has just loaded an HTML (or other markup language, if you
> prefer) page with a search form.
> 
> With AJAX, the HTML file contains s script which will intercept each
> character the user types into the input field, send (via HTTP) a 
> searchrequest to the server, and then manipulate the dom to display 
> the search
> results in a dropdown menu.
> 
> With your model, how would this be handled?
> 
> 	hp
> 
> -- 
>   _  | Peter J. Holzer    | Openmoko has already embedded
> |_|_) | Sysadmin WSR       | voting system.
> | |   | [email-masked]         | Named "If you want it -- write it"
> __/   | http://www.hjp.at/ |  -- Ilja O. on 
> [email-masked]

Date: Fri, 31 Jul 2009 23:15:00 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--WIyZ46R2i8wDzkSu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[can you get your MUA to wrap lines at approximately 70 characters?
Single lines of 750+ characters are a bit unwieldy]

On 2009-07-31 02:36:31 +0400, 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.

I think you mix up HTTP and client-side scripting. HTTP is only a
protocol to send and request data. Some clients interpret some data
received by HTTP as code, but that has nothing to do with the HTTP
protocol itself. The same data received via FTP, or SMTP could be
interpreted just the same.

Therefore I don't think you gain anything by using SMTP instead of HTTP
as the transport protocol.

> Client-side scripting cannot be removed unless an alternative
> convention is proposed.
[...]
> 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.

What is gained by adding intermediate systems? I see only added
complexity and a potential for additional security holes here.

The idea to run the scripts on the server and let them only manipulate
the DOM of a document on the client via a well-defined protocol has some
merit. But it probably makes a lot more sense to base this protocol on
HTTP or XMPP than on SMTP. (most importantly, because HTTP and XMPP allow
communication in both directions, while SMTP is unidirectional (except
for status codes))

> 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.

I don't see what purpose the intermediate servers serve in your model.
Why are they necessary?

As a sample use case, consider a typical "autofill" search form:

The browser has just loaded an HTML (or other markup language, if you
prefer) page with a search form.

With AJAX, the HTML file contains s script which will intercept each
character the user types into the input field, send (via HTTP) a search
request to the server, and then manipulate the dom to display the search
results in a dropdown menu.

With your model, how would this be handled?

	hp

--=20
   _  | Peter J. Holzer    | Openmoko has already embedded
|_|_) | Sysadmin WSR       | voting system.
| |   | [email-masked]         | Named "If you want it -- write it"
__/   | http://www.hjp.at/ |  -- Ilja O. on [email-masked]

--WIyZ46R2i8wDzkSu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--WIyZ46R2i8wDzkSu--

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: Alessandro Vesely <[email-masked]>
Cc: [email-masked]
Date: Fri, 31 Jul 2009 18:15:47 +0400
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

Alessandro,

> Apparently, moving scripts execution to mail servers would also
> transfer vulnerability issues along the same path.
I attempted to resolve this problem as much as possible.

1) Scripts would not be executed by the client, so only the owner of the scripts could execute them.
2) I suggest that scripts must be executed in a sandbox location that is different from where they are stored on the server.  This idea is so if a script becomes corrupt or compromised during a session of communication that corruption would be limited to that single session.  A sandbox can also be regulated in how code is executed to prevent access to code outside the sandbox.

> Is it difficult
> to state whether a compromised server is better than a compromised
> client, but it is certainly better if at least one of them is not
> compromised.
I would say that it is better, only because of distribution of responsibilities.  A certain expectation is typically expected of a server administrator, especially if that server administrator is from a respected domain.  There is no expectation of responsibility or expertise to maintain the most basic of security controls from the user.

> In addition, it may be overly difficult to obtain real
> interactivity
> without local scripting.
Yes, the idea of event oriented execution would not be possible.  As a result loss of application interactivity would certainly occur locally.  The idea is to replace this luxury with rapid short bursts of data exchange between a client and the distant mail server.  The result is certainly less reliable than client-side scripting, but is more secure with a significantly higher degree of data integrity.

I am extremely hesitant to suggest that any event oriented execution should exist from an email client.  Its a drastic hard stop to completely remove the possibility of security compromise from the client.  I believe there is a middle ground where extremely limited interactions are possible from execution based upon client events, such as mere manipulation of the DOM.  It is very possible that such limited execution can be easily specified, but I believe this would be too easily abused.  I believe people know how things should work on the WWW and if provided the opportunity would do everything in their power to ensure that they work in email without regard for the standards or security compromises.

I will have to review the language of the specification to ensure I am not incorrectly communicating the definition of a CA.  I agree that the client should not have to manage any role of a CA or even distributed digital signatures.  I do state that a CA must be on a domain separate from any other involved agent in the transaction.  The idea is that this process exist to establish that the distant server is not a spoofed address in as much a transparent manner as possible.  I will reevaluate the language I have used to describe this process.

Thanks,
Austin

----- Original Message -----
From: Alessandro Vesely <[email-masked]>
Date: Friday, July 31, 2009 11:42
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
Cc: [email-masked]

> 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 [...]  
> Client-side scripting cannot be removed unless an alternative 
> convention is proposed.
> > 
> > [...] The idea is that interactivity from client-side scripting 
> can be replaced by transaction interactivity.  Since mail servers 
> are intermediate agents [...]
> 
> Apparently, moving scripts execution to mail servers would also 
> transfer vulnerability issues along the same path. Is it difficult 
> to state whether a compromised server is better than a compromised 
> client, but it is certainly better if at least one of them is not 
> compromised. (Considering that many mail server also function as 
> http servers, for handling email via web forms, it seems unlikely 
> that the vulnerability added to the servers would thus be removed 
> from the clients.)
> 
> In addition, it may be overly difficult to obtain real 
> interactivity 
> without local scripting. Indeed, the draft defines what minimal 
> code 
> a client has to be allowed to execute. Allowing some more seems 
> likely to come as an optional feature...
> 
> Finally, if the model is meant for widespread use, it shouldn't 
> rely 
> on users' ability to obtain and maintain CA certificates on their 
> clients, or similar requirements, whose fulfillment doesn't seem 
> more likely than S/MIME or PGP deployment. IMHO, ensuring that the 
> server who has relayed the message is vouched for sending 
> transactions by a trusted authority may be more viable (see RFC 
> 5518). I would additionally provide for an SMTP extension whereby 
> that relaying server grants that it knows where the message has 
> originated from, and takes accountability for its content.
> 

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: "J.D. Falk" <[email-masked]>, [email-masked]
Date: Fri, 31 Jul 2009 17:54:33 +0400
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

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-masked]>
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-masked]>
Cc: "J.D. Falk" <[email-masked]>, [email-masked]

> 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-masked]
> > 
> > 
> >> 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/
> > 
> > 
> > 
> 
> 
> 
> 
> 

Date: Fri, 31 Jul 2009 09:12:56 +0200
From: Alessandro Vesely <[email-masked]>
To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
CC: [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

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 [...]  Client-side scripting cannot be removed unless an alternative convention is proposed.
> 
> [...] The idea is that interactivity from client-side scripting can be replaced by transaction interactivity.  Since mail servers are intermediate agents [...]

Apparently, moving scripts execution to mail servers would also 
transfer vulnerability issues along the same path. Is it difficult 
to state whether a compromised server is better than a compromised 
client, but it is certainly better if at least one of them is not 
compromised. (Considering that many mail server also function as 
http servers, for handling email via web forms, it seems unlikely 
that the vulnerability added to the servers would thus be removed 
from the clients.)

In addition, it may be overly difficult to obtain real interactivity 
without local scripting. Indeed, the draft defines what minimal code 
a client has to be allowed to execute. Allowing some more seems 
likely to come as an optional feature...

Finally, if the model is meant for widespread use, it shouldn't rely 
on users' ability to obtain and maintain CA certificates on their 
clients, or similar requirements, whose fulfillment doesn't seem 
more likely than S/MIME or PGP deployment. IMHO, ensuring that the 
server who has relayed the message is vouched for sending 
transactions by a trusted authority may be more viable (see RFC 
5518). I would additionally provide for an SMTP extension whereby 
that relaying server grants that it knows where the message has 
originated from, and takes accountability for its content.

Date: Fri, 31 Jul 2009 00:00:19 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
CC: "J.D. Falk" <[email-masked]>, [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

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" <[email-masked]>
> 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" <[email-masked]>
> Cc: [email-masked]
> 
> 
>> 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/
> 
> 
> 

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: "J.D. Falk" <[email-masked]>
Cc: [email-masked]
Date: Fri, 31 Jul 2009 02:36:31 +0400
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

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" <[email-masked]>
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" <[email-masked]>
Cc: [email-masked]

> 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/

Date: Thu, 30 Jul 2009 15:14:29 -0600
From: "J.D. Falk" <[email-masked]>
To: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
CC: [email-masked]
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

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/

From: "Cheney, Edward A SSG RES USAR USARC" <[email-masked]>
To: [email-masked]
Date: Thu, 30 Jul 2009 22:20:09 +0400
Subject: Requesting comments on draft-cheney-safe-02.txt
Sender: [email-masked]

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

Thank you,
Austin Cheney

Date: Mon, 20 Jul 2009 19:50:04 -0400
From: Tony Hansen <[email-masked]>
To: Yet Another Mail Working Group <[email-masked]>, SMTP Interest Group <[email-masked]>, ietf-822 mailing list <[email-masked]>
Subject: current email address for John Myers?
Sender: [email-masked]

I need a current email address for John Myers (co-author of RFC 1864).
Anyone have one?

	Tony Hansen
	YAM co-chair

Date: Tue, 14 Jul 2009 21:51:04 -0700
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: SMTP Interest Group <[email-masked]>
Subject: [Fwd: RFC 5598 on Internet Mail Architecture]
Sender: [email-masked]

Folks,

It's been a long, five-year road.  The result is primarily due to the discussion 
that took place here, so I'd like to thank you all for sticking with the effort.

d/

-------- Original Message --------
Subject: RFC 5598 on Internet Mail Architecture
Date: Tue, 14 Jul 2009 14:50:20 -0700 (PDT)
From: [email-masked]
To: [email-masked], [email-masked]
CC: [email-masked]

A new Request for Comments is now available in online RFC libraries.

         RFC 5598

         Title:      Internet Mail Architecture
         Author:     D. Crocker
         Status:     Informational
         Date:       July 2009
         Mailbox:    [email-masked]
         Pages:      54
         Characters: 115741
         Updates/Obsoletes/SeeAlso:   None

         I-D Tag:    draft-crocker-email-arch-14.txt

         URL:        http://www.rfc-editor.org/rfc/rfc5598.txt

Over its thirty-five-year history, Internet Mail has changed
significantly in scale and complexity, as it has become a global
infrastructure service.  These changes have been evolutionary, rather
than revolutionary, reflecting a strong desire to preserve both its
installed base and its usefulness.  To collaborate productively on
this large and complex system, all participants need to work from a
common view of it and use a common language to describe its
components and the interactions among them.  But the many differences
in perspective currently make it difficult to know exactly what
another participant means.  To serve as the necessary common frame of
reference, this document describes the enhanced Internet Mail
architecture, reflecting the current service.  This memo provides
information for the Internet community.

INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
   http://www.ietf.org/mailman/listinfo/ietf-announce
   http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net