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.