RE: SMTP Use Cases

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

Hilary,

thank you very much for bringing this up again. You are right.

Let's stick with the virus scanner use case as a prominent example:

You can write an OPES callout service for HTTP virus scanning by
using any virus scan SDK and you can easily rewrite this for SMTP
and create an OPES callout server for SMTP messages as most virus
scanners can already handle mail files and if not, you, the developer,
are left with the task to write an email MIME section decoder to
feed the virus scanner.

But if you needed to write an SMTP server that does the AV scanner
you would also need to implement these features:
  - Mail inbound/outbound queues
  - Open Relay avoidance strategy
  - Full RFC 2821 compliance
  - MX record resolution
  - Attack prevention mechanisms

That's why I believe an OPES callout server is the much better
place to to SMTP message adaptation than writing another SMTP server
with additional functionality.

Regards
Martin


P.S.
I will be travelling for the next 8 days.
Not sure when and how often I can connect to the Internet to
follow up with this discussion