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

From: "Martin Stecher" <[email-masked]>
Date: Thu, 20 Jan 2005 11:02:06 +0100

Hi,

seems that we first need a common understanding of the wording and
deployment scenario.

> 
> Right now I am quite concerned by the wording and the drafts. 
> I read that the idea is that the OPES _is_ an MTA? Also there 
> is no interaction between MTAs (or I misread the part on 
> "previous" commands, which should be read with a wider meaning?).

I think we should not talk about "the OPES".
Please let's stick with the wording we agreed on earlier: There are
two agents: OPES processor and callout server.

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.

The OPES processor is a standard device that sits in the data stream
of the protocol we want to handle. That device gets enhanced by an
OCP client that allows to vector out that data to the callout server.
In HTTP the OPES processor is a proxy server; for SMTP we picked
a MTA as the primary device that sits in the SMTP data stream.

> 
> If I note UA as U, MTA ad M, MSA as S, MDA as D, Filters as F 
> and OPES as O, here is the scheme I understand:

[...]

Much too complicated in my view.
Let me try to bring in the other M*A things here and map that to
the normal programs that we see today when sending email:

You start with an email client program such as Outlook. This is your MUA,
allowing you to write the email.
From there you send email to an outgoing email server. In that email
server an MSA (mail submission agent) is waiting for your email and uses a
MTA (mail transfer agent) within the same server to forward this email to
other domains.
(Communication between the MUA and MSA may already be via SMTP or something
else such as MAPI; one reason why we do not concentrate on these devices).

The MTA in your email server may directly contact the email server of the
recipient our use other intermediate email gateways. On the sending email
server, the destination email server and all intermediate gateways MTAs are
running to send/receive/forward the SMTP messages.
That is why we concentrate on MTAs. Nearly all email which is not locally
handled within your domain, is sent this way via SMTP via two or more MTAs.

In the destination email server there is then a MDA (mail delivery agent)
that may put the email in the recipient's mailbox. The email client program
of the recipient will then probably use a different protocol (such as
POP3 or IMAP) to access the mailbox and retrieve/read the messages.

|---------|    |----------|      |-----------|      |----------|    |---------| 
| email  M|    |M email  M| SMTP |M  email  M| SMTP |M email  M|    |M email  |
| client U|----|S server T|------|T gateway T|------|T server D|----|U client |
|        A|    |A        A|      |A         A|      |A        A|    |A        |
|---------|    |----------|      |-----------|      |----------|    |---------|
                    |                  |                 |       
                    | OCP              | OCP             | OCP     
                    |                  |                 |       
               |----------|      |-----------|      |----------|               
               |  callout |      |  callout  |      |  callout |
               |  server  |      |  server   |      |  server  |
               |----------|      |-----------|      |----------|               

So the OPES processor might be the sender's SMTP server, the destination SMTP
server or any intermediate SMTP gateway.
(Which building block belongs to which authorotive domain is an important
question but different from deployment to deployment).

As you can see from the picture above, the MTA is either receiving or sending an
email (or both) within an email server/gateway. These are the two activation points
that section 5 of the draft wants to tell about.

Do we agree on what I wrote here?

Regards
Martin

---

From: jfcm <[email-masked]>
Date: Thu, 20 Jan 2005 17:37:56 +0100

>seems that we first need a common understanding of the wording and

Agreement. I apologize for not having been clear enough. I think I have 
used the concepts accurately but I did not say it, so you have understood 
it differently because you do not consider the same granularity. But I 
think we need it. I will try to explain.

>The filtering functionality is on the callout server.

Not in my scheme. The reason why is that we all know that an MTA is built 
in module and that a filtering/returning process may not be  the same 
depending where it happens and where it returns.

>is an OCP server with some filtering services.

This is where I disagree in part: it may be several servers depending where 
in the MTA architecture it is related to and to which servers it is related 
to (through OCP or not).

Let assume that there is a decision to clean the outbound list for U2 when 
U1 has received the mail. This action cannot be taken before the outlist 
module because no other module will ever know it (a mail may stay a few 
minutes in the different modules and days in the outlist - or whatever the 
name for that type of MTA)

>a MTA as the primary device that sits in the SMTP data stream.

This assumes that the OPES processor is an unique device/service. It can be 
in a network of OPES processor and take decisions on a mail depending on 
information negotiated on that network.

>Much too complicated in my view

I fully understand it. But what you propose here is a daisy chain http 
scheme. This is an exact but a-minima scheme. I do not see it scaling:
- one to one mail becoming one to many
- one single standard OCP action becoming different modules involvements
- no connection between OPES processors scaling to cross feedback among all 
the processors
- there is a single mail path when there are several mutually dependent 
(through OPESed modifications)

>the normal programs that we see today when sending email:

No problem with that. But we have to document this RFC is for "normal" 
program and to define normality.

>Do we agree on what I wrote here?

With that limitation which transforms a mail in an asynchronous http, 
certainly. I think this may help to reduce the complexity of the real life 
applications (I opposed as too complex, if you remember). If this is 
something everyone agrees I am OK. All the more than I suspect that the 
code modularity will permit to do what I say - the complexity being on the 
OPES processors).

My question on text changes remains.
jfc