Re: is SMTP a candidate for OPES ?

At 01:47 08/07/04, jfcm wrote:
>>I can still apply the same kinds of adaptations before or after the
>>message is permanently or temporary stored, right? I understand that
>>SMTP is store-and-forward, but I do not understand why this creates
>>problems for OPES architecture. OPES is simply a polite way to do
>>man-in-the-middle adaptations. As long as the application protocol
>>allows for intermediaries (of any sort), OPES should be applicable.

You can with a lot of "if".

- you can process the stream as in http - if you deal with spam and just 
check the first datagram
- you can fake the store-and-forward as a stream - but will the user buy 
the concept. This is why I quoted the Judge as a typical non technician who 
discuss that service. He bought the idea that SMTP is store and foreward 
because it gave him more possibilities.
- massaging a message at the store phase is far cheaper (complexity, 
bandwidth management, applications which can be used, acceptable delays, 
etc) than OPESing as an HTTP faked flow.
- you do not develop additional features related to IP windowing, what is a 
complex issue where newtork security is related to. But then only one 
single datagram mails are concerned (I am not against it, as I think this 
the way it should mainly be used).
- you dont consider that SMPT is not only a store and foreward protocol, 
but also a point to multipoint protocol and will have to address that 
question. I copied the issue on the Judge because it introduced the 
complexity to modify the header. The Judge was actually entered after the 
fact as a Bcc. What an OPES could have done.

etc.

My point is not that OPES does not apply. My point is that SMTP is very 
different from http and introduces a lot of additional contraints to OCP 
etc. So, the question is to know if it is worth doing it now, while UDP 
support could be far more usefull (for DNS) and give experience with IP 
support you may need in SMTP case.
jfc