----- Original Message -----
From: "jfcm" <info(_at_)utel(_dot_)net>
Cc: "OPES Group" <ietf-openproxy(_at_)imc(_dot_)org>
Sent: Saturday, January 22, 2005 10:52 AM
Subject: RE: [draft-ietf-opes-smtp-use-cases-01]
I would rephrase this: OPES processor/network should use two kinds of
callout servers built as an OCP server. (1) filtering the data stream as
in
HTTP, SMTP and probably many other protocols (2) scanning stored files as
in the store phases of an MTA and probably many applications.
I think everyone can easily think of uses of each. May be we can make a
list to include in thre draft. If you consider the differences of the two
models the data stream filtering will have the typical use we quoted,
while
the file scanning will give ideas of new usages.
If I have been following this discussion correctly, don't you really have
three possibilities?
1) Dynamic Request at the RCPT state point
2) Dynamic Request at the DATA state point
3) Post Request of Accepted mail at the POST SMTP file storage point.
I don't wish to rehash the obvious:
#1 relies on transport information only, #2 and #3 relies on transport
information and possible 2822 information.
#2, #3 requires a standard passing of transport information as each system
may do this differently.
but more importantly, what concerns me the most from a commercial vendor
standpoint:
#2 and #3 has high potential payload bandwidth issues in a high anti-spam
environment.
#3 has a borderline, yet real legal conflict with US EPCA delivery
expectations of accepted data.
In practice, the mail filtering is considered a administrative action, but a
technical automated concept. We have a near 20 year tradition where
immediate rejection is more plausible, acceptable, not subject to
litigation versus fuzzy, even mal-practice, unreliable post acceptable
rejection systems where no notification is provided.
So consider this. Given a OPES system availability for implementation. We
were do our best to implement at #1 or #2 where an immediate rejection can
be applied by default setup. #3 would be offered optional by administrator
request only. The difference? Reduce product liability issues.
We do the same thing today in our current environment with a dynamic hooking
system into the SMTP state machine.
Once the message is accepted by SMTP, the responsibility moves to the
operator on how it is he/she wishes to handle/process the stored message.
I guess what this means from my standpoint is that an OPES 'like-device" is
applied POST SMTP, then how is this reflected back into the SMTP process?
I can only see it as a bounce. Any errant drop of mail will be attributed
to the system operator (sysop) post filtering policy.
In any case, I believe alot of this will be based on the OPES device and its
required input process parameters.
If a OPES service exist for #1, then only transport information is required:
result = OPES_RCPT(IP,HELO/ECHO,MAILFROM, RCPTTO)
if a OPES service exist for #2, then the functional model follows:
result = OPES_DATA(IP,HELO/ECHO,MAILFROM, RCPTTO, PAYLOAD)
#2 also works for #3, with the key difference of what is more desirable
instant or delayed rejection notification.
---
Hector Santos, CTO
WINSERVER "Wildcat! Interactive Net Server" http://www.santronics.com
support: http://www.winserver.com