Re: SMTP Use Cases

"Alex Rousskov" <[email protected]> Fri, 22 Oct 2004 11:13:22 -0600
Newsgroups gmane.ietf.opes
Organization The Measurement Factory
Message-ID <[email protected]>
On Fri, 2004/10/22 (MDT), <[email protected]> wrote:

> There's a technical reason for questioning whether or not OPES
> is the right thing for SMTP, and I believe Martin once gave me
> a reasonable answer, but I don't think it's ever been elucidated
> on this list.  The question arises from SMTP being inherently
> store-and-forward, as Morin points out.  Thus, one would think
> the the "natural" architecture for handling it would be for the
> OPES processor to simply run SMTP and forward the messages to
> an SMTP server where the "service enhancements" can be applied.
> That SMTP server can then forward the messages onward to the appropriate
> "vanilla" SMTP servers.  So, why is OPES necessary?
>
> I believe that Martin told me that it would be much easier for
> developers to write OPES rules and modules for SMTP than to
> write them for SMTP directly, and I suppose that makes sense if
> OPES is deployed widely for HTTP and there is a base of developers
> skilled in that environment.  Is that an accurate statement of
> the intent of the OPES/SMTP proponents?  I think it would really
> help if we could agree on an answer to the basic question (above).

The reason we want OPES is so that we can reuse many things common to  
content adaptation, regardless of the protocol that the content came from.  
We do not want to answer content integrity, men-in-the-middle, or rules  
questions from scratch for every new protocol.

I may be repeating myself, but I still do not know how store-and-forward  
SMTP is different from whatever-you-want-to-call-it HTTP in the context of  
adapting content. Thus, for me, SMTP adaptation can be within OPES scope  
if HTTP adaptation is. Using your example above, exactly the same argument  
can be made for HTTP: why not forward the messages to an HTTP proxy where  
the "service enhancements" can be applied...

Alex.