Subject: RE: [draft-ietf-opes-smtp-use-cases-01]

From: "Martin Stecher" <[email-masked]>
Date: Fri, 21 Jan 2005 22:28:29 +0100

Hi Tony,

> >
> > I do not see any use case that deals with response 
> modification. Does
> > anybody see a use case in which first the MTA should check for the
> > response of its peer and then forward that response to the callout
> > server for further modification? What can be modified here? 
> Responses
> > are only short acknowledgements or error codes. So turning 
> an ok into an
> > error would be possible but the callout server does not 
> really need to
> > see the ok first, does it?
> 
> There are some situations in which an SMTP server may wish to 
> call forward
> to another server in order to validate a user's address. For example,
> Cambridge University's central email cluster acts as the MX 
> and anti-spam
> and anti-virus filter for several departmental email servers. 
> The central
> servers do not have a list of the valid email addresses for the
> departmental servers. In order to verify the recipient addresses on a
> message during the SMTP conversation with a client outside 
> the University,
> the central server performs an abbreviated SMTP conversation with the
> departmental server to check what response it would give to the RCPT
> command. Success and failure responses (250 and 550) are passed to the
> external client, but temporary failures (4xx) are modified to success
> responses so that we take responsibility for a message if the 
> departmental
> server is having problems.
> [...]

Thank you for this real world use case.

Not sure whether you see this as a response modification example, it's not IMO:
The university's central email server can send the RCPT
command to the callout servers that have access to the departmental
user directories and get the reply for this command in response to its
OCP request.
But it is not necessary to first create a pseudo reply in the central
mail server and to have that modified by the callout server. That
pseudo response would have no meaning to the callout server.

Regards
Martin

---

From: jfcm <[email-masked]>
Date: Sat, 22 Jan 2005 01:30:21 +0100

Tony, Martin,
please consider my initial proposition (repeated in my yesteray analysis) 
and how it fits to this? We are in a store and complex forward system 
(while http was a single forward one). This is true of the whole MTA but 
also true for most of the modules building the MTA. RFC 1958 says that we 
should proceed simple step by simple step.

What are the objections to consider filtering the stored data, without 
considering the forwarding data flow? So the SMTP mechanism are fully 
respected (not touched) and the maximum complexity can be supported (one 
step at a time) where ever the filtering and return occurs.

1. with HTTP we have a logic for acting on a live traffic.
2. with SMTP we will have a logic for acting on files.
3. data handling is the same.
4. whatever the complexity, we just look at the status of the file, change 
it or not; the server bears the complexity, but this is out of the OPES design?

jfc

---

From: Tony Finch <[email-masked]>
Date: Sat, 22 Jan 2005 04:10:18 +0000

On Sat, 22 Jan 2005, jfcm wrote:
> considering the forwarding data flow?

You have to be able to reject incoming messages during the SMTP
conversation.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
ROCKALL MALIN: VARIABLE 3 OR 4, BUT CYCLONIC 5 OR 6 AT FIRST IN SOUTH ROCKALL,
BECOMING NORTHEAST 4 OR 5 LATER. RAIN OR SHOWERS. MODERATE OR GOOD.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Sat, 22 Jan 2005 00:15:16 -0700

HTTP OPES could also act on stored messages, but it is more efficient to handle
the data as a stream and separate the storage function into a later stage.

Hilarie

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Sat, 22 Jan 2005 00:11:54 -0700

I think you are rejecting a reasonable response modification scenario
by saying "implement your service another way."  I don't see any
reason to exclude having the response modification done "in the flow".

Hilarie

---

From: jfcm <[email-masked]>
Date: Sat, 22 Jan 2005 16:52:31 +0100

>You have to be able to reject incoming messages during the SMTP

You are right. So I should rephrase this. I think this is very near from 
what Martin everyone says, but one function more.

Martin says "The filtering functionality is on the callout server. No 
difference between HTTP and SMTP here. The callout server may
even support adaptation of both messages for both protocols. That is our 
application agnostic approach. The callout server
is an OCP server with some filtering services."

Hilarie says "HTTP OPES could also act on stored messages, but it is more 
efficient to handle the data as a stream and separate the storage function 
into a later stage."

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.

jfc

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 22 Jan 2005 14:53:06 -0500

----- Original Message -----
From: "jfcm" <[email-masked]>
Cc: "OPES Group" <[email-masked]>
Sent: Saturday, January 22, 2005 10:52 AM
Subject: RE: [draft-ietf-opes-smtp-use-cases-01]

> 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